[BUG] macOS: Local Network permission is lost on every auto-update (versioned claude.app bundle path); 20+ stale permission rows accumulate

Preflight Checklist

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

What's Wrong?

On macOS, the desktop app's Claude Code helper is installed at a versioned bundle path:

~/Library/Application Support/Claude/claude-code/<version>/claude.app

macOS's Local Network privacy system registers the grant against that specific bundle path. Every auto-update installs a new versioned bundle and deletes the old one, with two consequences:

1. The Local Network grant is lost on every update. The freshly installed claude.app has no grant, so LAN unicast from Claude's shell starts failing with sendto: No route to host / EHOSTUNREACH until the user notices, finds the new prompt or row, and re-toggles it. The gateway and internet stay reachable (that is how the Local Network gate works), VPN/tunnel interfaces (e.g. Tailscale utun) are unaffected, and every other app on the machine keeps LAN access - which makes this very easy to misdiagnose as a router or network fault. It can also strike mid-session, at the moment the helper context changes during an update.
2. Stale permission rows accumulate. System Settings -> Privacy & Security -> Local Network on this machine currently shows 20+ rows all named claude.app, most with a generic blank icon because the bundle behind them no longer exists. Only ONE versioned bundle is actually on disk right now (.../claude-code/2.1.246/claude.app). There is no per-row delete UI in System Settings, so the list only ever grows.

The code signing identity is stable across versions, so the churn is purely the install path:

Identifier=com.anthropic.claude-code
Authority=Developer ID Application: Anthropic PBC (Q6L2SF6YDW)
TeamIdentifier=Q6L2SF6YDW
flags=0x10000(runtime)

Earlier on this machine the permission registry showed the grant bound to .../claude-code/2.1.217/claude.app while the installed app had already moved on many versions - the grant simply never follows the update.

Related but distinct issues, for cross-reference:

• #74378 - the bare un-bundled CLI binary cannot register for Local Network at all (missing Info.plist). This report is the complementary desktop-app case: the helper IS a proper signed bundle and registers fine, but its identity-by-path churns every release.
• #88146 - desktop app SSH EHOSTUNREACH on the local subnet; plausibly the same underlying permission state.
• #74831 (closed, area:packaging) - permission prompts showing the version number instead of "Claude Code"; a cosmetic symptom of the same versioned-bundle design.
• #80072 - silently-denied Local Network permission breaking daemon-spawned sessions.

Steps to Reproduce

1. On macOS 15+ (observed on macOS 26.x), run the Claude desktop app with Claude Code, and have a session touch any LAN host (e.g. ssh 192.168.x.x via the Bash tool) so the Local Network prompt fires; grant it.
2. Let the app auto-update (new ~/Library/Application Support/Claude/claude-code/<new-version>/claude.app is installed, old one removed).
3. Have a session touch the same LAN host again.

Result: No route to host / EHOSTUNREACH from Claude's processes only; a NEW Local Network row/prompt appears for the new bundle; the old row remains as a dead entry. Repeat per release - after months of updates the panel holds 20+ dead claude.app rows.

Expected: the Local Network grant survives updates (stable helper location, or LAN traffic routed through a stable parent/XPC helper so the grant binds to something that persists), and dead rows are not left behind.

Suggested Direction

Since Identifier and TeamIdentifier are already stable, keeping the permission-bearing bundle at a stable, versionless path (or holding the Network-framework/LAN-touching activity in the stable parent app or a stable helper bundle, as sibling issue #74378 also proposes for the CLI) should let the grant persist across updates and stop the row accumulation.

Environment

• macOS 26.6.2 (build 25G83), Apple Silicon (M3)
• Claude desktop app with Claude Code helper 2.1.246 (~/Library/Application Support/Claude/claude-code/2.1.246/claude.app)
• Observed repeatedly since at least May 2026 across many app versions (grant re-lost after updates; independently re-diagnosed on this machine at least three times)