codex-implementer: handle sandbox write-denial (fail loud, opt-in fallback) - #5
Conversation
On some hosts (observed on Windows) codex's sandbox setup helper fails to grant the workspace write ACE and caches the failure, so every --sandbox workspace-write run reports the workspace as read-only and the lane stays dead with no explanation. Teach codex-implementer to recognize that signature and either return STATUS: unavailable with the exact cause and host remediation hints, or — only when the caller's spec explicitly includes "sandbox-fallback: allowed" — retry once under the operator's own configured sandbox mode, marking the report SANDBOX: downgraded so the change is never silent. Document the recoverable case in the orchestration skill. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 05a16dea40
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| retry once with the operator's own configured sandbox mode by omitting the | ||
| `--sandbox` flag entirely (codex then uses `sandbox_mode` from | ||
| `~/.codex/config.toml`, which the machine owner chose deliberately). Add |
There was a problem hiding this comment.
When a trusted repo contains .codex/config.toml, omitting --sandbox does not necessarily use the machine owner's ~/.codex/config.toml; Codex's configuration precedence lists Project config files: .codex/config.toml ahead of User config: ~/.codex/config.toml. In the sandbox-denial path this can make an opted-in fallback run under a repository-supplied sandbox/approval mode, including broader access, while the report says it used user-config, so the downgrade is not actually explicit to the operator.
Useful? React with 👍 / 👎.
…ac180#4 DannyMac180#5 DannyMac180#6 DannyMac180#7 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
1 participant
Problem
On some hosts — reproduced on Windows 10 — codex's sandbox setup helper fails to grant the workspace write ACE (
SetNamedSecurityInfoW failed: 5in~/.codex/.sandbox/sandbox.*.log) and then caches the failure: it never re-attempts the grant, so everycodex exec --sandbox workspace-writerun has the model report "the workspace is read-only and write approval is disabled" and produce no diff. The codex-implementer lane is permanently dead on such hosts, and the agent's current instructions give it no way to explain why or recover.Change
agents/codex-implementer.md:git status).STATUS: unavailablewithREASON: sandbox denied writes …, the exact codex message, and host remediation hints (one elevated codex run so the helper's ACE grant succeeds; or restart codex daemons / clear~/.codex/.sandboxcache), orsandbox-fallback: allowed— retries once with--sandboxomitted, deferring to the operator's ownsandbox_modein~/.codex/config.toml, and addsSANDBOX: downgraded to user-config (workspace-write denied)to the report.workspace-writeremains the unconditional first attempt; nothing starts atdanger-full-access, and no fallback is ever silent.skills/orchestration/SKILL.md:unavailablecase and the explicit opt-in line, so the architect knows the escape hatch exists instead of just rerouting.Why this shape
The lane's contract is "loud failure over silent substitution". This keeps that: the safe sandbox stays the default, the fallback requires an explicit per-spec opt-in from the caller (who is in the best position to know the operator accepted their own codex sandbox config), and the report always discloses the downgrade.
🤖 Generated with Claude Code