Rescue runs launched via the harness's background Bash die silently when the shell tree is reaped — job wedges at "running" with companion, broker, and app-server all killed mid-turn

Summary

A /codex:rescue task can be killed out from under the plugin by Claude Code's own background-shell cleanup, leaving the job wedged at status: "running" forever. This is a specific, reproducible trigger behind the "stuck running" reports in #391 / #377 (item 2) / #367, with a full forensic timeline. It also explains part of the background-mode silent loss in #395.

The trap: agents/codex-rescue.md tells the subagent to "prefer background execution" for long tasks, but nothing pins down which background. In practice the subagent (a Claude model) frequently satisfies this by setting run_in_background: true on its Bash tool call while invoking codex-companion.mjs task in foreground mode — instead of passing the companion's own --background flag. The two are not equivalent:

• Companion --background: spawnDetachedTaskWorker creates a detached, unref'd worker that survives its launcher. This is the designed-for path.
• Harness run_in_background: the foreground companion lives inside a Claude Code-tracked background shell. The rescue subagent then exits immediately (its instructions forbid it from polling or collecting). The shell is now orphaned, and when Claude Code later cleans it up, it kills the whole process tree — companion, the broker (still parent-linked as the companion's child, despite detached: true), and the broker's codex app-server child. All die mid-turn via signal, so the catch that would write status: "failed" never runs. The job record is frozen at running and, per #377 item 2, no PID-liveness check ever notices.

Forensic timeline (observed 2026-07-04, macOS)

Key negative results: the Codex rollout ends with a client-pending exec and never records a timeout or abort event (rules out exec timeout / turn abort); no crash logs (rules out app-server crash); a controlled test of spawn(..., {detached: true}) from a subagent's Bash call shows detached-and-reparented processes do survive subagent exit — the incident tree died because companion + broker + app-server were still parent-linked when the tree-kill walked it.

Impact

• Job wedged at running indefinitely; /codex:status and status --wait report a corpse as live work (no liveness probe — #377 item 2).
• The stale record then blocks follow-ups: resolveLatestTrackedTaskThread throws "Task … is still running. Use /codex:status before continuing it.", and the Stop hook nags about a job that died days ago.
• The orchestrating Claude session dutifully waits on the state file; the user eventually has to notice and nudge. Intermittency is confusing: foreground rescues always work, backgrounded ones fail only when cleanup wins the race against job completion.

Environment

• Plugin: codex 1.0.1 (marketplace openai-codex)
• Codex CLI: 0.142.4 · Claude Code: 2.1.197 (desktop app, local agent mode) · macOS 15.x (arm64)

Proposed fixes (layered; any one helps, all three are cheap)

1. Close the instruction gap — in agents/codex-rescue.md and skills/codex-cli-runtime/SKILL.md, state explicitly: never set the Bash tool's run_in_background when invoking the companion; for long tasks pass the companion's --background flag (foreground Bash call returns quickly with the job stub). This removes the trigger with a docs-only change.
2. Make the runtime reap-proof — have the foreground companion path (or the broker spawn) fully detach the broker into its own session (double-fork / setsid-equivalent) so a tree-kill of the shell can't take the shared broker and app-server down with it; optionally add a SIGTERM handler in the companion/worker that flushes status: "failed", error: "terminated by signal" before exit.
3. Stop trusting the state file (= #377 item 2, seconding it with this real-world postmortem) — buildSingleJobSnapshot / status should probe process.kill(pid, 0) and transition ESRCH'd jobs to failed so a dead job can never present as running.

Happy to provide the raw logs (job log, rollout jsonl, session transcript excerpts) if useful.

Start with agents/codex-rescue.md and skills/codex-cli-runtime/SKILL.md to trace how background execution is instructed. Then inspect spawnDetachedTaskWorker, buildSingleJobSnapshot, and status to compare the proposed instruction, process-detachment, and PID-liveness fixes. Done means the selected fix prevents silent loss or reports a dead job as failed instead of leaving it running.