Plugin overrides Codex sandbox config and can trigger bwrap failures

Summary

The plugin currently passes an explicit sandbox mode when starting Codex app-server threads:

native review starts with sandbox: "read-only"
adversarial review starts with sandbox: "read-only"
task/rescue starts with sandbox: "read-only", or "workspace-write" when --write is used

That means a user-level Codex config such as:

approval_policy = "never"
sandbox_mode = "danger-full-access"

is not honored for plugin-launched threads. On Linux systems where bubblewrap cannot initialize, plugin commands can still fail with bwrap errors even though plain codex uses danger-full-access.

Reproduction

Configure Codex with sandbox_mode = "danger-full-access".
Use /codex:review or /codex:rescue --write through the Claude Code plugin.
Observe that the plugin-created thread receives a sandbox override and may enter the Linux bwrap sandbox path.

On an affected machine this manifests as errors like:

bwrap: loopback: Failed RTM_NEWADDR: Operation not permitted
bwrap: setting up uid map: Permission denied

Expected behavior

The plugin should inherit the effective Codex sandbox configuration unless it has a user-visible reason to override it. This matches the README wording that the plugin uses the user's existing Codex configuration.

Notes

I have a patch ready that omits the sandbox field from app-server thread/start and thread/resume requests unless an explicit override is provided, plus regression coverage for review and task --write.

+1 from macOS — same root cause, different sandbox. On macOS Seatbelt the hard-coded sandbox: "workspace-write" blocks .git/ writes and localhost listen(), which makes every end-to-end rescue task fail: Codex can't branch/commit (.git/index.lock: Operation not permitted) and can't run the backend test suite (listen EPERM when supertest spins up the Express app).

We hit this on two consecutive /codex:rescue --background dispatches against a Node+Express+Supabase monorepo. Our local workaround is a narrow ~/.codex/config.toml:

[sandbox_workspace_write]
network_access = true
writable_roots = ["<abs path>/.git", "<abs path>/.git/worktrees"]

This unblocks both cases, but only because we're on macOS and Seatbelt honors the per-mode config. If the plugin stopped force-setting sandbox (per your proposed patch), this config.toml would be respected without any plugin change — which is the cleanest outcome from our side too.

One incremental idea complementary to the "don't override" patch: a named --scoped-write preset on /codex:rescue that bundles network_access = true + writable_roots = [project .git] programmatically, so users don't have to hand-write config.toml per project. Effectively workspace-write with the two carve-outs the workspace boundary already implies (the project's own .git, localhost). Different shape from your patch, not a replacement — both could ship.

Downstream context (won't mean much here, but noted for traceability): https://github.com/jumpingloops/CVBounty/issues/293.

feat(sandbox)!: inherit user ~/.codex/config.toml sandbox_mode by def…

docs(v2.0.0): sync README + MIGRATION_v2.0.md + TROUBLESHOOTING.md wi…

fix(sandbox): omit sandbox in executeTaskRun + resume so read-only is…

fix(sandbox): omit sandbox from plugin threads so config.toml governs (…

Navigation Menu

Repository navigation

Plugin overrides Codex sandbox config and can trigger bwrap failures #240

Summary

Reproduction

Expected behavior

Notes

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Plugin overrides Codex sandbox config and can trigger bwrap failures #240

Description

Summary

Reproduction

Expected behavior

Notes

Activity

Basu-llm commented on Apr 23, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions