Repository navigation
Codex App does not honor [sandbox_workspace_write] network_access = true from config.toml (works in CLI) #13373
Description
What variant of Codex are you using?
Codex App - Version 26.228.1430 (760)
What feature would you like to see?
Problem
Official docs state that for Codex App / CLI / IDE, network in workspace-write can be enabled via:
config.toml
[sandbox_workspace_write]
network_access = trueSource: https://developers.openai.com/codex/security
In practice, Codex CLI behaves as expected, but Codex App does not reliably match this behavior.
Codex CLI behavior (expected)
With:
[sandbox_workspace_write]
network_access = trueCLI can run networked commands in workspace-write mode, including DNS-dependent requests to internal/corporate hosts.
Codex App behavior (observed)
In App sandboxed runs, behavior is different:
scutil --dnsmay returnNo DNS configuration availableCODEX_SANDBOX_NETWORK_DISABLEDis often1- DNS-dependent commands to internal/corporate hosts fail
To make the same tasks work in App, users currently need escalated/full-access execution.
Why this matters
This blocks efficient day-to-day engineering workflows in corporate environments:
- running benchmarks/tests that depend on internal services
- validating integrations against internal APIs
- using Codex App as a practical replacement for CLI without over-privileging execution
Why current workaround is insufficient
Current workaround is to run with escalated permissions / full-access (or approve broad prefixes like make).
This works, but it is not least-privilege:
- grants broader execution power than needed,
- is policy-unfriendly for enterprise environments,
- does not provide predictable network behavior for all tools/commands.
Proposal
Please add one of the following:
-
CLI parity in App:
Honor[sandbox_workspace_write] network_access = truein Codex App exactly as in CLI. -
Explicit App UI controls:
- Filesystem sandbox:
workspace-write - Network:
enabled(same practical behavior users get in CLI withnetwork_access=true)
- Filesystem sandbox:
-
Clear docs:
Document network behavior differences between CLI/App and sandbox/escalated/full-access modes, and clarify config scope in App.
Expected outcome
Users can keep strict filesystem sandboxing while still enabling required network access, without requiring Full Access.
Related
- Codex app should respect network_access = true #10702: App does not respect
network_access=trueas expected (CLI/App parity gap). - codex app can't touch web , but codex cli can #10856: CLI can run
curl, while App fails with DNS resolution errors. - External CLIs fail with DNS lookup error, while Codex CLI works #10616 (closed): External CLIs in App fail with DNS lookup errors, while CLI works.
- Codex unable to access my localhost rest endpoint #10610 (closed):
localhost/ internal endpoint is not reachable from sandbox; discussed as sandbox/network enhancement direction.
Additional information
No response
Activity
JHenzi commentedon Mar 12, 2026
Present on Mac desktop. Codex even wrote an app to write to the Click UP API but won't run it. This is going to make me cancel.
mikemike396 commentedon Mar 13, 2026
With the latest build I was able to change the sandbox settings to workspace write and check the "allow network access". After restarting codex my automations can access the network!
JHenzi commentedon Mar 13, 2026
Mac desktop, latest version, lacks that feature/option.
sokolgood commentedon Mar 18, 2026
Updated to Codex App - Version 26.313.41514 (1043)
The issue appears to be resolved. Codex now provides configuration directly in the UI, and it correctly respects values from config.yaml.
Thanks for the improvement!
Closing the issue.
JHenzi commentedon Mar 18, 2026
You'd think this would be closed when users have it. I am running the latest client, I don't have that option.
JHenzi commentedon Mar 26, 2026
This doesn't exist, why is this closed?