[Bug] macOS accessibility permissions lost on every update due to version-specific binary path

Bug Description
macOS accessibility/automation permissions break on every Claude Code update — binary path includes version

Problem

macOS stores accessibility and automation permissions keyed on the exact filesystem path of the granting binary. Claude Code's installed binary path includes the
version number. When Claude Code auto-updates (which happens often — sometimes multiple times per week), the binary path changes, which invalidates all previously
granted permissions from macOS's perspective.

The result: every update silently breaks Computer Use MCP and any other feature that requires macOS accessibility or automation permissions. The user discovers this
only when the feature fails, usually mid-task, often with a cryptic permission-denied error.

Steps to reproduce

1. On macOS, grant Claude Code accessibility or automation permissions:

• Open System Settings → Privacy & Security → Accessibility
• Add or enable Claude Code
• Verify it works (e.g., Computer Use MCP takes a screenshot successfully)

1. Wait for Claude Code to auto-update (or manually update to a new version, e.g., 2.1.99 → 2.1.100)
2. Attempt to use a feature that requires the granted permission
3. Observe: permission failure. The old entry in System Settings is now a "ghost" pointing at a path that no longer exists, and the new binary has no permission.

Observed behavior

On my Mac, I have accumulated ghost entries in Privacy & Security > Accessibility for multiple past Claude Code versions, each pointing at a stale path. Every update
adds another ghost. I have to:

1. Go to System Settings > Privacy & Security > Accessibility
2. Remove the ghost entry for the old version
3. Click "+" and navigate to the new Claude Code binary
4. Re-toggle the permission

This happens every single update. Multiple times per week. My ghost list is currently around a dozen entries.

Root cause

macOS permissions are stored with the inode and path of the binary at the moment permission was granted. Updating the binary to a new path means macOS treats it as a
different application that has never been granted permission. Claude Code appears to install each version to a version-specific path rather than using a stable symlink,
wrapper script, or update-in-place pattern.

Expected behavior

Option 1 (preferred): Stable binary path

Claude Code should install to a version-independent path (e.g., /usr/local/bin/claude or /Applications/Claude Code.app) with the versioned binaries hidden behind it as
implementation detail. Updates swap the target of the stable path; the path itself never changes. macOS permissions granted to the stable path survive all future
updates.

Option 2: In-place binary update

Update the binary in place without changing its path. macOS re-reads the new inode and preserves permissions for the same path.

Option 3: Documented migration on update

If Options 1 and 2 are infeasible, at minimum detect the update-breaks-permissions condition and show a clear one-time banner: "Claude Code was updated. If you use
Computer Use MCP or other accessibility-dependent features, you will need to re-grant macOS permissions in System Settings > Privacy & Security."

Why this matters

• Computer Use MCP is a flagship Claude Code feature. Breaking it silently on every update undermines trust in the tool.
• Users who update frequently suffer most. Power users who adopt new features fastest are the most penalized. This is the opposite of what a good update ergonomics

model produces.

• The ghost-entry accumulation is user-hostile. Users see a list of "Claude Code" entries in Privacy & Security growing over time with no clear way to clean them up.
• Not fixable in user space. Framework developers cannot work around this. Only Anthropic can fix the install layout.

Reporter

• Name: Jordan Dea-Mattson
• GitHub: @jordandm (the-agency-ai), @jordan-of (OrdinaryFolk)
• Email: jordandm@users.noreply.github.com, jordan-of@users.noreply.github.com
• Framework: https://github.com/the-agency-ai/the-agency
• Claude Code version: (fill at submission — claude --version)

Related

• Computer Use MCP is the primary affected feature
• Filed as part of the 2026-04-11/12 feedback batch alongside:
• /feedback comms gap (#46531)
• Content filter opacity (#46546)
• Session identity (#46853)
• Agent permission UX (#46855)
• --agent env var (#46858)

Environment Info

• Platform: darwin
• Terminal: ghostty
• Version: 2.1.101
• Feedback ID: 48a647ec-73f5-4954-a88b-6b9fd7e8a185

Errors

[{"error":"Error: 400 {\"type\":\"error\",\"error\":{\"type\":\"invalid_request_error\",\"message\":\"Output blocked by content filtering policy\"},\"request_id\":\"req_011CZwHyHAGs3JxBGJEgkNGQ\"}\n    at generate (/$bunfs/root/src/entrypoints/…

Note: Content was truncated.