orchestration worker-start --agent claude fails at agent_readiness on Windows (Claude Code 2.1.301); --terminal works #30111

Activity

1. AmethystLiang commented on Oct 18, 2026

   

   AmethystLiang

   on Oct 18, 2026

   Contributor

   More actions

   looking into it
2. AmethystLiang

   assigned

   Jinwoo-H

   on Oct 18, 2026
3. gildedge commented on Oct 19, 2026

   

   gildedge

   on Oct 19, 2026

   More actions

   Confirming this on macOS with Orca 1.4.229 and Claude Code v2.1.266 — so it's not Windows-specific, and it spans at least Claude Code 2.1.266–2.1.301. Two pieces of new evidence that complicate the picture:

   1. The --terminal workaround does not work on macOS. Reusing a fully-booted, idle Claude terminal still timed out at agent_readiness:

   orca orchestration worker-start --task task_e5307f961d76 --retry-of ctx_43ffadb384bb \
     --terminal term_8b317e5c-0ceb-45f6-af44-cd4638e527c2 --worktree current \
     --from <coordinator> --timeout-ms 120000 --json
   # → dispatch ctx_36cae3f8c3c5, state: failed, stage: agent_readiness, lastError: timeout
   #   effects: terminal "reused", residualResources: []
   

   The terminal had Claude Code sitting at a live idle composer the whole time (❯ prompt, ⏵⏵ bypass permissions on). This rules out slow first-boot as the cause and points squarely at the launch-readiness lane never recognizing this TUI version — consistent with the claude.json idle-anchor suspicion in the OP, but also suggesting the plain tui-idle path is not consulted on --terminal starts here the way it apparently is on Windows.

   2. The fleet layer and the readiness gate disagree. After an app relaunch, worker-list --run <id> --include-remote --json reported the failed Claude dispatch with projection.liveness.verdict: "live" (source: agent_status, fresh observation) while stage.detail stayed agent_readiness / failed. Orca could see the agent was alive; only readiness couldn't.

   Consequence worth calling out: three consecutive detection-gap failures tripped the documented circuit breaker and permanently failed Task task_e5307f961d76 (--retry-of now refused with task_not_startable). So a readiness-detection gap doesn't just waste time — it burns the Task. Consider treating a fleet-verified live agent at an idle composer as readiness evidence, or failing these starts with a distinct code that doesn't consume circuit-breaker strikes. Full receipt trail: dispatches ctx_43ffadb384bb (claude, --agent), ctx_36cae3f8c3c5 (claude, --terminal reuse), run run_0872486ca7ed.

   Codex side note (distinct blocker, possibly overlaps #25007): --agent codex on the same machine (Codex v0.163.0, YOLO mode) also timed out at agent_readiness (dispatch ctx_54b014b7b410) — but its terminal was parked on Codex's "Set up security for Daybreak mode" account modal (Press a number to choose · esc to dismiss), which blocks prompt injection entirely. Whatever the readiness fix is, modal-blocked agents may need their own detection/dismissal path.

   Note: this report was prepared with the help of an AI assistant (Kimi), which ran the commands above on the reporter's machine.
4. gildedge commented on Oct 21, 2026

   

   gildedge

   on Oct 21, 2026

   More actions

   Confirmed fixed in 1.4.230 (macOS, Claude Code v2.1.266 — same machine and same Claude build as my report above, so the Orca upgrade is the only variable).

   Full supervised loop now passes end-to-end:

   • worker-start --agent claude → state: ready, stage: input_accepted (on 1.4.229 this timed out at agent_readiness three consecutive times, including the --terminal warm-reuse variant)
   • Worker received the task, executed it, sent worker_done with outcome: succeeded
   • check --wait → worker-release → check --ack all clean; final worker-list shows 0 reclaimable terminals

   Receipt IDs for your telemetry: run run_748417b533c2, task task_300649fa31cb, dispatch ctx_494e883b6aad, delivery delivery_dc10ab4c691a.

   Note the v1.4.230 release notes don't mention readiness — worth a changelog line, since anyone who hit this on 1.4.229 won't know to retry. Leaving whether to close this issue to you, since the Windows --agent case in the OP may still want separate verification.

   Note: this confirmation was produced with the help of an AI assistant (Kimi), which ran the commands above on the reporter's machine.
5. nwparker commented on Oct 24, 2026

   

   nwparker

   on Oct 24, 2026

   Contributor

   More actions

   Thanks for reporting this! The agent readiness wait was reworked in #27925 and another reporter confirmed worker-start --agent claude now works on 1.4.230. Could you confirm on the latest build on Windows? Please reply if it still times out at agent_readiness.
6. DavidCho1024 commented on Oct 26, 2026

   

   DavidCho1024

   on Oct 26, 2026

   More actions

   Still reproduces on Windows 11 with Orca 1.4.239 and 1.4.240, Claude Code 2.1.310, Orca agent permission "Own settings" (no --dangerously-*), default shell PowerShell.

   orca orchestration worker-start --worktree current --agent claude --model sonnet --effort low --timeout-ms 90000 --spec "..." → state: failed, failedStage: agent_readiness, lastError: timeout (also with 60 s and 180 s). The worker terminal sits at Claude's idle composer the whole time.

   What I observed:

   • The worker's SessionStart hook does reach Orca. %APPDATA%\orca\agent-hooks\last-status.json has an entry for the worker pane with hookEventName: SessionStart, payload.state: done, sessionBoundary: true, and a launchTokenHash.
   • On that worker terminal, even a plain orca terminal wait --terminal <worker> --for tui-idle --timeout-ms 15000 times out.
   • A Claude started with orca terminal create --command "claude --model sonnet --effort low" in the same worktree (no launch token; its SessionStart entry has no launchTokenHash) satisfies --for tui-idle right away.
   • Handing that pre-launched terminal to worker-start --terminal <handle> works end to end: state: ready, stage: input_accepted, then worker_done arrives about 15 s later. The catch is that worker-release leaves it retained (external_terminal), so we close it ourselves.

   So on Windows the readiness lane seems to ignore, or never match, the launch-token-bearing hook status for Orca-launched Claude, while untokened terminals are fine. Codex workers via --agent codex work on the same machine.