Codex App does not honor `[sandbox_workspace_write] network_access = true` from `config.toml` (works in CLI)

[sokolgood]

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 = true

Source: 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 = true

CLI 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 --dns may return No DNS configuration available
• CODEX_SANDBOX_NETWORK_DISABLED is often 1
• 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:

1. CLI parity in App:
   Honor [sandbox_workspace_write] network_access = true in Codex App exactly as in CLI.

2. Explicit App UI controls:

   • Filesystem sandbox: workspace-write
   • Network: enabled (same practical behavior users get in CLI with network_access=true)

3. 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=true as 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

[JHenzi]

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]

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]

Mac desktop, latest version, lacks that feature/option.

[sokolgood]

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.