codex-network-proxy doesn't work with exec and interactive mode

What version of Codex CLI is running?

0.117.0

What subscription do you have?

Plus

Which model were you using?

pt-5.3-codex

What platform is your computer?

Darwin 25.3.0 arm64 arm

What terminal emulator and version are you using (if applicable)?

iTerm2

What issue are you seeing?

First of all, thank you for working on Codex which I use every single day. It's a great tool and it makes my life so much easier and productive.

I've been testing ways to restrict the network egress with Codex and found some documentation within https://github.com/openai/codex/tree/main/codex-rs/network-proxy.

I have tested locally with the following ~/.codex/config.toml ( after a lot of troubleshooting to get the right config entries ):

model = "gpt-5.3-codex"
model_reasoning_effort = "medium"
personality = "pragmatic"

default_permissions = "workspace"

[sandbox_workspace_write]
network_access = true

[permissions.workspace.filesystem]
":minimal" = "read"

[permissions.workspace.filesystem.":project_roots"]
"." = "write"

[permissions.workspace.network]
enabled = true
proxy_url = "http://127.0.0.1:3128"
# SOCKS5 listener (enabled by default).
enable_socks5 = true
socks_url = "http://127.0.0.1:8081"
enable_socks5_udp = true
# When `enabled` is false, the proxy no-ops and does not bind listeners.
# When true, respect HTTP(S)_PROXY/ALL_PROXY for upstream requests (HTTP(S) proxies only),
# including CONNECT tunnels in full mode.
allow_upstream_proxy = true
# By default, non-loopback binds are clamped to loopback for safety.
# If you want to expose these listeners beyond localhost, you must opt in explicitly.
dangerously_allow_non_loopback_proxy = false
mode = "full" # default when unset; use "limited" for read-only mode
# When true, HTTPS CONNECT can be terminated so limited-mode method policy still applies.
mitm = false
# CA cert/key are managed internally under $CODEX_HOME/proxy/ (ca.pem + ca.key).

# If false, local/private networking is rejected. Explicit allowlisting of local IP literals
# (or `localhost`) is required to permit them.
# Hostnames that resolve to local/private IPs are still blocked even if allowlisted.
allow_local_binding = false

# DANGEROUS (macOS-only): bypasses unix socket allowlisting and permits any
# absolute socket path from `x-unix-socket`.
dangerously_allow_all_unix_sockets = false

allowed_domains = ["*.openai.com", "localhost", "127.0.0.1", "::1"]

Now running the following command gives the expected output:

codex sandbox macos -- /bin/zsh -lc 'curl -vvv https://www.google.com'
* Uses proxy env variable no_proxy == 'localhost,127.0.0.1,::1,*.local,.local,169.254.0.0/16,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16'
* Uses proxy env variable https_proxy == 'http://127.0.0.1:54888'
*   Trying 127.0.0.1:54888...
* Connected to 127.0.0.1 (127.0.0.1) port 54888
* CONNECT tunnel: HTTP/1.1 negotiated
* allocate connect buffer
* Establish HTTP proxy tunnel to www.google.com:443
> CONNECT www.google.com:443 HTTP/1.1
> Host: www.google.com:443
> User-Agent: curl/8.7.1
> Proxy-Connection: Keep-Alive
>
< HTTP/1.1 403 Forbidden
< content-type: text/plain
< x-proxy-error: blocked-by-allowlist
< content-length: 83
< date: Mon, 30 Mar 2026 11:20:40 GMT
<
* CONNECT tunnel failed, response 403
* Closing connection
curl: (56) CONNECT tunnel failed, response 403

but running codex interactively or through codex exec using the -s workspace-write flag on both does not seem to make use of the internal managed-proxy. The connection to https://www.google.com results in a 200 and is not denied.

Is that expected or am I doing something wrong here?

I also think that this feature's documentation should be easier to find on your official website with a clear example on how to enable this feature through the config.toml other than the one contained within the link that I have shared above.

What steps can reproduce the bug?

codex sandbox macos -- /bin/zsh -lc 'curl -vvv https://www.google.com'

codex -s workspace-write exec --skip-git-repo-check 'run curl -I https://www.google.com'

What is the expected behavior?

I expected all the commands to deny access to https://www.google.com.

Additional information

_No response_