Repository navigation
Add --full-access flag to companion task for unsandboxed execution #145
Description
Summary
The codex-companion.mjs task command currently supports two sandbox modes:
--write→sandbox: "workspace-write"(bubblewrap sandbox, no GPU access)- (default) →
sandbox: "read-only"
There is no way to reach sandbox: "danger-full-access" through the companion script's task command. This makes it impossible to use codex-companion.mjs task for workflows that require GPU/CUDA access (e.g., running pytest with GPU tests, ML model forward passes, CUDA-dependent verification).
Use Case
We use Codex for automated plan review and implementation audit in a multi-repo ML platform. The audit phase runs actual tests (including GPU tests) to verify implementations. Currently we use codex exec --dangerously-bypass-approvals-and-sandbox for this, but we want to migrate to the companion script to benefit from the app-server protocol (shared broker, JSON-RPC, auth checking, --prompt-file).
The migration is blocked because task --write uses workspace-write sandbox, which restricts GPU device access via bubblewrap on Linux.
Proposed Change
Add a --full-access boolean flag to the task command that maps to sandbox: "danger-full-access":
// In handleTask:
booleanOptions: ["json", "write", "full-access", "resume-last", "resume", "fresh", "background"],
// In executeTaskRun:
sandbox: request.fullAccess ? "danger-full-access" : (request.write ? "workspace-write" : "read-only"),This is a 3-line change. The flag name --full-access mirrors the existing danger-full-access sandbox mode name while being more ergonomic than --dangerously-bypass-approvals-and-sandbox.
Workaround
We've patched this locally in codex-companion.mjs (lines 460, 573, 707, 725, 735-743, 753-762), but plugin updates will overwrite the patch.
Environment
- codex-cli 0.118.0
- Plugin version: 1.0.2
- Platform: Linux (bubblewrap sandbox)
Activity
feat: add --full-access flag for danger-full-access sandbox
D2758695161 commentedon Apr 4, 2026
👋 I've implemented this feature in PR #147 — adding the
--full-accessflag that maps tosandbox: "danger-full-access". Ready for review!— 一筒 🦀
fix: add --full-access flag and prevent zombie/hanging jobs
feat(task): add --full-access and --dangerously-skip-permissions alia…
heavy-tail commentedon Jun 30, 2026
Adding a concrete browser/network variant that seems covered by this same request.
In plugin 1.0.5 with codex-cli 0.142.3 on Linux/WSL2,
/codex:rescueand delegated task runs still force the spawned Codex session into sandboxed modes. Inplugins/codex/scripts/codex-companion.mjs, the task path setssandbox: request.write ? "workspace-write" : "read-only", and the review path usessandbox: "read-only". That flows intorunAppServerTurn/lib/codex.mjs, wheresandbox: options.sandbox ?? "read-only"becomes the per-turn--sandboxvalue.The practical failure mode is not only GPU/CUDA: browser/network-heavy delegated tasks fail too. Under
workspace-writeon Linux (landlock/seccomp, network disabled), launching headless Chrome for a delegated task crashes withsetsockopt: Operation not permitted/ crashpad errors. It also prevents integration tests that need localhost/network access. This still happens when the user's global~/.codex/config.tomlhassandbox_mode = "danger-full-access"and the project is trusted, because the plugin's per-turn sandbox value overrides the global setting.So +1 for an explicit opt-in full-access path, with sandboxing still the default. A flag on
/codex:rescueand the task-run entry would cover this, e.g.--full-access/--dangerously-bypass-sandbox, or an env/config key the companion intentionally honors.