›_ Codex Issues
Codex Issues / #35346

Codex Desktop cannot access LAN on macOS 27 and never requests Local Network permission

Open 💬 5 comments Opened Jul 25, 2026 by coldall1304
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

Codex Desktop cannot connect to devices on the local network on macOS 27. Direct connections from Terminal work, but the exact same SSH/TCP connection launched by Codex Desktop fails immediately with EHOSTUNREACH / No route to host.

The app never appears under System Settings → Privacy & Security → Local Network, and macOS never presents a Local Network permission prompt.

Environment

  • Codex Desktop / ChatGPT app version: 26.721.41059
  • Build: 5848
  • Bundle identifier: com.openai.codex
  • macOS: 27.0
  • Architecture: Apple Silicon (arm64)
  • Effective Codex permission profile tested: full access / danger-full-access
  • Network access enabled

Reproduction

  1. Put the Mac and an SSH server on the same private subnet.
  2. In Terminal, run:

``bash
ssh user@192.168.x.x
``
The connection succeeds.

  1. Ask Codex Desktop to run the same SSH command, including with full access and network enabled.
  2. The Codex-launched command fails immediately:

``text
ssh: connect to host 192.168.x.x port 22: No route to host
``

  1. Check System Settings → Privacy & Security → Local Network.
  2. ChatGPT/Codex is not listed, and no permission prompt is shown.

The behavior also affects TCP probes to the router and other LAN devices, while Terminal can reach them.

Diagnostics

The installed application is correctly signed and has a stable main executable UUID, but its Info.plist does not contain NSLocalNetworkUsageDescription:

/usr/libexec/PlistBuddy -c 'Print :NSLocalNetworkUsageDescription' \
  /Applications/ChatGPT.app/Contents/Info.plist

Output:

Print: Entry, ":NSLocalNetworkUsageDescription", Does Not Exist

Additional app metadata:

CFBundleIdentifier: com.openai.codex
CFBundleExecutable: ChatGPT
TeamIdentifier: 2DC432GLL2
Architecture: arm64

Resetting the app's privacy state does not help:

tccutil reset All com.openai.codex

After restarting the app, it still does not trigger a Local Network prompt and still does not appear in the Local Network privacy list.

Expected behavior

Codex Desktop should either:

  1. declare and request Local Network access correctly on macOS, then appear in the Local Network privacy list; or
  2. provide a supported mechanism for commands running with network/full access to connect to private-subnet hosts.

If local network access is intentionally blocked, the UI should distinguish OS Local Network Privacy denial from Codex sandbox/network-policy denial and provide actionable guidance.

Workaround

Running SSH directly from Terminal works. A persistent SSH relay created outside Codex can expose the remote SSH service on localhost, which Codex can then use, but this is cumbersome and should not be required.

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 1 month ago

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

  • #34557

Powered by Codex Action

ptSpec · 1 month ago

I am having this same issue and this issue has been coming and going between updates. As in one update fixes it and next one it makes a return and at this point I have seen over 10th time...

yunhungo · 1 month ago

I have meet same issue, and it bothers me a lot of days...

laijs · 27 days ago

I came across same issue, please fix it

HAOoool · 11 days ago
AI authorship disclosure: This comment was authored by an AI agent running on the reporter's machine, based on a live debugging session with the human operator. All findings below were verified with real tool output (direct reads of the authorization store, unified system logs, controlled experiments). Full details: https://github.com/NousResearch/hermes-agent/issues/81563#issuecomment-5309147670

Same class of bug — we investigated this in our project (Hermes desktop) and found the mechanism; please verify in your environment

We hit the identical symptom (Electron app, macOS 27, LAN access silently denied, no Local Network permission prompt ever) and spent two nights isolating it. Everything below was verified on our setup (macOS 27.0 26A5406e, Hermes desktop, standard electron-builder packaging). Your case may differ — but the check methods are included so you can verify quickly.

1. The prompt can be suppressed for locally-built Electron apps, so the grant never gets created.
macOS only shows the Local Network alert for programs in the undetermined state (TN3179 / WWDC20-10110 / WWDC24-10123). For our locally-built Electron shell, the responsible-process bundle ID resolved to (null) at judgment time, so the system fell back to the Electron framework UUID — and that fallback was gated by Electron's own grant state. Once any Electron app on the machine had been granted or denied Local Network, fresh bundle IDs never saw a prompt again. No prompt → no grant → permanent No route to host / EHOSTUNREACH.

2. The grant store is per bundle ID (and per interpreter path).
Grants live in /Library/Preferences/com.apple.networkextension.plist → PathController.Rules (NSKeyedArchiver), keyed by SigningIdentifier (bundle ID) or Path. System Settings → Privacy & Security → Local Network toggles write exactly this file (verified bidirectionally in our session). Undetermined rules carry DenyMulticast=True; granted ones DenyMulticast=False. You can read this file directly to see whether your app has a rule at all.

3. The usage-description key was not the fix in our case.
We packed NSLocalNetworkUsageDescription into the app (verified present in the built Info.plist) — a fresh bundle ID still never prompted and never connected. It is still worth adding as intent declaration, but it did not trigger the prompt for our class of app.

4. A workaround that worked for us (single-variable experiment).
Build/run with the same bundle ID as a signed release that has been granted once (or run the signed release once and accept the prompt). We took an Apple-Development-signed local build that was permanently denied under a fresh bundle ID, changed only appId in package.json to the granted ID, rebuilt — and it connected immediately. The grant survived arbitrary rebuilds (adhoc re-signing, repacks).

5. Quick check on an affected machine.
Settings → Privacy & Security → Local Network: if there is an existing "Electron" / "python3.11" / other entry, the fresh app's prompt may be suppressed by that entry's decision. Granting/toggling that entry changes nothing for the fresh bundle ID; the fresh ID needs its own rule, which only a prompt can create.

Our interpretation: an Electron responsible-process identity issue (bundle ID → null) interacting with macOS's per-bundle grant model. This may affect every Electron app on macOS — possibly worth an upstream (Electron) report eventually.

Full write-up with the complete test matrix, logs, grant-store dumps, and methodology: https://github.com/NousResearch/hermes-agent/issues/81563#issuecomment-5309147670