[BUG] Auto-update swapping versions under a live session causes assistant text to silently not render (2.1.204 process, 2.1.205 on disk); text intact in JSONL

Environment

• Claude Code, native installer, macOS (Darwin 25.5.0), Apple Terminal.app
• Auto-update swapped the on-disk binary from 2.1.204 to 2.1.205 at a known time (symlink mtime Jul 8 15:46 local) while multiple interactive sessions launched under 2.1.204 kept running

Summary

Sessions that were running when the auto-updater replaced the installed version began silently not rendering assistant text blocks. The text exists intact in the session JSONL (verified by grepping the transcript file), but it never appeared in the terminal. The user only discovered the loss because a reply referenced answers he had never seen.

Observed symptoms (two affected sessions, both launched under 2.1.204 before the swap)

1. A turn containing substantive text followed by tool calls and a short closing message rendered only the short closing message. The long text block earlier in the turn (a five-part answer, several thousand characters) was never displayed.
2. A follow-up message that was a single text-only block (no tool calls) also failed to display beyond its opening line.
3. In the same degraded sessions, transcript view did not recover the text for the user.
4. After the user quit and restarted the session under 2.1.205 (resuming the same conversation), rendering has been normal so far.

Verification

• grep of the raw session .jsonl finds the full text of both missing messages, so this is a display-side failure, not message loss.
• Both affected sessions straddled the update. No fresh 2.1.205 session has shown the problem to date.

Hypothesis

A long-lived process launched from ~/.local/share/claude/versions/2.1.204 continues running after the updater changes the claude symlink and installs 2.1.205. If any resources are lazily loaded from disk after that point, the running process can end up with mismatched components, and rendering is where it shows.

Impact

Worst kind of failure for trust: the user cannot know what they did not see. In this case the user assumed a complete answer had been received when it had not.

Suggestions

• Have running sessions detect that the installed version no longer matches the running version and show a persistent "update installed, please restart this session" banner
• Or pin all lazily-loaded resources to the version directory the process started from, so a swap cannot affect a live process