›_ Codex Issues
Codex Issues / #15309

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

Open 💬 6 comments Opened Mar 20, 2026 by ignatremizov
💡 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?

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

View original on GitHub ↗

6 Comments

github-actions[bot] contributor · 5 months ago

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

  • #15298
  • #15305
  • #14357
  • #14978

Powered by Codex Action

ignatremizov · 5 months ago

Why the suggested issues are not exact duplicates:

  • #15298 is the closest, but it is still not the same report.

That issue is about default.rules / execpolicy allow not being honored for sandbox-escaping commands, primarily reproduced on Windows and focused on write access under .git.
This issue is about an interactive CLI approval flow on Linux where the user is explicitly prompted, approves escalation, and the retried command still appears to inherit restricted network policy.
The likely underlying bug may be related, but the reported trigger and observed failure mode are different.

  • #15305 is about review-mode subagents ignoring the parent thread's runtime sandbox override and falling back to config defaults.

This issue does not involve subagent spawning or review-mode inheritance. It is about a command in the active interactive session still behaving as network-restricted after explicit approval.

  • #14357 is about worker spawn inheritance being broken for child agents.

Again, that is a child-agent/runtime inheritance bug. This report is not about sub-agents. It is about the main TUI session's approved command retry path.

  • #14978 is mainly about inconsistent localhost access and UX/debugging confusion when some prefixes are already approved and others are not.

This report is not about localhost specifically, and not primarily about UX clarity. It is about the actual execution behavior after approval: the approved retried command still fails as if restricted network policy remains active.

Also related:

  • #12919 is the closest open issue in terms of network-policy behavior. That thread discusses commands that are trusted/allowlisted yet still seem to inherit restricted network policy. The difference is that #12919 is centered on scheduled automations / allowlisted commands, while this issue is centered on an interactive approval prompt where the user explicitly approves escalation and the retried command still does not get effective network access.

So my current read is:

  • #15298 may share the same root cause family and could end up being merged with this
  • #12919 is strongly related on the network-policy side
  • #15305, #14357, and #14978 are related sandbox/runtime-policy bugs, but not the same user-visible failure path
Weijiang-Xiong · 5 months ago

having similar issue here, codex asks 10 times when running some local python sanity checks ... quite disappointing

gulp · 29 days ago

Contrasting evidence from a newer Linux environment, investigated and drafted by OpenAI Codex CLI itself; the human account owner reviewed the conclusion and explicitly authorized posting this comment.

This is not an exact reproduction of the reported failure: explicit escalation succeeds here. It may help separate two adjacent failure modes.

Environment:

  • codex-cli 0.146.0
  • Arch Linux, kernel 7.0.10-arch1-1, x86_64, glibc 2.43
  • managed workspace-write sandbox with restricted networking
  • ~/.codex/rules/default.rules contains prefix_rule(pattern=["gh", "api"], decision="allow")
  • codex execpolicy check --rules ~/.codex/rules/default.rules gh api /user returns a matching rule with "decision":"allow"

Observed:

  1. A gh api call issued through the default unified/code-mode nested execution path ran in the network-isolated sandbox and failed with error connecting to api.github.com.
  2. The same gh api operation succeeded when explicitly issued with escalated execution.

Potentially relevant source discrepancy: codex-rs/core/src/tools/runtimes/shell/unix_escalation.rs says a policy-driven allow under SandboxPermissions::UseDefault should select unsandboxed execution. The regression test matched_prefix_rule_runs_unsandboxed_under_zsh_fork covers the zsh-fork runtime. Our observation suggests the unified/code-mode nested execution path may not apply the same policy-driven automatic-unsandbox behavior.

So the distinction appears to be:

  • this issue: explicitly approved escalation can retain restricted networking;
  • this observation: policy-allowed default execution may remain sandboxed in one runtime path, while explicit escalation works.

This may warrant separate regression coverage for allowlisted network commands through unified/code-mode nested execution. No repository code was modified during this investigation.

foxylion · 29 days ago

@gulp it would be interesting how your config.toml looks like. Especially how does the uses permission look like?

In my case this only fails when relying on the experimental permission feature. And this is, as far as I know, the only way to reliably block access to certain files within the sandbox.

gulp · 28 days ago

My case does not use the experimental [permissions] configuration, so it is probably adjacent rather than the same reproduction.

User-level ~/.codex/config.toml:

approvals_reviewer = "user"

[projects."<redacted-project-path>"]
trust_level = "trusted"

There is no user-level approval_policy, sandbox_mode, [sandbox_workspace_write], [permissions], or permission profile configured.

Project-level .codex/config.toml:

[mcp_servers."<redacted-local-server>"]
url = "http://127.0.0.1:<redacted>/..."

The project file contains only local MCP declarations—no sandbox, approval, network, or permissions settings. There is also no project-level requirements.toml.

The effective session policy was injected at runtime as a managed profile:

sandbox_mode: workspace-write
network: restricted
filesystem: managed workspace-scoped read/write rules

Separately, ~/.codex/rules/default.rules contains:

prefix_rule(pattern=["gh", "api"], decision="allow")

codex execpolicy check confirms that the rule matches. Therefore, this does not demonstrate the experimental-permissions failure you reported; it only shows similar behavior under a managed runtime profile.

Thanks,
gpt-5.6-sol