Skip to content

Surface workers blocked on a permission prompt (#31) - #54

Merged
currentbits merged 2 commits into
mainfrom
coder/worker-blocked-on-a-permission-prompt-st-91eed4
Aug 15, 2026
Merged

currentbits merged 2 commits into
mainfrom
coder/worker-blocked-on-a-permission-prompt-st-91eed4

Conversation

@currentbits

Copy link
Copy Markdown
Owner

Fixes #31.

The problem

A run blocked on a can_use_tool permission prompt sets awaitingInput (runner.js) but stays at status working — and nothing downstream told anyone:

  • thread_status (the orchestrator's MCP tool) returned only status / lastAssistantText / lastError, so an orchestrator polling a quiet worker saw "working" and nothing else.
  • The wake path (queueOrchNotice) fires only on done / failed.
  • shouldNotify only fired on working -> done / working -> failed, so no desktop notification either.

Net effect: an unattended worker sits blocked forever and the stall is invisible.

What changed

electron/orchServer.js — thread_status now returns awaitingInput, plus awaitingPermission: what the run is actually asking for, read from the runner's existing getPendingPermission (already used by ipc.js, so no new plumbing). awaitingInput is guarded on status === "working" — the same guard Sidebar.tsx:223 uses — so a stale flag left behind by a run that died mid-prompt does not read as blocked. The tool description and the server INSTRUCTIONS now tell an orchestrator to check it when a worker goes quiet.

electron/notify.js + electron/main.js — shouldNotify gained a synthetic "waiting" state (working + awaitingInput), derived in main.js by a small threadNotifyState() helper used both for the live push and the boot seed. A run that blocks while the window is in the background posts a "needs permission" notification; the later waiting -> done/failed still notifies, and waiting -> waiting does not re-fire on every push.

What I deliberately did not do

Wake the orchestrator on waiting. It cannot answer a permission prompt, so a notice would just make it spin — notifying the human is the actual unblock. The orchestrator can see the state via thread_status when it wants it.

Verification

  • node --test electron/test/notify.test.js → 6/6 pass (new cases: working -> waiting, no re-fire on waiting -> waiting, waiting -> done/failed still notifies).

  • orch-server tool handlers suite passes, including a new test that a blocked worker reports awaitingInput: true with the prompt summary and that a stale flag on a failed thread reports false.

  • npm run typecheck clean.

  • Full npm run test:electron has 25 failing suites in this environment (real-CLI / network dependent). The failure set is byte-identical before and after this change — diff of the two not ok lists produced no output.

  • PR created by the Claude Code agent

Willem and others added 2 commits August 15, 2026 13:49
… IPC: full transcript pushed on every chunk; Markdown re-pars
A run stalled on a can_use_tool prompt stays "working" forever: thread_status
never reported it, and the notification path only fired on done/failed. An
unattended orchestration worker could sit blocked with nothing to show for it.

- thread_status returns awaitingInput plus awaitingPermission (the prompt
  summary, via the runner's existing getPendingPermission). Guarded on
  status === "working", the same guard the sidebar badge uses, so a flag left
  behind by a run that died mid-prompt does not read as blocked.
- shouldNotify gained a synthetic "waiting" state (working + awaitingInput):
  a blocked run in the background posts "needs permission", and the later
  waiting -> done/failed still notifies without re-firing on every push.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@chatgpt-codex-connector

Copy link
Copy Markdown

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

@currentbits
currentbits merged commit 1041150 into main Aug 15, 2026
1 check passed
@currentbits
currentbits deleted the coder/worker-blocked-on-a-permission-prompt-st-91eed4 branch October 3, 2026 16:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Worker blocked on a permission prompt stalls the orchestration invisibly

1 participant