[BUG] Release notes never readable: startup banner overwritten instantly (regression of #51569), and one global lastReleaseNotesSeen is consumed by concurrent sessions

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?

Two separate problems combine so that release notes are, in practice, never readable.

1. The startup "What's new" banner is overwritten within ~1 frame (regression of #51569).

#51569 reported the welcome header being dismissed instantly by a claude-in-chrome race at startup, and was closed as COMPLETED on 2026-04-21 (v2.1.116). The same symptom is back on v2.1.226, and the preconditions from that issue still match my setup:

• claudeInChromeDefaultEnabled: true in ~/.claude.json
• launched in a git-tracked project directory (the original repro noted it did not occur in non-project dirs)

The banner renders and vanishes too fast to read a single line. This matches #29380 (closed as duplicate) and #44247 (closed NOT_PLANNED / stale, labelled regression, area:tui) as well.

To be clear about confidence: I have not isolated the cause myself. What I can confirm is the symptom on 2.1.226 plus the config preconditions that #51569 identified.

2. lastReleaseNotesSeen is a single global marker, so concurrent sessions consume the notification.

This part does not appear in any existing issue and is what makes problem 1 permanent rather than merely annoying.

~/.claude.json holds one machine-wide lastReleaseNotesSeen value. The first session to start after an update writes the new version into it; every session started afterwards reads "already seen" and shows nothing. So each new version grants exactly one display opportunity for the whole machine.

If you run several terminal tabs and update near-daily, that single opportunity is routinely spent by whichever tab happened to start first, often one you were not looking at. Combined with problem 1 (the one display that does happen is unreadable), the practical result is that release notes are never seen at all. In my case: 4 versions in 5 days (2.1.223 → 2.1.226), ~950 startups since February, and no readable release notes for months.

What Should Happen?

• The banner should persist until dismissed (or at minimum stay through the first render of the REPL), per #44247.
• The "seen" gate should not be a single machine-wide token silently consumed by the first concurrent session. Either mark it seen only once actually displayed and dismissed, or scope it per session so a background tab cannot eat another tab's notification.

Error Messages/Logs

No errors emitted; the banner is simply replaced by the REPL.

Steps to Reproduce

1. Set claudeInChromeDefaultEnabled: true in ~/.claude.json.
2. Set lastReleaseNotesSeen to a version older than the installed one.
3. Launch claude in a git-tracked project directory.
4. The "What's new" banner flashes and is replaced by the REPL before it can be read.

For problem 2:

1. Set lastReleaseNotesSeen to an older version.
2. Start two sessions in quick succession.
3. Only the first shows anything; the second reads the now-updated marker and stays silent. Note that the first session's display is also the one destroyed by problem 1.

Notes

/release-notes does still work as a manual workaround, as noted in #29380.

Environment

• Claude Code v2.1.226, native install, macOS (Darwin 25.5.0)
• autoUpdates: false, though versions still land near-daily
• Claude in Chrome enabled; a --chrome-native-host process from a previous version (2.1.224) was still running alongside the 2.1.226 session, which may be relevant to the race

Is this a regression?

Yes — problem 1 was previously fixed in v2.1.116 via #51569.

Last Working Version

2.1.116 (for problem 1)

Claude Code Version

2.1.226