This is a loser-interesting question because it sounds petty. The agent already knows the run is stuck. Why be rude about the exact command? Why ask for branch and HEAD? Why insist on the dirty files? Because "blocked" is not yet a repair surface. It is only a narrated feeling until the run leaves behind enough structure for someone else to resume it without Slack archaeology or telepathy.
Dependable agent work does not report blockage as prose alone. It turns blockage into a packet: the exact failing command or handle, the lane it happened in, the state that remains, the boundary that stopped progress, and the next concrete repair step.
Why "blocked" is a flattering word
"Blocked" lets the system sound more competent than it is. The word suggests that the
run understood the task, came to a clean halt, and now awaits one obvious answer. Real
operator work is messier. Was the build command wrong? Did the run land in a detached
worktree? Is the endpoint actually dead, or did it return a useful
401 Unauthorized scope challenge? Is the side effect paused for approval?
Did the tool return a resumable state handle, or did the context vanish with the tab?
The embarrassing part is that serious builders do not want a graceful blocker story. They want the crude coordinates. Which command failed. Which machine or repo lane was touched. Which files are now dirty. What exact next command should happen. That lower- status packet is what makes the run inheritable.
The primary docs are already biased toward coordinates, not vibes
Git's current worktree documentation
says a repository can support multiple working trees and that linked worktrees share
everything except per-worktree files such as HEAD and index.
It also refuses to check out the same branch into another worktree unless you force it.
My inference from that is simple: branch, HEAD, and worktree path are not cosmetic
trivia. They are part of the state surface.
OpenAI's current guardrails and human review guide says approvals pause a run before sensitive tool calls, return interruptions plus a resumable state object, and later resume the same run instead of starting a new turn. The matching results and state guide is even blunter: interrupted runs return state, not a final answer, and that state is the saved snapshot you pass back in later. Once a runtime behaves that way, a vague "couldn't finish" message is below the standard the platform itself already set.
The Model Context Protocol is converging on the same rule. The final
SEP-2663 Tasks Extension
lets a server answer tools/call with an asynchronous task handle instead
of a final result, then retrieve or update it later through tasks/get,
tasks/update, and tasks/cancel. That is an explicit claim
that long work should leave behind an object you can point at, not just an apologetic
paragraph.
The
July 28, 2026 MCP authorization specification
makes failure more specific too. A server should include the required
scope in the WWW-Authenticate header, and the client must
treat the challenged scopes as authoritative for the current operation. In other words:
a precise 401 is already a repair packet. It tells the next operator what kind of
no happened.
The humiliatingly practical packet
The blocker packet serious builders keep asking for is not sophisticated. It is humiliatingly concrete:
STATUS: blocked
FAILED: bun run build
LANE: /Users/you/.codex/worktrees/task-x (branch automation/task-x, HEAD abc1234)
STATE: 4 task-owned files modified; deploy not attempted
BOUNDARY: approval/auth/build/test/live-check
NEXT: fix failing test in test/chopshopr-site/search.cases.js, rerun bun run buildThat looks almost too boring to publish. Which is exactly why it matters. The packet has no style points to hide behind. Either it leaves enough state for another builder to act, or it does not.
Name the failing thing.
Use the exact command, tool call, task handle, or route check. "Blocked" is a category. The failing object is the coordinate.
Name the lane.
Worktree path, branch, HEAD, environment, and target machine are part of the repair surface, not extra color.
Name the leftover state.
Dirty files, interruptions, resumable state, challenged scope, or pending approval tell the next operator what still exists.
Name the next move.
A blocker packet should end with one concrete repair step, not a vague promise to keep investigating.
What this means in Chopshopr's world
Chopshopr lives in the part of the stack where these differences matter immediately: local-first agents, MCP tools, NemoClaw and OpenShell host operations, on-device inference, isolated worktrees, and public routes that must survive after the chat window closes. In that world, soft blocker prose is expensive.
If a local model server is starting, say that. If the transport is alive but the caller needs a scope, say that. If the run is paused for approval, say that and preserve the state. If the site change is coded but unverified, say which command failed and which live route still needs a cache-busted check. The point of local-first tooling is not to sound autonomous. It is to keep the real operating seams visible enough that someone tired, skeptical, or newly parachuted into the run can still repair it.
This is also the gap between demo magic and dependable tools. The demo says the agent got stuck on something boring. The dependable tool says the exact boring thing, where it happened, and how to continue. One sounds lower status in the room. The other earns adoption.
Five questions worth asking every blocked run
- What exact command, task handle, or tool call failed?
- Which worktree, branch, HEAD, environment, or endpoint was active?
- What state still exists: dirty files, resumable state, approval pause, or scope challenge?
- Can a second operator continue from the packet without private context?
- What one concrete repair step happens next?
If your agent can answer those five questions, a blocker becomes a handoff surface. If it cannot, the word "blocked" is still hiding more than it reveals.