Codex 0.153.x draws its prompt as `»`, so startup readiness never sees the TUI and fresh launches fail as "returned to a shell"

[celaya-solutions]

OpenRig version: 0.5.17 (f137f11). The same code is on main at f137f11.
OS, Node and tmux: macOS 27.0 (arm64), Node 22.23.2 (daemon), tmux 3.7b
Harnesses involved: Codex 0.153.4 (standalone arm64 release)

What happened

rig up … and rig seat launch <codex-seat> --fresh start Codex, and Codex reaches its idle prompt. Startup still fails after 30 seconds, and the seat's tmux session is gone afterwards:

Readiness timeout after 30s — harness did not become interactive: The probe pane returned to a shell instead of staying inside the runtime.

The visible screen while the probe was running:

╭─────────────────────────────────────────────────╮
│ >_ OpenAI Codex (v0.153.4)                      │
│                                                 │
│ model:     gpt-6-astra ultra   /model to change │
│ directory: ~/Documents/openrig                  │
╰─────────────────────────────────────────────────╯
• You have 3 usage limit resets available. Run /usage to use one.
» Ask Codex to do anything
  gpt-6-astra ultra · ~/Documents/openrig

Cause

• looksLikeCodexTui (packages/daemon/src/domain/native-resume-probe.ts:300) needs a line that starts with ›. Codex 0.153.4 draws its composer prompt as », so the check fails. The code comments mention Codex 0.155.1; I did not check which Codex release changed the prompt symbol.
• The probe then reaches SHELL_COMMANDS.has(paneCommand). pane_current_command is bash because the /bin/sh …/openrig-tmux-send-*.txt wrapper leads the foreground process group, with Codex as its child. This is the shape from Codex seat stuck in attention_required because OpenRig's own /bin/sh launch wrapper fails the pane identity check #28. PR fix: improve Codex startup and restore reporting #38 fixed the identity reconciler, but in 0.5.17 this startup readiness path still treats a shell pane command as "returned to shell".
• looksLikeCodexHookReviewPrompt makes the same assumption in its gate-end check (/^\s*›(?:\s|$)/, around line 338). After the hook dialog is dismissed, a later » prompt does not replace the old panel, so the seat can keep reporting hook_trust_gate.

I ran the shipped assessNativeResumeProbe({ runtime: "codex", paneCommand: "bash", paneContent }) on the captured screen:

before: {"status":"failed","code":"returned_to_shell","detail":"The probe pane returned to a shell instead of staying inside the runtime."}
after accepting `»` as well as `›`: {"status":"resumed","code":"active_runtime","detail":"Codex is running with an active interactive TUI in the probe pane."}

I patched both checks locally in the installed dist to accept [›»] and restarted the daemon. After that, fresh Codex seats reached ready, and seats that had been stuck in attention_required showed as run.

Related, not patched

For the same screen, classifyPaneActivity returns unknown / no_activity_signal. It finds no › idle prompt, and the footer gpt-6-astra ultra · ~/… does not match /gpt-\d[\d.]* .+ · Context \[/. A default rig send still delivers with an advisory, but sends that wait for idle would refuse.

Suggested fix

Accept both prompt symbols, or match the composer line by its structure rather than one symbol. Also, when a Codex process is alive under the pane, the startup readiness probe should not report "returned to shell" just because pane_current_command is a shell. PR #38's lineage walk could be reused there.

Checks

• I searched existing issues for this (Codex seat stuck in attention_required because OpenRig's own /bin/sh launch wrapper fails the pane identity check #28 is related: same wrapper shape, different code path).
• I am on the latest published version (0.5.17).

[mvschwarz]

Thanks for running the shipped assessNativeResumeProbe on your captured screen, before and after. That made this quick to confirm.

One thing we couldn't reproduce: our Codex 0.153.4 panes draw ›, not ». Your #78 mentions Orca. Was this screen in Orca too, and which locale is it running? That would tell us what switches the symbol.

The code side is as you describe in 0.5.17. looksLikeCodexTui only accepts a line starting with ›, and when that misses, the startup probe treats a bash pane command as "returned to shell" even though Codex is running under the wrapper. The hook-review check has the same › assumption. Accepting both symbols, and not calling a live Codex "returned to shell", is the direction we'd take. Your classifyPaneActivity note belongs with the same fix.

We'll link the work here when it's scheduled.

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