Foreground task dispatch dies unrecoverably at Claude Code's 10-min Bash cap — SIGTERM kills the codex chain and no session id is ever surfaced for resume

Repo: github.com/openai/codex-plugin-cc
Plugin version: 1.0.6
Environment: Claude Code 2.1.218, macOS (darwin 27.0.0), codex CLI via companion runtime

Summary

A foreground codex-companion.mjs task dispatch is executed by the calling agent as a single Claude Code Bash tool call. Claude Code's Bash tool has a hard 600000 ms (10 min) ceiling — at timeout the harness SIGTERMs the process tree, killing the companion and the whole codex chain (codex app-server, codex-code-mode-host) mid-run. The work is lost silently:

• the Bash call returns exit 143 with no final stdout from the companion,
• the codex thread had done ~10 minutes of real work (1 MB rollout file, active tool calls seconds before the kill),
• the companion never surfaced the codex session/thread id to the caller, so the calling agent has no handle to recover with.

The run WAS recoverable — but only because I manually dug the session UUID out of ~/.codex/sessions/2026/07/23/rollout-*.jsonl and ran codex exec resume <uuid> "finish the task", which picked up the preserved context and completed. Nothing in the plugin's output makes that possible for a normal caller.

Repro

1. From a Claude Code agent, dispatch a research-grade task in foreground mode (no --background), e.g. an analysis brief requiring web verification — anything that runs > 10 min.
2. The Bash call carrying node .../codex-companion.mjs task "$TASK_PROMPT" hits Claude Code's 600000 ms cap.
3. Observe: exit 143, pgrep -fl codex empty, rollout file mtime frozen, no output artifact, no session id ever printed.

Why guidance alone doesn't cover it

agents/codex-rescue.md says to prefer background for tasks "likely to keep Codex running for a long time" — but duration is unpredictable up front (this task was a bounded analysis brief that happened to exceed 10 min), and the guidance never names the hard 600 s ceiling, so agents can't reason about the cliff. When they guess wrong, the failure is total instead of degraded.

Suggested fixes

1. Emit the codex thread/session id early on stdout (first line, before the model runs). A killed foreground call then leaves a recovery handle in the partial tool output.
2. Trap SIGTERM in the companion and print a one-line recovery hint (killed by host timeout — resume with: codex exec resume <id>) before exiting; optionally detach the codex child so the in-flight turn can finish and be reattached.
3. Name the 600000 ms Claude Code Bash cap explicitly in agents/codex-rescue.md / skills/codex-cli-runtime/SKILL.md, and flip the default recommendation: foreground only for tasks confidently < ~8 min, background otherwise.

Related but distinct: #517 covers background jobs killed by host timeouts staying "running" in the registry; this issue is about foreground dispatch, where there is no registry entry at all and the kill also takes down the codex processes.

Start with codex-companion.mjs and reproduce the foreground task timeout described in the issue, then inspect agents/codex-rescue.md and skills/codex-cli-runtime/SKILL.md. Done means a foreground run exposes a recovery handle before execution can be terminated, handles the host timeout clearly, and documents the 600000 ms limit and foreground/background guidance.