Repository navigation
[Bug] macOS Activity Monitor shows version number (e.g. '2.0.53') instead of 'claude' as process name #12433
Description
Environment
- Platform: macOS (Darwin 25.1.0, Apple Silicon)
- Installation method: Native installation via
bun - Claude Code version: 2.0.53
Description
In macOS Activity Monitor, Claude Code processes appear with just the version number (e.g., 2.0.53) as the process name instead of something recognizable like claude or Claude Code.
This makes it difficult to:
- Quickly identify Claude Code processes in Activity Monitor
- Distinguish Claude Code from other applications
- Monitor resource usage at a glance
Root Cause
The native installation stores versioned binaries at:
~/.local/share/claude/versions/2.0.53 (actual Mach-O binary)
~/.local/bin/claude -> ~/.local/share/claude/versions/2.0.53 (symlink)
macOS Activity Monitor uses proc_pidpath() from libproc.dylib to get process names, which resolves symlinks and returns the actual binary path. Since the binary filename is literally 2.0.53, that's what Activity Monitor displays.
Reproduction
- Install Claude Code via native installation
- Run
claudein terminal - Open Activity Monitor
- Search for "claude" - no results
- Search for the version number (e.g., "2.0.53") - Claude Code processes appear
Expected Behavior
Activity Monitor should show a recognizable name like claude, claude-code, or claude-2.0.53.
Potential Fix
One low-disruption option would be to rename the versioned binary files from {version} to claude-{version}:
~/.local/share/claude/versions/claude-2.0.53
This would:
- Make processes show as
claude-2.0.53in Activity Monitor (recognizable + shows version) - Require minimal changes (just the filename template in build/update logic)
- Not affect any user-facing paths (symlink remains
~/.local/bin/claude)
However, there may be other approaches the team prefers.
Additional Context
Verified via:
$ readlink -f ~/.local/bin/claude
/Users/.../.local/share/claude/versions/2.0.53
$ python3 -c "
import ctypes, os
libproc = ctypes.CDLL('/usr/lib/libproc.dylib')
# ... proc_pidpath() returns the resolved path
"
# Returns: /Users/.../.local/share/claude/versions/2.0.53This appears to be unreported - searched existing issues for Activity Monitor, process name/title, and related terms without finding a match.
Activity
github-actions commentedon Dec 26, 2025
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.
shaanmajid commentedon Dec 30, 2025
This is still occurring as of version 2.0.76
aaronjensen commentedon Jan 5, 2026
This also impacts Tmux's automatic-rename capability
PaulRBerg commentedon Jan 14, 2026
Still occurring as of v2.1.7 - and it's a bug that makes observability difficult especially when running multiple Claudes.
shaanmajid commentedon Jan 14, 2026
I would recommend leaving a
/bugin 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.PaulRBerg commentedon Jan 14, 2026
I don't see any
/bugcommand in Claude Code? @shaanmajidshaanmajid commentedon Jan 14, 2026
I think it's disabled if you have
CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1or similar settings (I keep the same on and briefly remove it to submit bugs and re-enable afterwards lol).fix(tmux): prevent status icon from persisting after Claude Code exits
fix(tmux): prevent status icon from persisting after Claude Code exits (
8 remaining items
mattwilkinsonn commentedon Apr 2, 2026
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 viahomebrew->brew install --cask claude-codethe process is calledclaude.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.
joshmedeski commentedon Apr 2, 2026
@mattwilkinsonn that's why I switched to the direct install (brew is often behind on releases)
davidchambers commentedon Apr 28, 2026
tmux users may be interested in the workaround shared by @brian-deane-gusto.
brian-deane-gusto commentedon Apr 28, 2026
Behavior is definitely still present though, would love a fix!
Dithy-Balaji-Official commentedon May 3, 2026
+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 --chromeplus 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 atell 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>/claudewith~/.local/bin/claudesymlinked 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-codeputs 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.
balazserdeszlogmein commentedon May 14, 2026
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.
FrankLedo commentedon Jun 6, 2026
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:
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.rmlarsen commentedon Jun 7, 2026
Seeing the same on Linux (e.g. in
top). +1 to fixing this.blwfish commentedon Jun 24, 2026
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 appsand reappears repeatedly even after clicking Allow. Full Disk Access is granted for all three claude CLI binaries and the Claude desktop app.blwfish commentedon Jun 24, 2026
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.
bashrc: wrap `claude` so tmux windows don't get named after its version
lubos-dataplaza commentedon Aug 29, 2026
Still the same and really annoying for all reasons mentioned here in comments.
add claude wrapper: the one claude on PATH