Claude Code 2.1.283 reports its version as the pane command, so the Claude readiness probe never returns resumed: restore fails, seats stick in attention_required, and clear-attention cannot clear them

[fkody1]

OpenRig version: 0.5.17 (f137f11). The probe is unchanged on main (packages/daemon/src/domain/native-resume-probe.ts:124 and :230).
OS, Node and tmux: macOS 26.5.2 (arm64), Node 22.23.1 (daemon), tmux 3.7c
Harnesses involved: Claude Code 2.1.283

What happened

After a daemon restart, the restore of an 11-seat rig ran claude --resume for every Claude seat. Four of them (Opus and Sonnet, all with "bypass permissions on") failed with:

Harness launch failed: Claude resume failed: timed out waiting for Claude to become active

restore.completed recorded those nodes as failed and startup_status became attention_required. The Claude processes came up fine a few seconds later and have been working normally since (runtime-hook activity running/idle, panes mid-turn, queue rows progressing). But rig ps / the TUI keep showing them as attention_required / "needs you", and nothing can clear it:

$ rig seat clear-attention orch1-lead@rigname
not_demonstrably_responsive — Uncleared attention class restore_outcome: pane_not_usable:
Pane state is inconclusive (awaiting_runtime); reconciliation requires resumed.

The same result with --reason "<operator attestation>". Seats whose pane happened to match the TUI heuristic during the restore window came up ready; the four that were still loading a large session did not.

Cause

• Claude Code 2.1.283 sets its process title to its version string, so tmux #{pane_current_command} reports 2.1.283, not claude:

  $ tmux display -p -t orch1-lead@rigname '#{pane_current_command}'
  2.1.283
  

• assessNativeResumeProbe (claude-code branch) only returns resumed when paneCommand === "claude" (line 124) or looksLikeClaudeTui(paneContent) (line 230), which needs a ❯ prompt plus the text "Claude Code v" or "accept edits on". A seat running "bypass permissions on" (or "auto mode on") shows neither once the welcome banner scrolls off. Everything else falls through to inconclusive / awaiting_runtime.

• Reproduced by calling the shipped module against live panes:

  orch1-lead@rigname        cmd=2.1.283  {"status":"inconclusive","code":"awaiting_runtime",...}
     ↳ same pane content, cmd='claude' → resumed
  data1-analyst@rigname     cmd=2.1.283  {"status":"inconclusive","code":"awaiting_runtime",...}
     ↳ same pane content, cmd='claude' → resumed
  

  (The pane-identity reconciler's pane_process layer verifies these same seats as verified, so process lineage already knows the pane is Claude.)

• Knock-on effects, all from the same probe:

  1. claude-resume times out at restore → node failed + startup_status=attention_required.
  2. ContextMonitor.normalizeStartupStatus re-probes on every poll with the same function → never flips back to ready.
  3. SeatAttentionReconciler.clearAttention delegates a restore.completed-sourced outcome to reconcileNodeRuntimeTruth, which also requires resumed; the --reason attestation branch is never reached for that class, so there is no operator path at all.
  4. deriveNodeLifecycleState ranks the stale startup/restore verdict above live agentActivity, so a seat that is demonstrably working renders as "needs you".

Expected

A seat whose runtime hook is reporting running/idle under the current occupant generation, or whose pane process lineage verifies as Claude, should count as resumed, and an operator attestation should be able to clear a restore-derived attention flag (in the spirit of #7).

Suggested fix

• native-resume-probe.ts: for claude-code, treat a pane command matching ^\d+\.\d+\.\d+$ as the Claude process (or use the same process-lineage check the identity reconciler uses), and extend looksLikeClaudeTui to accept the "bypass permissions on" / "auto mode on" footers.
• seat-attention-reconciler.ts: let fresh positive hook activity or --reason clear the restore_outcome class, as they already can for startup_status.

Side note (possibly its own issue)

Running rig reconcile-session <seat> --no-launch on a live managed seat as a workaround registered a new occupant tenure (kind=adopt) while the running process still carries the previous OPENRIG_OCCUPANT_GENERATION in its environment. Every later hook event is now judged generation_mismatch, so that seat's agentActivity is permanently unknown until it is relaunched. Refusing adoption of a seat that already has a live managed tenure, or carrying the tenure forward, would avoid that.

Related: #7 (startup readiness is one-shot), #79 (same class of probe/TUI drift on Codex 0.153).

[fkody1]

Two more data points from the same host, same evening:

Codex seats hit the same wall. Three Codex seats (codex-cli 0.157.1) were relaunched fresh with rig seat launch --stop --fresh and completed their first turns normally. rig seat clear-attention was still refused on all three:

not_demonstrably_responsive — Uncleared attention class restore_outcome:
pane foreground 'bash' does not identify runtime codex

Codex runs under OpenRig's own shell wrapper, so pane_current_command is bash, and a fresh launch does not reset the per-node outcome recorded by the earlier restore.completed. So a restore-derived attention_required is currently permanent for both runtimes until the next successful full restore, regardless of what the seat has done since.

CLI timeout vs launch duration. rig seat launch reports "did not respond in time … timed out after 5000ms … outcome UNKNOWN", but the daemon completes the launch fine; slow-operations.jsonl shows each POST /api/seat/launch/<seat> taking 21–24 s. A 5 s client timeout on an operation that routinely takes 20 s invites operators to retry a launch that already succeeded.

[mvschwarz]

Thanks for running the shipped probe against your live panes, and for swapping the pane command to show the difference. That made this quick to confirm.

You're right about the probe in 0.5.17. For Claude seats it only counts a restore as resumed when the pane command is exactly claude, or when the screen shows the ❯ prompt together with "Claude Code v" or "accept edits on". A seat in bypass or auto mode, once the banner has scrolled away, matches neither, so it stays inconclusive and the restore marks it failed. We see the same fragility on our own machine: Claude Code 2.1.282 here reports claude.exe as the pane command. Matching one process name is clearly not enough.

Thanks too for the Codex data points. Codex seats relaunched fresh still being refused, because the pane shows our shell wrapper as bash, looks like the same restore-outcome problem from the other side, and we've added it to the same triage.

We haven't traced the clear-attention path or your reconcile-session side note yet. Both are with the team, and the side note may well deserve its own issue. We'll link the work here when it's scheduled.

— dev-planner@v-openrig-build, on behalf of @mvschwarz