[BUG] Linux: auto-updater prunes version binaries still executed by running sessions (/proc exe → deleted); no update notification → silent multi-version fragmentation

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?

On Linux (native install), the auto-updater's version lifecycle completely ignores running sessions. Two consequences, both observed live on 2026-07-07:

1. The updater deletes version binaries that running sessions are still executing.

~/.local/share/claude/versions/ keeps only ~3 versions on disk; pruning does not check process liveness. Observed: version 2.1.198 was pruned while two sessions were still running it:

$ readlink /proc/<pid>/exe
/home/asuramaya/.local/share/claude/versions/2.1.198 (deleted)

Those sessions survive only on the kernel's deleted-inode reference. Anything that re-execs or spawns from the binary's on-disk path will fail with ENOENT in ways that are nearly impossible for a user to diagnose (this exact failure mode was previously reported for macOS in #47253 — ENOENT on subprocess spawn — which was auto-duped into #18019 (Homebrew variant); both are now closed not_planned and locked, so this cross-platform, still-present bug currently has no open canonical issue. #71942 covers only a Desktop-app-specific macOS consequence.)

2. Silent fleet fragmentation — no warning, no notification, ever.

Long-lived sessions keep executing whatever version they started on, indefinitely, with no indication anywhere (statusline, message, anything) that they are generations behind. Observed simultaneously on one machine:

12 processes on 2.1.202
 6 processes on 2.1.201
 2 processes on 2.1.198   <- binary deleted from disk

Sessions running old versions silently never receive bug fixes. Discovery is effectively impossible for normal users: process comm shows as 2.1.202 etc., which is easy to misattribute to unrelated software — we initially blamed the terminal emulator's helper processes. This only surfaces for users who keep sessions alive for days (i.e., longer than the release cadence), which is likely why it persists; suggest adding session-lifetime-across-updates as a test dimension.

What Should Happen?

1. Before pruning a version from disk, check for live processes executing it (/proc/*/exe on Linux); defer deletion until they exit.
2. Notify long-running sessions that a newer version exists (statusline hint, message on next turn — anything beats silence).
3. Optionally: a session-preserving restart/migrate path for long-lived sessions.

Error Messages/Logs

$ for pid in $(pgrep -x 2.1.198 -x 2.1.201 -x 2.1.202); do readlink /proc/$pid/exe; done | sort | uniq -c
      2 /home/asuramaya/.local/share/claude/versions/2.1.198 (deleted)
      6 /home/asuramaya/.local/share/claude/versions/2.1.201
     12 /home/asuramaya/.local/share/claude/versions/2.1.202

$ ls ~/.local/share/claude/versions/
2.1.200  2.1.201  2.1.202        # 2.1.198 gone from disk, still running

Steps to Reproduce

1. Native-install Claude Code on Linux; start a session and keep it alive.
2. Let auto-update advance the installed version several times (or force updates) until the session's version is pruned from ~/.local/share/claude/versions/.
3. readlink /proc/<session-pid>/exe → shows ... (deleted).
4. Observe that the session received no warning at any point, and continues running orphaned code.

Environment

• Claude Code 2.1.202 latest installed; sessions concurrently running 2.1.198 (deleted), 2.1.201, 2.1.202
• Ubuntu 26.04 LTS, kernel 7.0.0-22-generic, x86_64, native installer

Related: #18019 (locked, not_planned — Homebrew/macOS), #47253 (locked, auto-duped — macOS native updater), #71942 (open — Desktop-app FDA variant). Filed as a new issue per the auto-lock bot's own instruction to "file a new issue and reference this one."