LearnGrokA Bot that stalls and a Bot that overreaches are the same failure with the sign flipped: the brief did not say where the line was, so the Bot picked one.
When it is stuck
Work down these in order; the first two account for most cases.
Check for a pending approval, a question or a login. The most common cause is exactly what it says: it is waiting on you and the notification was missed. Open the conversation, and open the computer to see whether the Bot is sitting on a page waiting for a CAPTCHA, a sign-in or a secret request.
Check whether its screen is already busy. This one is structural and surprises people: a Bot runs one computer-use task on its screen at a time. A second task cannot start until the first finishes or is redirected. The Bot is not stuck, it is occupied, and the fix is to redirect the current task rather than to repeat the request.
Check usage and billing. An exhausted allowance or a reached spending limit stops work, and it presents as a Bot that simply does not proceed rather than as an error you would notice.
Check for a missing input. A Bot that cannot reach a document, an account or a folder often stops rather than improvising, which is the right behaviour. The report usually names what it could not reach.
Check for a genuine ambiguity. If two instructions conflict, or the task needs a judgement you did not authorise, stopping is correct. Resolve it in the Bot's description rather than in a one-off reply, so the same stall does not recur.
Then redirect or stop. A short message can redirect a Bot mid-task; a direct message takes priority over background work. If you want it to end, the command is "Stop now". Note what that does and does not do: it ends the work immediately, and it does not undo anything already completed.
When it acted without asking
Deal with the consequence first (retract, correct, notify), and the process second.
Start from the rule that governs the whole system: an approval controls the action being proposed, and it does not reverse work already done. So the question is never only "why did it not ask", it is also "what had already happened by the time it did".
Then, without blame-storming the software:
- Find the sentence that authorised it. Usually a broad "handle X" that you read narrowly and it read literally.
- Add the specific boundary to the brief, in the "come back to me before" list. General instructions to "be careful" do not work; enumerated actions do.
- Ask whether the capability should exist at all. If the Bot did not need send access to do its job, the fix is in the connection settings, not in the brief. See Connecting Bots to your tools safely.
- Move the task to draft-only until you have watched several clean runs.
- Write the boundary into the Bot's description, not the message. A standing rule in the profile sits in its context for every task; an instruction in one message does not.
When an approval will not clear
The opposite complaint, an action that keeps stopping no matter how often you allow it, usually has a specific cause. Check your Auto Review rules for a matching "Require Approval" entry: require rules take precedence over allow rules, so one forgotten require rule outranks every permission you have granted since. Note too that those rules live on the desktop you wrote them on rather than on your account, so a second machine has its own set.
More on how all of this fits together in What stops a Bot, and what does not.
The pattern that prevents both
Before a Bot runs an unfamiliar task, ask it to restate the goal, the boundaries and what it will do in the likely edge case, without starting. Mismatches show up in seconds and cost nothing at that point. There is a template for it in Grok Bot task brief prompts.
What changes
Grok Bot's approval mechanics, notifications and scheduling are early and moving. How the product surfaces a pending approval today is documented at x.ai/bot.
