### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) 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? Renaming a session from the title in the Claude view header shows the new name for one frame, then reverts. Renaming the same session from the activity-ba

Also reproducing on **Linux**, via VS Code Remote-SSH (the extension host runs on the remote machine). - **Client:** Arch Linux, VS Code 1.138.0 - **Remote extension host:** x86_64, kernel 6.18.13 (TrueNAS / Debian 12 based) - **Extension:** linux-x64, bundled CLI of the same version Rename attempts vs. `TypeError: X.query.renameSession is not a function` errors, per extension-host log: | Extension | Date | Renames | Errors | |---|---|---|---| | 2.1.267 | 2026-09-11 | 4 | 0 | | 2.1.270 | 2026

[BUG] [VS Code] Renaming a session from the chat header reverts instantly (2.1.270 regression)

Status Fixed / completed

Reported on v2.1.267

Maintainer reply None cached

Workaround ✓ Mentioned in thread ↓

Activity 7 comments · opened Sep 14, 2026 · closed Oct 14, 2026

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?

Renaming a session from the title in the Claude view header shows the new name for one frame, then reverts. Renaming the same session from the activity-bar session list works.

The title is persisted — reload the window and the new name is there. Only the header view rolls back.

Cause

extension.js, Comm.renameSessionOnCli:

renameSessionOnCli($,Q){let X=(Y)=>{this.logger.log(`renameSession: the CLI did not take the title: ${Y}`)},
J=this.channelOnSession($);
if(J){J.query.renameSession(Q,$).catch(X);return} ... }

query.renameSession does not exist on the SDK query class. The call throws a synchronous TypeError, so .catch(X) never attaches — the throw escapes Comm.renameSession, handleRequest returns {type:"error"}, and the webview store's renameBaseline rollback restores the old title.

Why only the header

The comm that owns the session's live CLI channel is the one that throws. A header rename originates from that comm, so it receives its own error and rolls back. A list rename originates from a comm with no channel; the fan-out's echo to the chat view is evaluated before the throwing call in the same comma expression, so the header has already adopted the new title. adoptPersistedTitle early-returns when summary already equals the new title, so the echo cannot repair the header path.

What Should Happen?

The header shows the new title, matching what was persisted and what the activity-bar session list shows.

Error Messages/Logs

Claude Code output channel, session id and titles redacted:

[info]  Received message from webview: {"type":"request","request":{"type":"rename_session","sessionId":"<redacted>","title":"<new title>"}}
[error] Error processing client request: TypeError: J.query.renameSession is not a function
[info]  Received message from webview: {"type":"interrupt_claude","channelId":"oes4etaaov"}
[warning] Channel not found: oes4etaaov
[info]  Received message from webview: {"type":"request","request":{"type":"update_session_state","sessionId":"<redacted>","state":"idle","title":"<OLD title>","idConfirmed":true}}

The trailing update_session_state carries the OLD title - that is the rollback.
Also note the interrupt_claude uses the requestId as a channelId and is not found;
that appears to be the generic error path misfiring on a request that never opened a channel.

Steps to Reproduce

Open a session in the Claude sidebar view and send one message, so a CLI process is attached to it.
Click the session title in the view header, type a new name, press Enter.

Expected: the header shows the new title.
Actual: it reverts immediately. Renaming the same session from the activity-bar session list keeps the new name.

The attached CLI process matters — that is what makes this comm the channel owner and therefore the one that throws on itself.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

2.1.267

Claude Code Version

VS Code extension 2.1.270 (CLI: 2.1.238)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

Regression detail

Not present in 2.1.267: renameSessionOnCli appears 0 times in that build, and the total renameSession occurrences in extension.js go from 6 (2.1.267) to 13 (2.1.270).

Suggested check

The SDK query class exposes generateSessionTitle, messageRated and similar, but has no rename* member — so this looks like a call added against a method that was never implemented on that class, rather than a wiring mistake. Awaiting the call rather than using an unattached .catch() would at least surface it instead of failing silently into a rollback.

View original on GitHub ↗

5 Comments

eschultz · 1 month ago

Also reproducing on macOS (darwin-arm64). First failure in my logs is on 2.1.269 (installed 2026-09-14); renames were clean on 2.1.261 and 2.1.263. Still broken on 2.1.272. Same TypeError: J.query.renameSession is not a function, and the title is persisted to the transcript JSONL despite the header reverting.

modus-miles · 29 days ago

Reproduced on macOS arm64 with 2.1.272 (VS Code) and 2.1.270 (Cursor), same TypeError: X.query.renameSession is not a function in the Claude VSCode output channel. Adding three findings that go beyond the header rollback, because the same throw also loses the persisted title in a common case.

1. The CLI never learns the new title, so its per-turn flush re-stamps the old one

renameSessionOnCli is the only thing that tells the live CLI process about the rename, and it throws before the control request is sent. The CLI keeps its in-memory title and re-appends it to the transcript after every turn (last-prompt → custom-title → ai-title → atis-latch block). The loader takes the last custom-title record, so the rename is overwritten on disk, not just in the header.

