[BUG] macOS: Network volume permission prompt appears on every update (TCC grants tied to versioned binary path)

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?

Every time Claude Code auto-updates, macOS shows a permission popup:
> "2.1.119 would like to access files on a network volume."

Clicking Allow fixes it temporarily, but the prompt returns with the next
update. After a week of updates I had 4 separate permission entries
accumulating in System Settings → Privacy & Security.

## Root Cause

Claude Code installs each version as a standalone binary at a versioned path:
~/.local/share/claude/versions/2.1.116
~/.local/share/claude/versions/2.1.117
~/.local/share/claude/versions/2.1.119
with ~/.local/bin/claude as a symlink to the current version.

macOS TCC (Transparency, Consent, and Control) grants permissions per
resolved binary path, not per symlink. So every update produces a new binary
at a new path, which macOS treats as an entirely new application requiring
fresh permission grants. The symlink is irrelevant — macOS resolves it to the
real path before checking TCC.

This can be confirmed in the TCC database:
kTCCServiceSystemPolicyNetworkVolumes | ~/.local/share/claude/versions/2.1.116
| allowed
kTCCServiceSystemPolicyNetworkVolumes | ~/.local/share/claude/versions/2.1.117
| allowed
kTCCServiceSystemPolicyNetworkVolumes | ~/.local/share/claude/versions/2.1.119
| allowed

Each version gets its own entry. Granting permission to one version does
nothing for the next.

## Expected Behavior
Permission granted once should persist across updates.

## Suggested Fix

Ship a stable launcher binary at a fixed path (e.g.
~/.local/bin/claude-launcher) that never changes between versions and exec's
the current versioned binary. TCC would grant permission to the launcher
once, permanently.

This is how most self-updating CLI tools handle it. The Electron desktop app
already does it correctly via its bundle ID (com.anthropic.claudefordesktop)
— the CLI just needs the same treatment.

## Environment

• macOS (Darwin 25.4.0)
• Claude Code 2.1.119
• Networked NAS volumes mounted via SMB

What Should Happen?

## Expected Behavior
Permission granted once should persist across updates.

Error Messages/Logs

Steps to Reproduce

1. Install Claude Code CLI (not the desktop app) on macOS with network volumes

mounted (e.g. NAS via SMB)

1. Use Claude Code normally — it will prompt "2.1.x would like to access files

on a network volume" and you click Allow

1. Wait for Claude Code to auto-update (happens every few days)
2. The prompt appears again for the new version number, even though you

already granted permission

1. Repeat indefinitely — each update produces a new prompt

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.119

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Root cause is visible in the macOS TCC database — permissions are granted per
resolved binary path, not per symlink:

kTCCServiceSystemPolicyNetworkVolumes |
~/.local/share/claude/versions/2.1.116 | allowed
kTCCServiceSystemPolicyNetworkVolumes |
~/.local/share/claude/versions/2.1.117 | allowed
kTCCServiceSystemPolicyNetworkVolumes |
~/.local/share/claude/versions/2.1.119 | allowed

Claude Code places each version at a new path and updates the symlink at
~/.local/bin/claude. macOS resolves the symlink before checking TCC, so every
update is treated as a brand new application requiring fresh permission
grants.

After a week of updates, there were 4 separate "2.1.x" entries accumulating in

System Settings → Privacy & Security → Files & Folders, each needing to be
individually managed.

Workaround: Manually grant Full Disk Access to the current version binary in
System Settings → Privacy & Security → Full Disk Access after each update.
Still requires manual intervention per update.

Suggested fix: Ship a stable launcher binary at a fixed path that never
changes
between versions and exec's the current versioned binary. TCC would grant
permission to the launcher once, permanently. The desktop app already handles
this correctly via its bundle ID (com.anthropic.claudefordesktop) — the CLI
needs the same treatment.