Summary
When a Claude Code session delegates to the codex-rescue agent and the task specifies an output path outside the repository (e.g. ~/.local/bin/foo), Codex refuses to write:
writing outside of the project; rejected by user approval settings
Codex reports this clearly and even suggests the remedy. The problem is that the constraint is not documented anywhere in the plugin — agents/codex-rescue.md, the skills, and the README contain no mention of writable / sandbox roots.
Why this is costly
The delegating agent typically checks whether the artifact files exist, sees nothing, and concludes "the delegation failed / the result could not be retrieved." It then redoes the work itself. The actual cause — an impossible spec — is only visible in the Codex CLI output, which the parent may never read. This is silent, repeats every session, and wastes both time and tokens.
Reproduction
- From Claude Code, delegate to
codex-rescue with a prompt like: "create ~/.local/bin/mytool and a test script next to it, then run the tests."
- Codex reports the rejection above; no files are created.
- Nothing in the plugin documentation would have warned the caller in advance.
Suggested fix
Add a short note to agents/codex-rescue.md (and ideally the runtime/prompting skills), for example:
Sandbox scope: Codex can only write inside the repository and temp directories. Tasks that must produce files elsewhere (~/.local/bin, ~/.config, system paths) should write into the repo and let the caller install them.
Two smaller points that would help the same failure mode:
- Note that runs exceeding the foreground timeout move to the background, and that
codex-rescue cannot retrieve its own background result — the caller must read the output file.
- Recommend that the caller read the Codex output rather than inferring success/failure from artifact presence.
Environment
- codex plugin
1.0.6
- Claude Code on macOS (arm64)
Summary
When a Claude Code session delegates to the
codex-rescueagent and the task specifies an output path outside the repository (e.g.~/.local/bin/foo), Codex refuses to write:Codex reports this clearly and even suggests the remedy. The problem is that the constraint is not documented anywhere in the plugin —
agents/codex-rescue.md, the skills, and the README contain no mention ofwritable/ sandbox roots.Why this is costly
The delegating agent typically checks whether the artifact files exist, sees nothing, and concludes "the delegation failed / the result could not be retrieved." It then redoes the work itself. The actual cause — an impossible spec — is only visible in the Codex CLI output, which the parent may never read. This is silent, repeats every session, and wastes both time and tokens.
Reproduction
codex-rescuewith a prompt like: "create~/.local/bin/mytooland a test script next to it, then run the tests."Suggested fix
Add a short note to
agents/codex-rescue.md(and ideally the runtime/prompting skills), for example:Two smaller points that would help the same failure mode:
codex-rescuecannot retrieve its own background result — the caller must read the output file.Environment
1.0.6