When a Google Jules task hangs, fails, or returns changes you didn't want, use this troubleshooting guide to diagnose the cause and get a clean, correct pull request.
Google Jules tasks tend to go wrong in one of three ways: the task appears stuck and never finishes, it fails outright, or it completes but produces changes you did not want.
Each has different causes and different fixes, so the first step is identifying which one you are facing. Misdiagnosing wastes iterations.
All three are recoverable, and none should cost you anything permanent, because Jules works on a branch and pull request rather than your main code.
This guide addresses each mode in turn, then covers the habits that prevent all three.
Keep that safety net in mind while you troubleshoot: because nothing lands on your main branch without your review and merge, you can experiment freely. The worst outcome of a bad task is a closed pull request and a few minutes spent, not damage to your codebase.
A task that seems to hang is usually either genuinely still working or waiting on something. Because Jules is asynchronous, some jobs simply take longer than a quick edit.
Give it reasonable time before assuming failure. A large refactor across many files is not the same as adding a comment.
Check the task status in the Jules interface for any indication of progress, a prompt, or an error. Sometimes it is waiting on input or has hit a limit.
If it is truly unresponsive well beyond expectation, cancel and re-dispatch with a smaller, clearer scope. A hung task is often a sign the request was too large or too vague.
Before you re-dispatch, take the apparent hang as a hint about scope. A task that stalls is frequently one you asked to do too much at once, and breaking it into a first concrete step often sails through where the broad version stuck.
An outright failure often traces to access, environment, or scope. If Jules cannot read a needed file or the repository, it cannot complete the work.
Confirm the repository connection and permissions are intact, since access can change between tasks. A revoked integration turns previously fine tasks into failures.
Read any error message Jules provides. It frequently names the obstacle, whether that is a missing file, an unclear instruction, or a limit reached.
If the failure is about scope or ambiguity, rewrite the task to be narrower and more concrete, then try again. Small and specific succeeds where broad and vague fails.
If failures started suddenly after a period of everything working, suspect an environmental change rather than your prompt. A revoked GitHub app, an organization policy update, or a hit usage limit can all turn yesterday's fine task into today's failure.
The most common and most fixable mode is a completed pull request that does the wrong thing. This is almost always a communication problem, not a capability problem.
Vague tasks produce vague results. "Improve the app" gives the agent no target, so it guesses, and its guess rarely matches your intent.
Missing context is the other big cause. Jules reads your code but not your conventions, your architecture decisions, or your constraints.
The fix is to close the pull request or request changes, then re-specify the task with precise scope and the context the agent was missing.
Resist the temptation to blame the model when the result misses. Nine times out of ten the diff is a faithful answer to an underspecified question, and the leverage is in sharpening the question rather than retrying the same one and hoping for a different guess.
Turn a fuzzy request into a sharp one. Instead of "clean up the networking code," write "in NetworkClient.swift, extract the retry logic into a private method and add doc comments, without changing behavior."
Name files, methods, and expected outcomes. Specificity is the single biggest lever on output quality.
State what must not change. Telling the agent to preserve behavior or leave certain files alone prevents unwanted collateral edits.
Include your conventions explicitly, such as your architecture pattern or minimum iOS version. The context you provide is the context the agent uses.
A useful test is to ask whether a new human teammate could execute your task without asking a follow-up question. If they would need to clarify scope, files, or constraints, so does the agent, and adding those details now saves a round trip.
If a task keeps stalling or misfiring, it is probably too big. Large, open-ended requests strain any agent and produce sprawling, hard-to-review diffs.
Decompose the goal into a sequence of small, verifiable steps. Each step becomes its own task and its own reviewable pull request.
Smaller tasks fail less, finish faster, and are far easier to correct when they do go wrong. They also build your trust in the tool incrementally.
Think of it as the difference between one giant ambiguous ticket and a tidy backlog of well-defined ones. The backlog wins every time.
Smaller pull requests also compound a second benefit on Apple platforms: each one is quicker to build and run in Xcode, so your verification step stays fast. A sprawling diff is not only harder to review but harder to prove correct on your Mac.
When a pull request is close but imperfect, do not start over. Leave specific review comments describing the exact end state you want.
Jules can revise the same pull request in response. A tight feedback loop with concrete direction converges quickly.
Describe outcomes, not just problems. "This should return early when the array is empty" is more actionable than "this is wrong."
If several rounds of feedback still miss, that is a signal to take the change over manually. Recognizing when to stop delegating is part of using the tool well.
Treat that handoff as a normal outcome, not a failure. Some problems are genuinely subtler than any short description can capture, and the mark of using an agent well is knowing which tasks to keep and which to reclaim rather than grinding the loop indefinitely.
Prevent most failures by writing small, specific, context-rich tasks from the start. The quality of your instructions largely determines the quality of the output.
Keep every change behind human review and a local Xcode build, so a wrong change is caught before it ever reaches your main branch.
Remember that Jules cannot build, sign, or submit your iOS app, so some tasks are outside its reach entirely. Signing, provisioning, and submission problems belong in Xcode and App Store Connect, not in an agent task.
Because Jules is new and evolving, check the official documentation when behavior surprises you, and treat persistent unexplained failures as a reason to consult current guidance rather than to keep retrying blindly.
If you are tempted to reach for Jules to ship faster by wrapping a website in a thin native shell, know that no agent changes App Store policy, and Apple frequently rejects apps that are little more than a web wrapper. The reach of the tool ends well before the store.
First give it reasonable time, since asynchronous tasks can take a while, especially large ones. Check the task status for a prompt or error. If it is truly unresponsive well beyond expectation, cancel and re-dispatch with a smaller, clearer scope.
Usually the task was too vague or lacked context. Jules reads your code but not your conventions or constraints. Close or revise the pull request, then re-specify the task with precise scope, named files, expected outcomes, and what must not change.
Check that the repository connection and permissions are still intact, read any error message for the specific obstacle, and narrow the task. Large, ambiguous requests fail far more often than small, concrete ones.
Yes. Leave specific review comments describing the exact end state you want, and let Jules revise the same pull request. If several rounds still miss the mark, take the change over manually.