›_ Codex Issues
Codex Issues / #15305

Review-mode subagent ignores runtime sandbox override and falls back to config defaults

Open 💬 4 comments Opened Mar 20, 2026 by janbam
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of Codex CLI is running?

codex-cli 0.116.0

What subscription do you have?

ChatGPT Plus

Which model were you using?

gpt-5.4 with high reasoning effort

What platform is your computer?

Linux 6.11.0-28-generic x86_64 x86_64

What terminal emulator and version are you using (if applicable)?

GNOME Terminal on Ubuntu 24.04 LTS

What issue are you seeing?

When I start a thread in danger-full-access via the UI/menu and then enter review mode, the spawned review subagent does not inherit the thread's effective runtime sandbox override. Instead, it falls back to the base config/default sandbox and starts in workspace-write.

On my machine this surfaced as a bwrap error at first, but that turned out to be a separate local AppArmor issue. After fixing the local Bubblewrap/AppArmor problem, the inheritance mismatch is still evident in Codex state and source.

Observed thread state from ~/.codex/state_5.sqlite:

  • Parent thread 019d0ac2-0ef5-7263-a370-86715e1dd67a:
  • source: cli
  • sandbox_policy: {"type":"danger-full-access"}
  • approval_mode: never
  • created_at: 2026-03-20 10:19:43
  • Review subagent thread 019d0ac3-ebaf-7060-8ca9-a4d8f4cd2fd9:
  • source: {"subagent":"review"}
  • sandbox_policy: {"type":"workspace-write","writable_roots":["/home/jan/.codex/memories"],"network_access":true,"exclude_tmpdir_env_var":false,"exclude_slash_tmp":false}
  • approval_mode: never
  • created_at: 2026-03-20 10:21:45

The code path looks consistent with that behavior:

  • codex-rs/tui/src/app.rs:1250 uses Op::OverrideTurnContext specifically so menu changes apply to the active thread immediately.
  • codex-rs/tui/src/app.rs:3562 stores runtime_sandbox_policy_override.
  • codex-rs/core/src/codex.rs:2273 applies session setting updates.
  • codex-rs/core/src/codex.rs:1049 still keeps a separate original_config_do_not_use.
  • codex-rs/core/src/codex.rs:5270-5273 shows the review turn context carrying the parent turn's effective approval and sandbox policies.
  • But codex-rs/core/src/tasks/review.rs:93-116 clones ctx.config and passes that cloned config into run_codex_thread_one_shot(...), which appears to ignore the effective runtime override already present on the turn context.

So the review subagent seems to inherit stale config defaults instead of the parent turn's live effective sandbox/filesystem/network policy.

What steps can reproduce the bug?

  1. Start Codex CLI on Linux.
  2. Change sandbox permissions from the UI/menu to danger-full-access for the active thread.
  3. Confirm the thread is running with the updated effective sandbox.
  4. Enter review mode so Codex spawns the review subagent.
  5. Inspect the new thread in ~/.codex/state_5.sqlite.

Thread IDs from my reproduction:

  • parent: 019d0ac2-0ef5-7263-a370-86715e1dd67a
  • review child: 019d0ac3-ebaf-7060-8ca9-a4d8f4cd2fd9

What is the expected behavior?

The review-mode subagent should inherit the parent thread's effective runtime permissions, including the active sandbox override from the menu, instead of reverting to config defaults.

If the parent thread is effectively danger-full-access, the review subagent should not silently downgrade to workspace-write.

Additional information

This appears separate from Linux/Bubblewrap/AppArmor problems.

I initially noticed it while debugging a local Ubuntu 24.04 Bubblewrap failure, but after fixing that local environment issue, the Codex behavior above still looks wrong on its own merits: the child review thread's persisted sandbox policy does not match the parent's effective runtime sandbox.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 5 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #14357
  • #14590

Powered by Codex Action

s1korrrr · 5 months ago

I prepared a fix for this on a public fork branch:

Root cause: review mode cloned ctx.config and reapplied review restrictions, but it did not propagate runtime-owned values from TurnContext such as the active sandbox policy, derived filesystem/network sandbox policies, current working directory, and sandbox executable path. That lets the review delegate fall back to stale config defaults instead of the environment the parent turn is actually using.

Fix summary: build the review subagent config from the live turn state first, then apply the review-only restrictions. I also added a regression test that mutates the runtime sandbox state and asserts the child review config preserves it.

Validation:

  • just fix -p codex-core
  • cargo test -p codex-core build_review_sub_agent_config_uses_turn_runtime_sandbox_state
  • ./tools/argument-comment-lint/run.sh

I tried to open a PR, but GitHub rejected PR creation because openai/codex currently reports pull_request_creation_policy: collaborators_only. If a maintainer wants this as an invited PR, I can open it immediately from the branch above.

EthicalAIExplorer · 4 months ago

Reproduced on codex-cli 0.120.0 in the interactive TUI, with a very similar result.

My environment:

  • Ubuntu 24.04.4 LTS
  • kernel 6.8.0-106-generic
  • Codex CLI 0.120.0

What I observed:

  1. Start Codex normally in a repo:

codex

  1. In the TUI, Full Access is enabled for the active session.
  1. An ordinary in-session shell prompt succeeds:

pwd && git status -sb

  1. Then run:

/review
Review uncommitted changes

  1. /review dispatches successfully, but the review path spawns a separate subagent and that child still executes through the sandboxed path, failing with:

bwrap: loopback: Failed RTM_NEWADDR: Operation not permitted

Relevant log markers from the failing review path:

  • op.dispatch.review
  • session_task.review
  • session_init.is_subagent=true
  • Codex(Sandbox(Denied ... bwrap: loopback: Failed RTM_NEWADDR: Operation not permitted))

Important comparison:

  • In-session Full Access did not fix /review
  • But a launch-time override did:

codex -c 'sandbox_mode="danger-full-access"'

With that launch command, /review -> Review uncommitted changes succeeded.

So this appears consistent with the issue described here: the review subagent is not inheriting the parent TUI session’s effective runtime override, while a launch-time sandbox override does propagate.

sunjiajunsunjiajun · 1 month ago

I am seeing what looks like the same class of issue with parent/subagent permission inheritance.

In my case, the parent agent is granted Full Access and the UI/status indicates that the permissions have been updated. However, when the parent dispatches a subagent, the subagent does not appear to use the updated effective permissions. The failure only becomes obvious when the child agent tries to perform work that should be allowed under the parent’s Full Access state, but still behaves as if it is running with the older/restricted permission context.

So the user-visible state is: permissions were updated successfully. The operational state is: spawned subagents do not reliably inherit that updated permission context. That makes the Full Access grant misleading for multi-agent workflows, because the main agent can continue but delegated work fails or asks for permissions unexpectedly.