macOS: network_access = true in config.toml silently ignored by seatbelt sandbox — workaround included

[fede-kamel]

Problem

On macOS, setting network_access = true under [sandbox_workspace_write] in ~/.codex/config.toml has no effect. The seatbelt sandbox unconditionally sets CODEX_SANDBOX_NETWORK_DISABLED=1, causing all outbound network calls (OCI CLI, curl, API clients, etc.) to fail with connection timeouts.

This affects any workflow that requires network access from within a Codex session — cloud CLI tools (OCI, AWS, GCP), package registries, API calls, etc.

Environment:

• macOS (Darwin 25.2.0)
• Codex CLI installed via Homebrew (/opt/homebrew/bin/codex)
• config.toml with network_access = true under [sandbox_workspace_write]

Reproduction:

1. Set network_access = true in ~/.codex/config.toml:

   [sandbox_workspace_write]
   network_access = true

2. Launch codex and run any network command (e.g. curl https://example.com or an OCI/AWS CLI call)
3. Command fails with connection timeout / "not reachable"

Root cause: The macOS seatbelt sandbox profile (codex-rs/core/src/seatbelt_network_policy.sbpl) enforces network blocking at the OS level regardless of config.toml.

Confirmed Workaround

The only reliable fix is bypassing the seatbelt sandbox via CLI flag:

codex --sandbox danger-full-access "your prompt"

Or as a persistent shell alias:

alias codex='CODEX_SANDBOX_NETWORK_DISABLED=0 codex --sandbox danger-full-access'

Setting sandbox_mode = "danger-full-access" in config.toml alone is not sufficient — the CLI flag is required.

Proposed Fix

The seatbelt profile should respect the network_access = true configuration from config.toml the same way the Linux Landlock sandbox does. When a user explicitly opts in to network access via config, the seatbelt policy should conditionally allow outbound connections instead of unconditionally blocking them.

A potential implementation path:

1. In codex-rs/core, read network_access from the resolved config before generating the seatbelt profile
2. Conditionally include/exclude the network deny rule in seatbelt_network_policy.sbpl
3. This would make macOS behavior consistent with the documented config.toml settings

Happy to submit a PR if the team agrees with this approach.

Related Issues

• Per-project config ignored; session forced to approval_policy=on-request + sandbox=workspace-write (CODEX_SANDBOX=seatbelt) #8714 (per-project config ignored, CODEX_SANDBOX_NETWORK_DISABLED=1 forced)
• Critical: VS Code Codex extension blocks network access and returns persistent sandbox errors even with danger-full-access #5041 (VS Code extension blocks network with danger-full-access)
• network_access permission not working #3454 (network_access permission not working)
• Regression: sandbox/network enforcement breaks Codex autonomy (follow-up to incorrectly closed #5038) #5090 (sandbox/network enforcement regression)

[github-actions]

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

• Per-project config ignored; session forced to approval_policy=on-request + sandbox=workspace-write (CODEX_SANDBOX=seatbelt) #8714
• Requires permissions escalation for every network request even when network_access = true #9298
• Mcp-server has no network access even with network access flags enabled #8634

Powered by Codex Action

[fede-kamel]

Not a duplicate — those issues were closed without a workaround or root cause analysis.

This issue provides both:

1. Confirmed workaround (shell alias with --sandbox danger-full-access + CODEX_SANDBOX_NETWORK_DISABLED=0)
2. Root cause analysis of the full config → seatbelt policy flow
3. Two PRs with code contributions:
   • docs: add macOS network sandbox troubleshooting to README #10391 — README troubleshooting section so users can actually find the workaround
   • fix: add seatbelt network_access test coverage and sandbox policy tracing #10392 — Test coverage for network_access: true in the seatbelt path (unit + integration tests proving the OS-level sandbox behavior), plus tracing in derive_sandbox_policy() so users can debug why network is blocked

The integration tests in #10392 confirm the seatbelt code on main does correctly handle network_access: true — the policy includes network rules and socket creation succeeds under sandbox-exec. This means the bug users are hitting is likely a version mismatch between their installed binary and current main, or the config resolution path silently falling back to defaults (which the new tracing would surface).

The pre-existing seatbelt tests (create_seatbelt_args_with_read_only_git_and_codex_subpaths, create_seatbelt_args_with_read_only_git_pointer_file) also have a macOS /var/folders vs /private/var/folders path mismatch bug — unrelated to this issue but worth noting.

Closing this as a duplicate of issues that were themselves closed without resolution doesn't help the users still hitting this. Happy to iterate on the PRs if the team has feedback.

[jawwadfirdousi]

Can confirm the issue on Codex MacOS app as well.
The app also does not respect the setting

[fede-kamel]

Feel free to try this solving your problem. It works for me ; curious to know

[fede-kamel]

Quick follow-up after re-checking current main: the macOS seatbelt path now has substantial sandbox/network changes (including dynamic network policy and proxy-aware routing in recent sandbox PRs), which looks like it may have addressed the original network_access behavior reported here. @etraut-openai could you confirm whether this issue is now considered fixed on latest releases, or if there is still a reproducible gap for macOS users? If fixed, I can help validate and close with tested version details.

[bc-lee]

I encountered the same issue. Using MCP is an interesting option, but in my workflow I need to invoke Bazel directly. Bazel itself provides many tools such as bazel query, so agents still need to invoke bazel directly to work and to diagnose problems.

I added this to my Codex settings:

# $HOME/.codex/config.toml
[sandbox_workspace_write]
writable_roots = ["/private/var/tmp", "/var/tmp"]
# network_access = true # dangerous, do not enable

Even with that, the project still fails like this:

$ codex sandbox macos --full-auto --log-denials bazelisk build //:hello
Starting local Bazel server and connecting to it...
Server crashed during startup. Now printing /private/var/tmp/_bazel_redacted/01c67db48b5725ab953a9bd9ac1470c4/server/jvm.out
OpenJDK 64-Bit Server VM warning: Options -Xverify:none and -noverify were deprecated in JDK 13 and will likely be removed in a future release.
gRPC server failed to bind to IPv4 and IPv6 localhosts on port 0: [IPv4] Failed to bind to address /127.0.0.1:0
[IPv6] Failed to bind to address /[0:0:0:0:0:0:0:1]:0
com.google.devtools.build.lib.util.AbruptExitException: gRPC server failed to bind to IPv4 and IPv6 localhosts on port 0: [IPv4] Failed to bind to address /127.0.0.1:0
[IPv6] Failed to bind to address /[0:0:0:0:0:0:0:1]:0
	at com.google.devtools.build.lib.server.GrpcServerImpl.serve(GrpcServerImpl.java:430)
	at com.google.devtools.build.lib.runtime.BlazeRuntime.serverMain(BlazeRuntime.java:1066)
	at com.google.devtools.build.lib.runtime.BlazeRuntime.main(BlazeRuntime.java:770)
	at com.google.devtools.build.lib.bazel.Bazel.main(Bazel.java:96)
Caused by: java.io.IOException: Failed to bind to address /127.0.0.1:0
	at io.grpc.netty.NettyServer.start(NettyServer.java:328)
	at io.grpc.internal.ServerImpl.start(ServerImpl.java:183)
	at io.grpc.internal.ServerImpl.start(ServerImpl.java:92)
	at com.google.devtools.build.lib.server.GrpcServerImpl.serve(GrpcServerImpl.java:427)
	... 3 more
Caused by: java.net.SocketException: Operation not permitted
	at java.base/sun.nio.ch.Net.bind0(Native Method)
	at java.base/sun.nio.ch.Net.bind(Unknown Source)
	at java.base/sun.nio.ch.ServerSocketChannelImpl.netBind(Unknown Source)
	at java.base/sun.nio.ch.ServerSocketChannelImpl.bind(Unknown Source)
	at io.netty.channel.socket.nio.NioServerSocketChannel.doBind(NioServerSocketChannel.java:141)
	at io.netty.channel.AbstractChannel$AbstractUnsafe.bind(AbstractChannel.java:562)
	at io.netty.channel.DefaultChannelPipeline$HeadContext.bind(DefaultChannelPipeline.java:1334)
	at io.netty.channel.AbstractChannelHandlerContext.invokeBind(AbstractChannelHandlerContext.java:600)
	at io.netty.channel.AbstractChannelHandlerContext.bind(AbstractChannelHandlerContext.java:579)
	at io.netty.channel.DefaultChannelPipeline.bind(DefaultChannelPipeline.java:973)
	at io.netty.channel.AbstractChannel.bind(AbstractChannel.java:260)
	at io.netty.bootstrap.AbstractBootstrap$2.run(AbstractBootstrap.java:356)
	at io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:174)
	at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:167)
	at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:470)
	at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:569)
	at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997)
	at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
	at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
	at java.base/java.lang.Thread.run(Unknown Source)