This happens whenever the CLI already holds a title: the session was renamed before its process spawned, or it was resumed after an earlier rename. Transcript from one of my sessions (writer identified by key order: the host writes sessionId,customTitle, the CLI writes customTitle,sessionId):

  1 {"type":"custom-title","sessionId":"…","customTitle":"sss"}        host, before spawn
  2 {"type":"custom-title","sessionId":"…","customTitle":"ddd"}        host, before spawn
  3 {"type":"custom-title","customTitle":"ddd","sessionId":"…"}        CLI adopts it at start
 …
 29 {"type":"custom-title","sessionId":"…","customTitle":"xxx"}        host: rename while running
 33 {"type":"custom-title","sessionId":"…","customTitle":"Session Re-name"}   host: rename again
 39 {"type":"custom-title","customTitle":"ddd","sessionId":"…"}        CLI re-stamps "ddd"
 53 … 65 … 74 … 87 … 94 … 107  same "ddd" record after every turn

Sessions whose CLI holds no title (fresh session, renamed after the first message) don't get re-stamped, which is why the persisted name survives in the original report. I suspect #94285 and #94017 are the same defect seen from the tab / session list: the CLI's update_session_state and title flush still carry the old title because it was never told.

2. The method is missing from the SDK build, not just from the extension bundle

The published @anthropic-ai/claude-agent-sdk@0.3.272 has no Query.renameSession. Its only rename export is the standalone file mutation renameSession(sessionId, title, options?), with the opposite argument order from the query.renameSession(title, sessionId) call in renameSessionOnCli. The extension host was evidently built against an API surface that never shipped.

The CLI side is ready: every bundled binary from 2.1.268 on handles the rename_session control subtype ({subtype:"rename_session", title}), and sending that request directly to the 2.1.272 native binary over stream-json returns {"subtype":"success"}.

3. One-line fix, verified locally

Adding this to the bundled SDK Query class (next to generateSessionTitle) makes the header rename stick and the CLI stop re-stamping:

async renameSession($,Q){await this.request({subtype:"rename_session",title:$})}

Verified on 2.1.272 and 2.1.270: no TypeError, the CLI acknowledges, and subsequent turns re-stamp the new title. Two hardening suggestions while you're there: wrap the CLI notify in try/catch so a synchronous throw can't roll back a rename that already persisted, and treat "CLI didn't take the title" as a log line rather than a request failure.

Unrelated but compounding: 2.1.269 also dropped the editor/title and editor/title/context entries for claude-vscode.renameSessionTab from package.json, so the tab right-click fallback disappeared in the same release. Happy to file that separately if it isn't tracked.

byeBee · 29 days ago

Also reproducing on Windows 11 x64 (Cursor 3.20.21, VS Code base 1.128.0) — extension host 2.1.270 with 2.1.272 also installed, same TypeError: J.query.renameSession is not a function, three times in eight minutes.

Confirming @modus-miles's finding from the Windows binary side: resources/native-binary/claude.exe carries the rename_session control subtype in both 2.1.270 and 2.1.272, while the camelCase renameSession appears nowhere in it. The CLI is ready; the gap is entirely on the SDK Query side.

One detail I haven't seen mentioned — the throw also tears down the request channel before the rollback lands:

10:22:48.132  rename_session   sessionId=3cb7c1cc-…  title="<new>"
10:22:48.145  [error] Error processing client request: TypeError: J.query.renameSession is not a function
10:22:48.158  interrupt_claude channelId=os4t3cg16  →  [warning] Channel not found: os4t3cg16
10:22:48.165  rename_tab       title="<previous auto-generated title>"    ← rollback, 33 ms

Same shape in the other two reproductions (95 ms and 92 ms from request to rollback). The try/catch around the CLI notify that @modus-miles suggests would close this path as well.

myprestarocks · 28 days ago

Also reproducing on Linux, via VS Code Remote-SSH (the extension host runs on the remote machine).

Client: Arch Linux, VS Code 1.138.0
Remote extension host: x86_64, kernel 6.18.13 (TrueNAS / Debian 12 based)
Extension: linux-x64, bundled CLI of the same version

Rename attempts vs. TypeError: X.query.renameSession is not a function errors, per extension-host log:

| Extension | Date | Renames | Errors |
|---|---|---|---|
| 2.1.267 | 2026-09-11 | 4 | 0 |
| 2.1.270 | 2026-09-14 / 09-15 | 5 | 5 |
| 2.1.272 | 2026-09-16 | 3 | 3 |
| 2.1.273 | 2026-09-16 | 5 | 5 |

So it's still broken on 2.1.273, the latest release. The last good version on this machine was 2.1.267.

One more detail: every attempt writes a correct custom-title record to the session .jsonl. The CLI never receives rename_session, though, so custom-title.json is never created, and the webview puts the previous title back when it gets the error response. The CLI's own rename path works: running /rename <name> in the session chat sticks, and it's the workaround until this is fixed.

joemillerpe-ux · 28 days ago

Same on extension 2.1.273 (Windows 11, VS Code). Renaming from the chat header: the new name shows for an instant, then flashes back to the original in the chat window. The Claude Code sidebar pane shows the renamed session correctly. Reopening the session shows the correct name in the window.

Workaround: rename from the Claude Code sidebar pane instead of the chat header — that updates the chat window name correctly.

Showing cached comments. Read the full discussion on GitHub ↗