[BUG] Renaming a session never updates its currently-open editor tab title (VS Code extension)

Still reproduces on extension v2.1.251 — and not only on Windows. I hit this on macOS driving a Linux dev container, so the platform:windows label is probably too narrow.

I dug through the shipped bundle to find the mechanism, in case it saves someone time.

Why the tab title never updates

The editor tab label isn't state the extension holds independently — it's pushed from the webview. extension.js assigns it in exactly one place:

else if ($.request.type === "rename_tab") {
  if (this.panelTab) { this.panelTab.title = $.request.title; /* …icon… */ }
}

and webview/index.js sends it from a reactive effect:

G2(() => {
  let G = this.activeSession.value,
      q = G?.summary.value,
      U = (q && q.length > 25 ? q.substring(0, 24) + "…" : q) || "Claude Code";
  _z(() => J.renameTab(U, V, H))
})

So the tab label is activeSession.summary, truncated to 24 chars. It changes only when that signal changes.

Why /rename doesn't change it

/rename persists correctly — it writes <session-id>/custom-title.json and appends {"type":"custom-title",…} records into the transcript. But nothing pushes the new value into summary.value:

• There is no filesystem watcher on the projects directory (createFileSystemWatcher and fs.watch( are both absent from extension.js), so the on-disk change is never noticed.
• The one live-push path is explicitly skipped once a persisted title exists:

if (!i.hasPersistedTitle.value) i.summary.value = u.title;

A /rename therefore disqualifies itself from the only path that would have updated the label. Same root cause for the history list entry, since both surfaces read the same session objects.

What does fix it

Any listSessions call, because doListSessions updates existing sessions in place:

if (V) {
  if (U.customTitle) {
    V.hasPersistedTitle.value = true;
    … if (… && V.summary.value !== U.customTitle) V.summary.value = U.customTitle
  }
  continue
}

Confirmed by testing: after a /rename, opening the Resume conversation dialog (which calls listSessions("sessions_dialog")) and pressing Esc updates both the history list entry and the open editor tab title immediately, with no reload.

Workaround for anyone hitting this now

/rename <name>, close the session using the editor tab x button then open from side panel list.

Developer: Reload Webviews also works, but it is far more disruptive than it looks: it tears down and restarts the session's CLI process, interrupting an in-flight turn. I verified this by watching the session pid change at the moment of the reload.

Suggested fix

The machinery already exists. The sidebar's state-sync effect has a branch for exactly this case:

else if (W.current.get(u.sessionId) !== u.title) { W.current.set(u.sessionId, u.title), s = true }
…
if (s) $.listSessions("state_sync"), setTimeout(…, "state_sync_retry", 2000)

That branch fires a re-list when a session which already has a persisted title reports a changed title in its state broadcast — precisely the /rename case. It appears not to fire, which suggests the broadcast session state's title isn't updated when /rename runs. If that's right, the fix is to have the rename update the broadcast title, rather than to add a filesystem watcher — the absence of watchers looks deliberate.

I can only read the shipped bundle, not the CLI side, so I can't tell whether the title is never broadcast or is dropped before it reaches the webview. Either way the existing state_sync path looks like the intended mechanism.

---

_{Bundle analysis done with Claude Code (Opus 5), reading the shipped v2.1.251 extension. The reproduction, the "Resume conversation" workaround, and the process restart on Developer: Reload Webviews were each confirmed by a human in the VS Code UI.}

I have this problem on Mac as well.

fixed in 2.1.285