[BUG] Local Network access silently denied for CLI due to Mach-O UUID collision with "Claude Code URL Handler.app" (macOS)

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

(Claude desktop diagnosed this and wrote the report.)

Local Network access silently denied for CLI due to Mach-O UUID collision with "Claude Code URL Handler.app" (macOS)

Environment

• Claude Code 2.1.267, installed via Homebrew cask (/opt/homebrew/Caskroom/claude-code/2.1.267/claude)
• macOS 27.0
• Terminal: iTerm2 (has Local Network permission)

Summary

The Claude Code CLI binary and the auto-created ~/Applications/Claude Code URL Handler.app contain executables with the same Mach-O UUID. macOS Local Network privacy uses the executable UUID to resolve identity, so the two bundle IDs (com.anthropic.claude-code and com.anthropic.claude-code-url-handler) get conflated. Once a Local Network denial was recorded for the CLI identity, there was no way to reverse it:

• System Settings → Privacy & Security → Local Network shows "Claude Code URL Handler" (enabled) but no entry for com.anthropic.claude-code, so there is nothing to toggle.
• tccutil reset LocalNetwork com.anthropic.claude-code fails, because Local Network isn't a TCC service.
• Reinstalling via Homebrew doesn't help, because the binary (and UUID) is identical.

Symptoms

• Mid-session, a macOS permission popup appeared and was accidentally dismissed (most likely denying it). The trigger is unknown; the handler app and its binary were both created two days earlier.
• From then on, connections from Claude Code (including Bash-tool subprocesses such as curl) to one host on the local subnet failed instantly with No route to host. Another host on the same subnet remained reachable.
• The same connections from iTerm2 directly succeeded. No proxy variables were set, and no third-party firewall is installed.

Evidence

Matching UUIDs:
$ dwarfdump --uuid /opt/homebrew/Caskroom/claude-code/2.1.267/claude
UUID: 4C4C4401-5555-3144-A13C-E92490FFBCBC (arm64)
$ dwarfdump --uuid "~/Applications/Claude Code URL Handler.app/Contents/MacOS/claude"
UUID: 4C4C4401-5555-3144-A13C-E92490FFBCBC (arm64)

The nehelper / UserEventAgent log during a failed connection shows the PID resolving to one bundle ID and the UUID to the other, and the preference check running against the URL Handler (allowed) while the connection stays blocked:
Got local network blocked notification: pid: 81670, uuid: 4C4C4401-5555-3144-A13C-E92490FFBCBC, bundle_id: (null)
LocalNetwork: found bundle id com.anthropic.claude-code by PID
LocalNetwork: found bundle id com.anthropic.claude-code-url-handler by UUID 4C4C4401-...
Local network allowed by preference for Claude Code URL Handler (com.anthropic.claude-code-url-handler)

Workaround

Moving Claude Code URL Handler.app to the Trash and rebooting restored local network access for the CLI.

Suggested fix

Make sure the URL handler's executable has a distinct Mach-O UUID from the CLI binary (e.g. a separate small launcher binary rather than a copy of claude), so macOS privacy subsystems don't conflate the two identities.

What Should Happen?

See above

Error Messages/Logs

Steps to Reproduce

It's not clear how it got into this state.

Claude Model

No response

Is this a regression?

I don't know

Last Working Version

No response

Claude Code Version

2.1.267

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

iTerm2

Additional Information

No response

Start by inspecting how ~/Applications/Claude Code URL Handler.app/Contents/MacOS/claude is created from the CLI at /opt/homebrew/Caskroom/claude-code/2.1.267/claude, then compare their Mach-O UUIDs with dwarfdump. Done means the URL handler and CLI have distinct UUIDs and the CLI can access the local network without the identities being conflated.