Approved escalated commands still inherit restricted network policy in interactive CLI sessions

What version of Codex CLI is running?

codex-cli 0.116.0

What subscription do you have?

Pro

Which model were you using?

gpt-5.4 high

What platform is your computer?

Linux 6.17.0-19-generic x86_64 x86_64

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

Ghostty (TERM=xterm-ghostty), no tmux, no zellij

What issue are you seeing?

In an interactive Codex CLI session (the TUI) with Default permissions, a command that requires network access can still fail after I explicitly approve escalation.

The core bug is that the restricted network sandbox policy appears to still be applied to an approved escalated command.

Observed behavior:

• the command is not allowlisted in ~/.codex/rules/default.rules
• Codex shows an approval prompt for the command
• I approve the prompt
• the command still fails with a GitHub network error instead of running with working host network access

Error from the approved command, e.g. gh issue:

error connecting to api.github.com
check your internet connection or https://githubstatus.com

This is in the TUI, not exec, app, or app-server, although likely to be reproducible there.

Workarounds:

• add the command prefix to ~/.codex/rules/default.rules
• or run Codex in full access / dangerous mode so the command bypasses the restricted path entirely

That suggests the approval flow is not fully removing the restricted network policy on the retried command.

What steps can reproduce the bug?

1. Start Codex CLI in default permissions mode.
2. Ensure the target network command is not allowlisted in ~/.codex/rules/default.rules.
3. In an interactive session, ask Codex to run a networked command against a public repo with required escalated permissions, for example:

gh issue list -R openai/codex --limit 3

1. Observe that Codex shows an approval prompt for the command.
2. Approve the prompt.
3. Observe that the command still fails with:

error connecting to api.github.com
check your internet connection or https://githubstatus.com

Affected thread id:

• 019d0aa4-3bfe-7100-a9df-9cf93b1d1397

What is the expected behavior?

Once the user explicitly approves the escalated command, the retried command should run without the restricted network sandbox policy.

In practice, an approved command that needs network access should be able to reach GitHub successfully instead of still failing with a sandbox-like network error.

Additional information

This appears related to the broader family of sandbox/network policy propagation issues, but this report is specifically about interactive approval flow:

• the user is prompted
• the user approves
• the retried command still behaves as if restricted network policy is active

Workaround today is to either allowlist the command prefix or run Codex with full access.

Implementation / fix spec

Probable failure mode:

• the approval flow correctly authorizes a retry without the filesystem sandbox wrapper
• but the retried attempt still inherits the original restricted network policy and/or managed-network enforcement state
• as a result, the command is retried in a partially unrestricted state instead of a truly unrestricted state

Concrete code paths that look involved:

• codex-rs/core/src/tools/orchestrator.rs
• the escalated retry path builds SandboxAttempt { sandbox: SandboxType::None, network_policy: turn_ctx.network_sandbox_policy, enforce_managed_network: has_managed_network_requirements, ... }
• that means the retry drops the sandbox wrapper but still keeps the original network policy and managed-network flag
• codex-rs/core/src/sandboxing/mod.rs
• SandboxManager::transform(...) preserves network_policy even when sandbox == SandboxType::None
• if the effective network policy remains restricted, it injects CODEX_SANDBOX_NETWORK_DISABLED=1
• it also returns an ExecRequest that still carries the restricted network_sandbox_policy
• codex-rs/core/src/tools/runtimes/shell/unix_escalation.rs
• the shell runtime passes network_policy and enforce_managed_network into SandboxTransformRequest
• then applies any network/proxy config from the resulting ExecRequest to the child environment

Expected implementation behavior:

• when a command is explicitly approved for escalated execution outside the sandbox, the retry should clear both the sandbox wrapper and the restricted network policy for that retry
• the retried execution should not preserve a restricted NetworkSandboxPolicy from the original turn if the approved action is intended to run unsandboxed
• the retried execution should not keep managed-network enforcement enabled for that approved unsandboxed retry
• the retried execution should not inject or preserve CODEX_SANDBOX_NETWORK_DISABLED=1 for that retry
• proxy/env rewriting that is only appropriate for the restricted sandbox path should not remain active on the approved unsandboxed retry

Suggested implementation points:

• audit the retry path in codex-rs/core/src/tools/orchestrator.rs where an approved command is rerun after a sandbox/network denial
• make the approved retry derive both sandbox mode and effective network policy from the escalation decision, not only sandbox mode
• update the transform/execution path in codex-rs/core/src/sandboxing/mod.rs so an approved unsandboxed retry cannot silently carry forward a restricted network policy
• verify the shell execution path in codex-rs/core/src/tools/runtimes/shell/unix_escalation.rs does not reapply restricted-network env/proxy behavior on an approved unsandboxed retry
• add regression coverage for interactive approval flow, not only allowlisted/trusted execpolicy flow

Acceptance criteria:

• in a default-permissions interactive CLI session, a non-allowlisted networked command that triggers approval succeeds after the user approves escalation
• the retried command does not see CODEX_SANDBOX_NETWORK_DISABLED=1 and can resolve and connect to network
• - behavior for commands that remain sandboxed is unchanged
• existing allowlisted/trusted-command behavior and child/subagent behavior are not regressed