macOS: local network access stays blocked after denying the first prompt, even with the permission enabled in System Settings

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

26.707.71524 (build 5263)

What subscription do you have?

Pro

What platform is your computer?

Darwin 27.0.0 arm64 arm (macOS 27.0 beta, build 26A5378j)

What issue are you seeing?

I denied the macOS local network permission prompt once, and now the app can't reach anything on my LAN anymore — permanently, as far as I can tell. Turning ChatGPT/Codex back on under System Settings → Privacy & Security → Local Network doesn't help. Neither does restarting the app, rebooting, reinstalling, or updating. The toggle says enabled, but LAN traffic from the app still fails:

PING 192.168.68.1 (192.168.68.1): 56 data bytes
ping: sendto: No route to host
Request timeout for icmp_seq 0

The route itself is fine, and the same address is reachable from Terminal.app, so Wi-Fi/gateway are not the problem:

route to: 192.168.68.1
destination: 192.168.68.1
interface: en0
flags: <UP,HOST,DONE,LLINFO,WASCLONED,IFSCOPE,IFREF,ROUTER>

Note this is not the same problem as #28024. That one is about the app never prompting because NSLocalNetworkUsageDescription is missing. In my case the prompt did show up at some point, I clicked "Don't Allow", and the app has been stuck in the denied state ever since.

What steps can reproduce the bug?

1. Launch the app and do something that touches a LAN address, so macOS shows the Local Network permission dialog.
2. Click "Don't Allow".
3. Go to System Settings → Privacy & Security → Local Network and turn the toggle for ChatGPT/Codex back on.
4. Quit the app completely and reopen it.
5. Try a LAN address again, e.g. ping 192.168.68.1.

Rebooting, reinstalling the same build, and updating to a newer one don't change anything.

What is the expected behavior?

Once the toggle is turned back on, the app should get LAN access again on its next attempt. If the OS still reports localNetworkDenied at that point, I'd expect the app to say so, rather than acting like the hosts are simply unreachable.

Additional information

App bundle: /Applications/ChatGPT.app, bundle ID com.openai.codex.

What I found digging into it

The shipping app bundle still has no NSLocalNetworkUsageDescription (same as #28024).

The NetworkExtension preference record for the app's identity kept the original denial, even while System Settings showed the permission as enabled:

SigningIdentifier: com.openai.codex
Path: /Applications/ChatGPT.app/Contents/MacOS/ChatGPT
DenyMulticast: true
MulticastPreferenceSet: true

tccutil reset is no use here, since local network privacy isn't managed by TCC.

Isolation test

To confirm it's the identity that's stuck, I made a temporary copy of the app with a brand-new bundle ID, an NSLocalNetworkUsageDescription string, an ad-hoc signature, and the same executable path under /Applications/ChatGPT.app.

With the new identity, macOS showed a fresh prompt. I clicked Allow, the new preference record came back with DenyMulticast: false, and once the full app ran under that identity, LAN access just worked:

5 packets transmitted, 5 packets received, 0.0% packet loss

So the original com.openai.codex identity is stuck in its first denied state — at least in my testing, updating the app never got macOS to re-evaluate it. Obviously changing the bundle ID and breaking the official signature isn't something end users should have to do.

The Apple side of this

To be fair, part of this is an OS problem. Apple's TN3179 says there's no supported way to reset an app's local network privilege back to "undetermined" (they track it as FB14944392):

https://developer.apple.com/documentation/technotes/tn3179-understanding-local-network-privacy

But the same technote says users can change the permission later in System Settings — and that supported path is exactly what's not working here: the toggle shows enabled while the active preference record and the actual network behavior stay denied.

Apple also notes that multiple versions/identities of the same app can confuse local network privacy (FB15568200). Forum threads with people hitting the same wall:

• https://developer.apple.com/forums/thread/766270
• https://developer.apple.com/forums/thread/769037

What would help from the app side

• Ship NSLocalNetworkUsageDescription in the macOS build (#28024 asks for this too).
• Detect the denied state (localNetworkDenied) and surface something actionable, instead of failing silently with unreachable hosts.
• Verify that Sparkle/in-app updates don't leave stale or mismatched responsible-code identities behind, and cover the deny → enable in System Settings → relaunch path in release testing.

Happy to pull more diagnostics off this machine if that helps.