[Bug] macOS Activity Monitor shows version number (e.g. '2.0.53') instead of 'claude' as process name

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

This is still occurring as of version 2.0.76

This also impacts Tmux's automatic-rename capability

Still occurring as of v2.1.7 - and it's a bug that makes observability difficult especially when running multiple Claudes.

!Image

I would recommend leaving a /bug in Claude Code. It's unclear to me how often GitHub issues are actually reviewed, but from seeing the attitudes of the Claude Code team on X, they seem to very aggressively monitor the native feedback and bug reports.

I don't see any /bug command in Claude Code? @shaanmajid

!Image

I think it's disabled if you have CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 or similar settings (I keep the same on and briefly remove it to submit bugs and re-enable afterwards lol).

Still occurring in 2.1.17

tmux pane_current_command also affected

This also breaks tmux's automatic-rename-format and any plugin that relies on pane_current_command to identify the running process.

On macOS, tmux uses proc_name() which resolves the symlink at ~/.local/bin/claude to the versioned binary (e.g. ~/.local/share/claude/versions/2.1.45), so pane_current_command returns 2.1.45 instead of claude.

This means plugins like tmux-nerd-font-window-name can't match the process to show a Claude icon. Even if the binary were renamed to claude-2.1.45, plugins still couldn't match on claude without prefix/pattern matching support.

The ideal fix from the tmux perspective would be a binary named claude (with version tracked via an internal mechanism rather than the filename).

Still present. It is probably because they are using symlinks when using the custom installer instead of npm:

❯ which claude
/Users/idriss.mortadi/.local/bin/claude

~
❯ l /Users/idriss.mortadi/.local/bin/
...
24 Feb 10:20 claude -> /Users/idriss.mortadi/.local/share/claude/versions/2.1.52
...

Confirmed still happening in 2.1.62.

Root cause is that the binary is ~/.local/share/claude/versions/2.1.62

Renaming the binary to claude-2.1.62 would resolve this issue.

FWIW I'm seeing this in 2.1.74, just reported via /bug and it generated this for a Github issue:

Bug Description
tmux windows show "2.1.74" instead of "claude" because the binary at ~/.local/share/claude/versions/2.1.74 is named after the version. tmux
resolves the symlink and uses the filename as the window title. Same root cause as https://github.com/anthropics/claude-code/issues/12433.

Environment Info

• Platform: darwin
• Terminal: tmux
• Version: 2.1.74
• Feedback ID: df8a431c-130c-44dc-a29b-9a5220b99ff8

Errors

[{"error":"Error: NON-FATAL: Lock acquisition failed for /Users/sagie.maoz@viam.com/.local/share/claude/versions/2.1.74 (expected in multi-process scenarios)\n    at kvT (/$bunfs/root/src/entrypoints/cli.js:2644:2025)\n    at Cbq (/$bunfs/root/src/entrypoints/cli.js:2644:1169)\n    at processTicksAndRejections (native:7:39)","timestamp":"2026-03-13T14:28:08.449Z"}]

Some more context - this only happens with the binary installed by the install script curl -fsSL https://claude.ai/install.sh | bash. If you install via homebrew -> brew install --cask claude-code the process is called claude.

But the homebrew installation is constantly lagging behind because the pace of updates + slow homebrew formula updates, so claude is always complaining it's out of date and telling you to run brew upgrade claude-code, when homebrew doesn't have a new version yet.

Anyone know how we get someone to triage this? Or just get lucky with the 8k+ open issues on this repo, lol.

@mattwilkinsonn that's why I switched to the direct install (brew is often behind on releases)

tmux users may be interested in the [workaround][1] shared by @brian-deane-gusto.

[1]: https://github.com/anthropics/claude-code/issues/49852#issuecomment-4328517818

Behavior is definitely still present though, would love a fix!

+1 - this isn't only a cosmetic Activity Monitor / tmux title issue. The versioned binary path also invalidates macOS TCC Automation grants on every upgrade, which silently breaks unattended automation.

Concrete operational impact: I run scheduled cron flows that drive Chrome via claude --chrome plus an AppleScript wrapper for window/tab housekeeping (health probe, stale-tab cleanup, post-flow window close). After every Claude upgrade, the Chrome Automation grant goes stale because TCC sees the new versioned binary as a new app. The cron-launched wrapper hits a tell application "Google Chrome" health probe, macOS queues a TCC consent dialog that no one is at the keyboard to click, and the entire pipeline silently fails. Last upgrade cost me ~2 days of failed GLG scans before I noticed.

Confirming @dweekly's earlier finding: my install is also at ~/.local/share/claude/versions/<version>/claude with ~/.local/bin/claude symlinked in. macOS TCC resolves the symlink → new file → new TCC identity → reauth required.

Workaround for anyone hitting this on automated/headless setups: brew install --cask claude-code puts the binary at a stable Homebrew path and the TCC grant survives upgrades. Tradeoff is the Homebrew formula lags upstream by days.

Real fix would be either (a) install the binary at a stable path with a sibling versions/ dir (so the executed path doesn't change per release), or (b) codesign every release with a stable Designated Requirement so TCC treats them as the same identity even at different paths.

Please fix this, this is going against all norms on macOS. Process names should be static among versions and they should be a string that resembles the application. This abnormal name makes it very hard to perform any governance or forensic investigation on Claude Code.

Same root cause bites harder in the macOS Automation/TCC permission dialog, where it crosses from cosmetic into a security concern.

On 2.1.166, launching a background job triggered:

"2.1.166" wants access to control "Terminal.app". Allowing control will provide access to documents and data in "Terminal.app", and to perform actions within that app.

No "Claude Code", no developer identity — just a bare semver requesting the power to drive Terminal (effectively arbitrary command execution). To a careful user this is indistinguishable from malware, and the correct security instinct is to click Don't Allow and start hunting for what's compromising the machine. I did exactly that before tracing the process back to ~/.local/share/claude/versions/2.1.166.

It compounds with the versioned-install-path problem (#46859 / #30608): every auto-update is a new binary identity to TCC, so the scary unnamed prompt re-appears on each update even after you've granted it once.

Fix is the same as this issue asks — a stable CFBundleName/CFBundleDisplayName (and ideally a version-independent TCC-facing binary path) so both Activity Monitor and the permission dialogs read "Claude Code" instead of a version string.

Seeing the same on Linux (e.g. in top). +1 to fixing this.

Still seeing this on macOS 15.7.1 (upgraded from 15.5 today). The dialog reads "claude.app" would like to access data from other apps and reappears repeatedly even after clicking Allow. Full Disk Access is granted for all three claude CLI binaries and the Claude desktop app.

Second symptom of the same root cause: the Local Network permission list (Privacy & Security → Local Network) accumulates a new 'claude' entry on every auto-update, because each versioned binary is a fresh TCC identity. I currently have 18+ duplicate 'claude' entries in Local Network, all enabled. The same happens in Full Disk Access. The net effect is that every update triggers a new permission dialog, and the permission panels become unusable garbage. This won't be fixed by clicking Allow — it will keep accumulating until the binary has a stable identity.