Codex Says "No Route to Host" on Your Mac LAN? Fix Local Network Access

If Codex Desktop returns No route to host for a private IP that works from Terminal, check the macOS permission attached to the parent ChatGPT app. Open System Settings → Privacy & Security → Local Network, enable ChatGPT, fully quit and reopen the app, then repeat the same connection test in a new Codex task.

That fix applies to a specific pattern: Terminal reaches the LAN host, Codex does not, and Codex already has task-level network access. If Terminal also fails, the problem is more likely the service, route, firewall, VPN, or address. Use the checks below before changing either machine.

Confirm the Exact Failure Before Changing Settings

You need a LAN host and port you are authorized to test. Replace 192.168.1.11 and 22 with that known address and service.

First run this in Terminal:

nc -vz -w 3 192.168.1.11 22

Expected result when the route and service work:

Connection to 192.168.1.11 port 22 [tcp/ssh] succeeded

Now ask Codex Desktop to run the identical command in the affected task. The macOS Local Network permission failure can look like this:

nc: connectx to 192.168.1.11 port 22 (tcp) failed: No route to host

The mismatch is the useful signal. Apple documents that command-line tools launched from Terminal are automatically allowed local-network access, while another app can remain blocked until the user grants its Local Network privilege. A successful Terminal test therefore does not prove the Codex host app has permission.

If both commands fail, skip to the decision table. Enabling an unrelated permission will not repair a stopped service or a bad route.

Enable ChatGPT Under Local Network

On the affected Mac:

1. Open System Settings.

2. Select Privacy & Security.

3. Open Local Network.

4. Enable ChatGPT.

5. Fully quit ChatGPT, reopen it, and create a new Codex task.

6. Repeat the exact nc command.

Why does the setting say ChatGPT instead of Codex? Current Codex work runs inside the ChatGPT desktop app. Apple attributes a helper process's network operation to the responsible parent application and records the permission for that app. In the public Codex reproduction, switching on ChatGPT immediately restored ICMP, TCP, and HTTP access without changing the Codex sandbox profile.

Do not use a different target for the second test. The before-and-after result is only meaningful when the IP address, port, network interface, and command stay the same.

Verify With the Protocol You Actually Need

Once the TCP probe succeeds, test the real protocol without sending secrets. For a local HTTP service:

curl --connect-timeout 3 --max-time 5 \
  -o /dev/null -sS -w 'HTTP %{http_code}\n' \
  http://192.168.1.11:8000/health

Useful outcomes include:

• HTTP 200: the route and endpoint are working.

• HTTP 401 or HTTP 403: the route works; authentication or authorization is the next layer.

• Connection refused: the host answered, but nothing is listening on that port.

• No route to host or HTTP 000: transport still fails before an application response.

An expected 401 is a connectivity success, not an authentication success. Do not paste a token into the command just to prove the route.

For SSH, stop after nc proves the port is reachable unless you intend to start an authorized session. For a local model server, use its harmless health or version endpoint. The Ollama network API guide shows a complete port 11434 verification flow.

Separate the Two Permission Layers

Codex task permissions and macOS Local Network privacy answer different questions:

The task can report network access as enabled while macOS still rejects LAN traffic. That is why increasing the Codex permission profile alone may not help.

Apple's local-network privacy technote also explains the Terminal difference: Terminal-launched command-line tools receive a macOS exception, while app-launched helpers are attributed to their responsible app. This makes the same command a clean diagnostic when it succeeds in Terminal and fails only inside Codex Desktop.

Use This Decision Table When the Toggle Does Not Fix It

If ChatGPT is not listed under Local Network, launch the app in the foreground and attempt one connection to a known LAN address. Apple says the operating system adds an app to this list after it attempts a local-network operation. Do not repeatedly reset privacy databases or modify system-wide network exemptions for an ordinary workstation workaround.

Avoid Risky False Fixes

Do not solve this client-side permission problem by weakening the server side:

• Do not turn off the Mac firewall just to test one outbound connection.

• Do not expose a private service to the public internet.

• Do not change a service from loopback to 0.0.0.0 unless LAN clients genuinely need it and you also configure authentication and host-firewall rules.

• Do not disable certificate verification for a production HTTPS endpoint.

• Do not pin an old desktop build indefinitely without a supported update plan.

The Local Network toggle grants the ChatGPT app access to nearby devices. Review that scope before enabling it on a managed or sensitive network, and revoke it when the workflow no longer needs LAN access.

Report a Reproducible Desktop Regression

If permission is enabled and the same numeric-IP probe still fails only in Codex, collect a small comparison:

macOS version:
ChatGPT/Codex desktop build:
network interface: Wi-Fi or Ethernet
target: private IP and non-sensitive port
Terminal result:
Codex result:
ChatGPT Local Network toggle: enabled
VPN or proxy: on/off

Do not include SSH keys, API tokens, cookies, private repository paths, or packet contents. A before-and-after matrix is more useful than a general statement that networking is broken. The public Codex reports that identified this permission layer used the same target and command in Terminal and Codex, then verified that the permission change restored the expected TCP and HTTP response.

Use a Managed Action for SaaS Instead of a Private LAN Route

If the real destination is GitHub, Notion, Google Drive, Slack, or another public SaaS provider, an agent may not need a private-network connection at all. Aident Loadout lets Codex discover a named Action, keep the provider credential in Aident Vault, inspect the input and cost, and execute the approved operation.

This is not a tunnel into your LAN and will not reach a private NAS, development server, or local model. It is a separate managed path for supported cloud services.

If the aident command is not installed, tell your coding agent: Follow https://aident.ai/SETUP.md.

Then verify one read-only Action from a trusted terminal:

aident account auth status
aident vault vault --action status
aident capabilities search \
  --query 'read-only Action for <your SaaS task>' \
  --types action

Inspect the selected Action before execution:

aident capabilities get <action-name>
aident capabilities preflight <action-name> --input '<reviewed-json-object>'

Expected result: authentication is ready, the Action contract identifies the provider and risk, and preflight validates the reviewed input with zero or disclosed credits. Ready to test that path? Set up Aident Loadout and preflight one read-only Action.

Sources

• Apple: Control access to your local network on Mac

• Apple TN3179: Understanding local network privacy

• OpenAI Codex issue 36962: Desktop does not request or diagnose required macOS Local Network permission

• OpenAI Codex issue 36891: Desktop blocks one LAN destination while allowing another

• Reddit: Every other Codex app update breaks local network permissions on macOS

• OpenAI: ChatGPT Work and Codex

Review this article after OpenAI changes the ChatGPT/Codex desktop packaging or permission flow, Apple changes macOS Local Network privacy, issue 36962 closes, or the upstream app begins displaying an actionable permission diagnostic.