Background daemon processes (bg-spare/bg-pty-host) show raw version string as process name

Description

Background daemon workers spawned by Claude Code (the --bg-spare and --bg-pty-host child processes) run via the exact versioned binary path, e.g.:

~/.local/share/claude/versions/2.1.201 --bg-spare /tmp/cc-daemon-<uid>/.../spare/....claim.sock
~/.local/share/claude/versions/2.1.201 --bg-pty-host /tmp/cc-daemon-<uid>/.../spare/....pty.sock

Since macOS (and most process monitors — Activity Monitor, Stats.app, TaskExplorer, 1Password's process list, ps, top) display the process name as the basename of argv[0]/the executable path, these show up simply as 2.1.201 (or whatever version) in process lists and system monitor widgets, with no indication they're Claude Code at all.

The interactive claude process itself displays fine (invoked via the ~/.local/bin/claude symlink, so argv[0] is claude), it's specifically the self-respawned background workers that leak the raw versioned path as their display name.

Why it happens (my understanding)

The background workers likely exec the literal resolved binary path (not the ~/.local/bin/claude symlink) deliberately, so a background daemon always runs the exact same version that spawned it and never drifts to a newer version after an in-place update. That's a reasonable version-skew guard — the issue is just the resulting process name, not the pinning behavior itself.

Suggested fix

After forking/before the long-running daemon loop starts, set a friendlier process title for these background workers (e.g. via setproctitle-equivalent) — something like Claude Code (background) — while still exec'ing/keeping the real versioned path for the pinning guarantee. This would make the process readable in Activity Monitor, Stats.app, htop, etc. without touching the version-pinning logic.

Environment

• macOS (Darwin 25.5.0, Apple Silicon)
• Claude Code CLI, self-hosted install under ~/.local/share/claude/versions/