Skip to content

codex-implementer: handle sandbox write-denial (fail loud, opt-in fallback) #5

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
pandaofwild wants to merge 1 commit into
base: main
Choose a base branch
from
Open

codex-implementer: handle sandbox write-denial (fail loud, opt-in fallback) #5

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
30 changes: 29 additions & 1 deletion agents/codex-implementer.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -69,14 +69,41 @@ Flag discipline (non-negotiable):

| Flag | Why |
|---|---|
| `--sandbox workspace-write` | Codex writes code, scoped to the working tree. Never `danger-full-access`. |
| `--sandbox workspace-write` | Codex writes code, scoped to the working tree. Always the first attempt — never start with `danger-full-access`. |
| `-c model_reasoning_effort=high` | Pins GPT-5.6 Sol to high reasoning for complex implementation work. |
| `--skip-git-repo-check` + `--cd "$(pwd)"` | Deterministic working root; works outside git repos. |
| `- < spec file` | Prompt via stdin. No quoting hazards, no truncated specs. |
| `${T:+$T 600}` | Ten-minute wall clock when `timeout`/`gtimeout` exists (macOS needs `brew install coreutils`); runs uncapped otherwise. On timeout, report `STATUS: timeout` with whatever landed. |

`--model gpt-5.6-sol` selects the Sol capability tier — if the caller's spec names a different codex model, use that instead; the slug is a documented default, not a constant.

### Sandbox denial — fail loud, or fall back only on explicit opt-in

On some hosts (observed on Windows), codex's sandbox setup helper fails to grant
the workspace write ACE and then caches the failure: every `--sandbox
workspace-write` run ends with codex reporting the workspace as read-only
(e.g. *"the workspace is read-only and write approval is disabled"*) and
`git status` shows no changes. The helper does not retry on its own, so the
lane stays dead until the host is repaired.

When you see that signature:

1. **If the caller's spec contains the exact line `sandbox-fallback: allowed`**,
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
Comment on lines +92 to +94

@chatgpt-codex-connector chatgpt-codex-connector Bot Jul 12, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Avoid fallback through project Codex config

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 👍 / 👎.

`SANDBOX: downgraded to user-config (workspace-write denied)` to your
report — the downgrade must never be silent.
2. **Otherwise stop** and return `STATUS: unavailable` with
`REASON: sandbox denied writes — workspace-write ACE grant failing on this host`,
the exact codex message, and the remediation hints: run codex once from an
elevated shell so the setup helper can complete the write-ACE grant, or
restart codex background processes / clear the cached state under
`~/.codex/.sandbox`.

Never jump straight to `danger-full-access` on a first attempt, and never fall
back without reporting it.

3. **Verify independently.** Read the diff (`git diff` / `git status`), run the spec's verification command yourself, and read codex's final message from `"$FINAL"`. Codex's claim of success is not evidence; your re-run is.

## What you return
Expand All @@ -88,6 +115,7 @@ OBJECTIVE: [restated in one line]
CHANGES: [file — one-line summary, per file, from the actual diff]
VERIFIED: [verification command you re-ran — actual output evidence]
CODEX SAID: [one-line summary of codex's final message, note any disagreement with the diff]
SANDBOX: [only when downgraded: "downgraded to user-config (workspace-write denied)"]
GAPS: [spec ambiguities, unfinished items, or "none"]
```

Expand Down
2 changes: 2 additions & 0 deletions skills/orchestration/SKILL.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -33,6 +33,8 @@ Grok vs codex is not a capability ranking — it's a failure-distribution questi

If a lane returns `unavailable` or `timeout`, re-route the same spec to the other lane and say so explicitly in your report — never quietly absorb the substitution. If both CLI lanes are unavailable, implement with a Claude subagent and state the downgrade plainly.

One recoverable `unavailable` case: when codex reports `sandbox denied writes` (a host-side sandbox bug — the workspace-write ACE grant fails and the failure is cached; observed on Windows), you may resend the same spec with the line `sandbox-fallback: allowed` if the operator accepts codex running under their own configured sandbox mode; the lane then retries once without `--sandbox` and marks the report `SANDBOX: downgraded`.

## The spec contract

Implementers share none of your conversation context. Every delegation prompt carries all five parts:
Expand Down