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

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   CLIIssues related to the Codex CLIIssues related to the Codex CLI

   sandboxIssues related to permissions or sandboxingIssues related to permissions or sandboxing

   tool-callsIssues related to tool callingIssues related to tool calling

   on Mar 20, 2026
2. github-actions commented on Mar 20, 2026

   

   github-actionsBot

   on Mar 20, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • default.rules is not honored for sandbox-escaping commands even when execpolicy returns allow #15298
   • Review-mode subagent ignores runtime sandbox override and falls back to config defaults #15305
   • Worker spawn inheritance broken: child worker agents do not inherit parent runtime/ network policy #14357
   • Inconsistent localhost access across approved command prefixes can silently invalidate debugging #14978

   Powered by Codex Action
3. ignatremizov commented on Mar 20, 2026

   

   ignatremizov

   on Mar 20, 2026

   Last edited by ignatremizov

   Author

   More actions

   Why the suggested issues are not exact duplicates:

   • default.rules is not honored for sandbox-escaping commands even when execpolicy returns allow #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.

   • Review-mode subagent ignores runtime sandbox override and falls back to config defaults #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.

   • Worker spawn inheritance broken: child worker agents do not inherit parent runtime/ network policy #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.

   • Inconsistent localhost access across approved command prefixes can silently invalidate debugging #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:

   • Scheduled automations cannot access GitHub API in default sandbox despite allowlisted gh api and loaded token #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
4. Weijiang-Xiong commented on Mar 20, 2026

   

   Weijiang-Xiong

   on Mar 20, 2026

   More actions

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

   removed

   CLIIssues related to the Codex CLIIssues related to the Codex CLI

   tool-callsIssues related to tool callingIssues related to tool calling

   on Mar 20, 2026
6. gulp commented on Jul 30, 2026

   

   gulp

   on Jul 30, 2026

   More actions

   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.
7. foxylion commented on Jul 30, 2026

   

   foxylion

   on Jul 30, 2026

   More actions

   @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.
8. gulp commented on Jul 30, 2026

   

   gulp

   on Jul 30, 2026

   More actions

   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
9. zaccromero commented on Nov 15, 2026

   

   zaccromero

   on Nov 15, 2026 – with ChatGPT Codex Connector

   Last edited by zaccromero

   More actions

   Reproduced on macOS in Codex Desktop with Codex CLI 0.169.0, with an important configuration-specific clarification discovered after inspecting current main.

   The active custom permission profile has:

   • explicit denied-read filesystem globs for **/.env and **/.env.*
   • managed networking enabled
   • only localhost and 127.0.0.1 in the domain allowlist

   In that profile, approved require_escalated commands failed with:

   Network access to "api.doppler.com" was blocked: domain is not on the allowlist for the current sandbox mode.
   

   The same happened for codex agents against ab.chatgpt.com, and for a nested codex exec attempt against api.openai.com. The equivalent Doppler command reached its service from the user's normal terminal.

   Current main already strips managed networking for ordinary approved escalation and includes coverage for unproxied escalated execution. However, because denied reads are active, the request takes the EscalatedSandboxWithRestrictions path. Current integration coverage intentionally keeps the owner network policy in that mode.

   So this reproduction should not be treated as proof that current main incorrectly preserves network restrictions for an otherwise unrestricted approved escalation. It instead highlights a UX/contract problem: the command is described and approved as require_escalated / “unsandboxed execution,” but security restrictions are intentionally retained without clearly explaining that the requested escalation is only partial or that an explicit domain grant is required.

   Expected UX in this configuration:

   • before approval, state that denied-read protections prevent a fully unsandboxed launch;
   • state that the owner-managed network allowlist will remain active;
   • identify the missing domain and the supported scoped remedy;
   • avoid presenting the approval as though it will bypass restrictions that cannot be removed.

   No secret values, credentials, device identifiers, or private repository paths are included.