=== Sandbox denials ===
(bazel) mach-lookup com.apple.logd
(bazel) mach-lookup com.apple.distributed_notifications@Uv3
(bazel) mach-lookup com.apple.CoreServices.coreservicesd
(bazel) mach-lookup com.apple.DiskArbitration.diskarbitrationd
(daemonize) sysctl-read security.mac.lockdown_mode_state
(daemonize) sysctl-read kern.bootargs
(daemonize) file-write-data /dev/dtracehelper
(java) sysctl-read security.mac.lockdown_mode_state
(java) sysctl-read kern.bootargs
(java) file-write-data /dev/dtracehelper
(java) mach-lookup com.apple.system.notification_center
(java) mach-lookup com.apple.logd
(java) mach-lookup com.apple.system.opendirectoryd.membership
(java) mach-lookup com.apple.bsd.dirhelper
(java) mach-lookup com.apple.SystemConfiguration.configd
(java) network-outbound /private/var/run/mDNSResponder
(java) network-bind local:*:0

I am not an expert on Seatbelt, but it seems like Codex could potentially support an option to allow binding to a local port. That would not weaken security very much, but it would make Bazel work in this setup. I am not sure whether this is feasible, but it would be great if Codex could support it. Thanks.

[robertpatrick]

It seems pretty non-intuitive to configure workspace-write mode but, on the Mac, silently ignore that setting and change to seatbelt mode. If seatbelt mode is desirable, it seems like I should be able to disable it without resorting to danger-full-access mode.