VS Code extension: Rename Session Tab persists the title but the editor tab label never refreshes (v2.1.270)

What's Wrong?

Claude Code: Rename Session Tab persists the new title correctly, but the editor tab label keeps showing the old one. It stays stale indefinitely — until something unrelated causes the session state to be re-read.

There is no error and no notification. The rename genuinely succeeds: the new title is written to the session transcript as customTitle, and renameSession returns skipped: false. Only the label is wrong, so it reads as "rename doesn't work".

Things that do make the label catch up, all of which re-read session state:

• clicking the session in the session list (cheapest — one click)
• opening the session list at all
• closing and reopening the tab
• restarting the window

Note the ordering trap: restarting before renaming doesn't help, because the panel reads the title at creation. You have to rename first, then cause a refresh. That made it look intermittent for a while.

What Should Happen?

The editor tab label should update as soon as the rename succeeds, the way it does when the session is renamed from the in-webview session list.

Steps to Reproduce

1. Open a Claude Code session as an editor tab (Claude Code: Open in New Tab).
2. Command Palette → Claude Code: Rename Session Tab.
3. Type a new name and press Enter.
4. Observe: the editor tab label is unchanged. No error, no notification.
5. Confirm it actually persisted — the new title is in the session's transcript under ~/.claude/projects/<project>/<session-id>.jsonl as "customTitle":"<new name>".
6. Now click that session in the Claude session list. The tab label updates immediately to the name set in step 3.

Analysis

From the shipped bundle in anthropic.claude-code-2.1.270-win32-x64:

The editor tab title is only ever assigned in response to a rename_tab message from the webview:

else if ($.request.type === "rename_tab")
    if (this.panelTab && typeof $.request.title === "string")
        this.panelTab.title = GX($.request.title)

and that message is produced by a reactive effect reading the active session's summary:

let q = this.activeSession.value?.summary.value,
    V = (q && q.length > 25 ? q.substring(0, 24) + "…" : q) || "Claude Code";
wZ(() => J.renameTab(V, H, W));

The two rename routes then differ:

• In-webview rename (session list) sets Z.summary.value = J optimistically before awaiting the round trip. The effect re-evaluates, rename_tab is sent, the tab updates.
• claude-vscode.renameSessionTab writes to the store, then handleSessionRenamed calls sendSessionRenamed, which delivers session_renamed to the webview. The only handler there is:

``js
case "session_renamed":
this.sessionRenamedEvents.emit({ sessionId: $.request.sessionId, title: $.request.title });
break;
``

Nothing assigns activeSession.summary, so the effect never re-evaluates, rename_tab is never sent, and panelTab.title is never reassigned.

That accounts for every symptom: correct persistence, no error, stale label, and any subsequent re-read of session state fixing it.

Suggested fix: have the session_renamed handler update the matching session's summary (as the in-webview path already does), so the existing effect fires and the tab repaints. The rest of the machinery is already in place and working.

Environment

• Extension: anthropic.claude-code-2.1.270-win32-x64
• VS Code on Windows 11
• Reproduced across several separate workspace folders

Additional note

The extension registers one lock file per workspace folder under ~/.claude/ide/. On this machine several VS Code windows shared a single Code process id across those lock files, so the symptom appeared in multiple windows at once and looked like one window blocking another. That turned out to be a red herring — it is the same missing refresh in each window, not cross-window interference. Renames were always applied to the correct session; I verified this by renaming to a unique string in one window and confirming it landed only on that window's transcript.