Codex Desktop blocks one LAN destination while allowing another on macOS

What version of the Codex App are you using (From “About Codex” dialog)?

26.727.51351 (build 6119), bundled codex-cli 0.146.0-alpha.9.2

What subscription do you have?

Plus

What platform is your computer?

Darwin 25.6.0 arm64 arm

What issue are you seeing?

Codex Desktop blocks traffic to one LAN host while allowing another host on the same subnet through the same interface.

Commands executed by Codex Desktop produce:

$ nc -vz -w 3 192.168.1.11 22
nc: connectx to 192.168.1.11 port 22 (tcp) failed: No route to host

$ curl -kS --connect-timeout 3 --max-time 5 \
    -o /dev/null -w 'HTTP %{http_code}\n' \
    https://192.168.1.11:8006/api2/json/version
curl: (7) Failed to connect to 192.168.1.11 port 8006 after 1 ms: Couldn't connect to server
HTTP 000

$ nc -vz -w 3 192.168.1.20 22
Connection to 192.168.1.20 port 22 [tcp/ssh] succeeded!

Both destinations are reachable from Terminal. Both are also reachable when either Codex runtime is explicitly executed under a Codex Seatbelt sandbox from Terminal.

The problem occurs in new Codex Desktop tasks and across different repositories.

What steps can reproduce the bug?

1. Use two reachable hosts on the same private subnet. Here they are 192.168.1.11 and 192.168.1.20.

1. Confirm both from Terminal:

nc -vz -w 3 192.168.1.11 22
nc -vz -w 3 192.168.1.20 22

Both connections succeed.

1. Run both Codex runtimes explicitly under Codex Seatbelt from Terminal:

for bin in \
  /opt/homebrew/bin/codex \
  /Applications/ChatGPT.app/Contents/Resources/codex
do
  echo "=== $bin ==="
  "$bin" --version
  "$bin" sandbox -C "$PWD" -P lab --log-denials -- \
    /bin/zsh -c '
      env | grep "^CODEX_SANDBOX="
      nc -vz -w 3 192.168.1.11 22
      nc -vz -w 3 192.168.1.20 22
      curl -kS --connect-timeout 3 -o /dev/null \
        -w "HTTPS status: %{http_code}\n" \
        https://192.168.1.11:8006/api2/json/version
    '
done

Both runtimes report:

CODEX_SANDBOX=seatbelt
Connection to 192.168.1.11 port 22 succeeded
Connection to 192.168.1.20 port 22 succeeded
HTTPS status: 401

The HTTP 401 is expected without credentials and confirms connectivity.

1. Ask Codex Desktop to run equivalent probes:

ping -c 2 -W 1000 192.168.1.11
nc -vz -w 3 192.168.1.11 22
curl -kS --connect-timeout 3 --max-time 5 \
  -o /dev/null -w 'HTTPS status: %{http_code}\n' \
  https://192.168.1.11:8006/api2/json/version

ping -c 2 -W 1000 192.168.1.20
nc -vz -w 3 192.168.1.20 22

Desktop results:

192.168.1.11: No route to host / HTTPS status 000
192.168.1.20: ICMP and TCP/22 succeed

1. Start a packet capture from Terminal:

sudo tcpdump -ni en7 \
  '(host 192.168.1.11 or host 192.168.1.20) and (icmp or tcp port 22 or tcp port 8006)'

1. Repeat the probes from Codex Desktop.

The capture contains ICMP traffic and a completed TCP handshake for 192.168.1.20, but no packets for 192.168.1.11. The failing request is rejected locally before reaching the network interface.

Session ID: 019f6017-1596-7370-bfac-e259a1514700

What is the expected behavior?

Codex Desktop should permit both destinations when the effective task permissions report network access as enabled.

Its behavior should match an explicit codex sandbox invocation using the same permission profile.

If an additional Desktop-specific policy blocks a destination, Codex should expose the effective policy and denial reason instead of returning an unexplained No route to host.

Additional information

Diagnostics performed:

• The Desktop command environment reports CODEX_SANDBOX=seatbelt and CODEX_PERMISSION_PROFILE=lab.
• Persisted task metadata reports "network":"enabled".
• Explicitly binding the failing commands to Ethernet and its source address does not change the result.
• The same interface and source address successfully reach 192.168.1.20.
• No relevant Seatbelt network denial appears in macOS logs.
• The app's Info.plist does not contain NSLocalNetworkUsageDescription.
• A third-party transparent-proxy extension was disabled and Codex restarted; behavior was unchanged.
• Homebrew CLI 0.146.0 and bundled runtime 0.146.0-alpha.9.2 reach both destinations when launched under codex sandbox from Terminal.
• Tcpdump confirms Codex Desktop emits no packets for the blocked destination.

This appears specific to an additional Codex Desktop execution layer rather than the repository permission profile or standard Codex Seatbelt sandbox.

This may be related to #35346, but this case is destination-specific rather than blocking all LAN access.