Summary
codex:codex-rescue tasks hang indefinitely when dispatched with isolation: "worktree" and the rescue agent uses run_in_background: true on the Bash call. The worktree is cleaned up before Codex finishes, leaving Codex running in a deleted directory.
Root Cause
- Rescue agent calls
codex-companion.mjs task --write with run_in_background: true
- Bash returns immediately ("Command running in background...")
- Rescue agent returns "Codex task dispatched in background" and exits
- CC sees agent returned with no file changes → deletes the worktree
- Codex is now running in a deleted directory → hangs at "Turn started"
The rescue agent uses run_in_background in two cases:
- Explicitly:
--background flag in the task text is interpreted as run_in_background: true
- Implicitly: For large prompts with long timeouts, Claude sometimes independently decides to background the call
Repro
# SUCCEEDS — rescue agent waits for Codex to complete:
Agent(subagent_type="codex:codex-rescue", isolation="worktree",
prompt="Create foo.txt with content hello")
# FAILS — rescue agent backgrounds, worktree cleaned before Codex finishes:
Agent(subagent_type="codex:codex-rescue", isolation="worktree",
prompt="Create foo.txt with content hello. --background")
Parallel dispatch without --background works fine — three concurrent worktree tasks all succeed. The issue is purely about early worktree cleanup from backgrounding.
Suggested Fix
In codex-cli-runtime SKILL.md, change the --background handling from:
- If the forwarded request includes `--background` or `--wait`, treat that as Claude-side
execution control only. Strip it before calling `task`, and do not treat it as part of
the natural-language task text.
To:
- If the forwarded request includes `--background` or `--wait`, strip it before calling
`task`. Do NOT set `run_in_background` on the Bash call. The rescue agent MUST wait for
Codex to complete — backgrounding causes the parent worktree to be cleaned up before
Codex finishes, silently orphaning the task.
Impact
Any codex:codex-rescue dispatched with isolation: "worktree" where the rescue agent backgrounds the Bash call will silently fail. No error, no timeout — just an indefinite hang at "Turn started" with Codex working in a deleted directory.
Environment
- Claude Code 2.1.89
- codex-plugin-cc (marketplace install)
- macOS Darwin 25.2.0
Summary
codex:codex-rescuetasks hang indefinitely when dispatched withisolation: "worktree"and the rescue agent usesrun_in_background: trueon the Bash call. The worktree is cleaned up before Codex finishes, leaving Codex running in a deleted directory.Root Cause
codex-companion.mjs task --writewithrun_in_background: trueThe rescue agent uses
run_in_backgroundin two cases:--backgroundflag in the task text is interpreted asrun_in_background: trueRepro
Parallel dispatch without
--backgroundworks fine — three concurrent worktree tasks all succeed. The issue is purely about early worktree cleanup from backgrounding.Suggested Fix
In
codex-cli-runtimeSKILL.md, change the--backgroundhandling from:To:
Impact
Any
codex:codex-rescuedispatched withisolation: "worktree"where the rescue agent backgrounds the Bash call will silently fail. No error, no timeout — just an indefinite hang at "Turn started" with Codex working in a deleted directory.Environment