Session tab rename is overwritten by a stale webview title; rename only appears after restarting VS Code

Environment

• Extension: anthropic.claude-code 2.1.273 (darwin-arm64)
• CLI: 2.1.239
• VS Code: 1.138.0
• macOS 26.4.1 (Darwin 25.4.0)

Summary

Renaming a session tab writes correctly to disk, but the extension then re-appends a stale title it is holding in memory, so the old name wins. The new name only becomes visible after quitting and reopening VS Code.

Repro

1. Open a session tab and let the conversation run long enough for the CLI to emit ai-title records.
2. Rename the tab (Claude Code: Rename Session Tab). Observe the new name briefly.
3. Keep working in the session.
4. The tab reverts to a previously set name — not the one just typed.
5. Quit and reopen VS Code. The correct name now appears.

Evidence

The two writers are distinguishable by JSON key order in the session transcript. {type, sessionId, customTitle} is V6.renameSession; {type, customTitle, sessionId} is the CLI echo via renameSessionOnCli. From one session's .jsonl, in file order:

A: cc tab            <- user rename
B: cc tab
A: cc tab updates    <- user rename
B: cc tab updates  x3
A: cc tab update     <- user rename
B: cc tab update
A: cc tab            <- not typed by the user; stale value, written last

The final record is in the extension's own rename format and carries a title the user had set two renames earlier. Nothing on disk seeds it — grepping that value across VS Code storage, ~/.claude/ide, ~/.claude/sessions and ~/.claude/daemon finds no match — so it is in-window state.

Likely cause

The webview message handler writes the supplied title with no freshness check against what is already on disk:

case "rename_session":
  return this.renameSession($.request.sessionId, $.request.title);

A webview holding a stale title re-asserts it through this path and clobbers the newer rename. That also explains why a full restart fixes it: the webview is rebuilt and re-reads the correct title.

Related: the persistence path never writes its own sidecar

Separately, renameSession appends a custom-title record to the transcript but never writes <transcript-dir>/<session-id>/custom-title.json. The tab-title resolver reads only the first and last 64 KB of the transcript (fQ = 65536) and consults that sidecar when the tail has no customTitle — but since nothing writes it, a rename is silently lost once ~64 KB of new transcript pushes the record out of the tail window. In one 1 MB transcript the rename sat 141 KB from EOF and the resolver fell through to the newest ai-title. Writing the sidecar during renameSession would fix that independently of the webview issue.

These are two distinct bugs; happy to split them if you'd prefer separate issues.

Workaround

Developer: Reload Window after renaming.