codex-companion.mjs hardcodes workspace-write sandbox for write tasks — git push fails with DNS error, work stuck in local worktree #304

Summary

When the plugin is invoked for a write-mode task (e.g. via /codex:rescue or any flow that ends in runAppServerTurn(... { write: true })), codex-companion.mjs hardcodes the sandbox to "workspace-write" at line 460:

sandbox: request.write ? "workspace-write" : "read-only",

workspace-write permits filesystem writes inside the workspace but blocks network egress. As a result, any task whose deliverable involves git push (e.g. mechanical sweep PRs, autonomous code-fix PRs) fails inside the Codex shell with:

git push origin <branch>
fatal: unable to access 'https://github.com/<org>/<repo>.git/': Could not resolve host: github.com

The plugin then returns the task as "completed" — the commits exist in a local worktree (typically .claude/worktrees/<branch> of the workspace repo) but they're never pushed and no PR is opened. Recovering the work requires the operator to:

1. Read the per-job log under ~/.claude/plugins/data/codex-openai-codex/state/<workspace-hash>/jobs/task-*.log
2. Discover the worktree path from the log
3. Manually push the branch from a shell with working network
4. Manually open the PR

Reproduction

1. Install the plugin (1.0.2 confirmed; recent versions likely affected).
2. Invoke a write-mode task that ends with a push, e.g. via the rescue agent in Claude Code:

   "Update the gitignore in this repo to add <some-path>. Open a PR titled chore: ...."

3. Codex completes the local work (branch + commit), then attempts git push.
4. Push fails with the DNS error above; plugin returns success-shaped output.

Why this matters

Write-mode tasks are the highest-leverage use of the plugin — they're the "fire-and-forget delegation" path that makes the plugin valuable vs the bare CLI. The current behavior turns every push-required task into an archaeology exercise, which removes most of the plugin's UX win over codex exec directly.

Proposed fix

Make the sandbox mode configurable, with safer defaults than danger-full-access but with git push capability. Two options:

Option 1 (minimal): pass through caller-provided sandbox

Allow callers of runWriteTask (or whatever the entry is) to override the sandbox via the request object:

sandbox: request.sandbox ?? (request.write ? "workspace-write" : "read-only"),

This lets internal callers (e.g. the rescue agent) opt into danger-full-access for tasks that need push, while leaving the conservative default for everything else.

Option 2 (better): respect ~/.codex/config.toml trust_level

The Codex CLI's config already defines per-project trust_level (e.g. [projects."/Users/og/src/exit"] trust_level = "trusted"). When the workspace root matches a project with trust_level = "trusted", default the sandbox to danger-full-access (or whatever the closest equivalent is that permits network for git push). This makes the trust model explicit and centralized, rather than hardcoded in plugin logic.

Option 3 (fallback): post-Codex push step

If Option 1/2 are too invasive, add a post-completion step in the plugin that runs git push from outside the sandbox (i.e., in the plugin's own shell, which has full network access). This separates "Codex generates commits inside sandbox" from "plugin pushes to remote outside sandbox" — cleaner separation of concerns.

Workaround in use

For now, we're routing push-required tasks through codex exec --sandbox danger-full-access "<prompt>" directly via Bash, bypassing the plugin entirely. This loses the plugin's auto-PR scaffolding but recovers reliable push behavior.

Environment

• Plugin version: 1.0.2 (latest as of 2026-05-07)
• Codex CLI: 0.129.0
• Platform: macOS (Apple Silicon)
• Workspace: trusted in ~/.codex/config.toml