[BUG] VS Code extension doesn't sync conversation names after CLI /rename command

Status Closed — not planned
Reported on v2.0.76
Maintainer reply None cached
Activity 12 comments · opened Jan 2, 2026 · closed May 22, 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?

Description:

When renaming a conversation using the /rename command in the CLI, the VS Code extension's conversation dropdown continues to display the old name, while the CLI correctly shows the new name.

Expected Behavior:

Both CLI /resume and VS Code extension dropdown should display the same conversation name after a rename operation.

Actual Behavior:

  • /resume command in CLI shows the correct new name ✅
  • VS Code extension dropdown shows the old name ❌
  • Both lists contain the same number of sessions - only the labels differ
  • Even after reloading VS Code window or closing/reopening VS Code, the dropdown still shows the old name
  • The session is correctly identified (same position in list, same metadata), only the display name is stale

Workaround:

None found. The VS Code extension dropdown never updates to reflect CLI-based renames.

Environment:

  • OS: Windows (win32)
  • Claude Code version: 2.0.76
  • VS Code version: 1.107.1

Additional Context:

This is a synchronization issue specific to conversation names/labels, not a cache issue affecting the entire session list. The extension appears to cache conversation display names separately and never re-reads them from the session metadata files, even though the CLI correctly reads the updated names from disk.

Severity: Medium - Creates confusion when managing conversations across CLI and UI workflows, as the same conversation appears with different names in different interfaces.

Related Issues:

  • #8667 mentions caching issues but refers to different sessions/data, not just label mismatches

What Should Happen?

What Should Happen:

When a conversation is renamed via the CLI /rename command:

  1. The session metadata file should be updated on disk (✅ this works - confirmed by CLI /resume)
  2. The VS Code extension should either:
  • Option A: Automatically detect the metadata change and refresh its conversation list
  • Option B: Re-read session metadata from disk when the conversation dropdown is opened
  • Option C: At minimum, refresh the list when VS Code window is reloaded

The conversation name should be consistent across all interfaces (CLI and VS Code UI) since they share the same underlying session storage.

Error Messages/Logs

Steps to Reproduce

Steps to Reproduce:

  1. Open a terminal in your project directory
  2. Start Claude Code CLI:

```bash
claude

  1. Have a conversation (send at least one message)
  2. Note the initial conversation name shown in the prompt or when you start the conversation
  3. Rename the conversation:

/rename new-conversation-name

  1. Verify the rename in CLI:
  • Exit the conversation (Ctrl+C or /exit)
  • Run /resume to list conversations
  • Result: The conversation shows the new name ✅
  1. Check in VS Code extension:
  • Open VS Code
  • Open the Claude Code extension panel
  • Click on the conversation dropdown/list
  • Result: The same conversation shows the old name ❌
  1. Attempt to refresh:
  • Reload VS Code window (Ctrl+Shift+P → "Developer: Reload Window")
  • Or close and reopen VS Code completely
  • Check the conversation list again
  • Result: Still shows the old name ❌

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.0.76

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

_No response_

View original on GitHub ↗

12 Comments

github-actions[bot] · 6 months ago

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

alexb5dh · 6 months ago

The issue is still present as of 2.1.39, same as automatically-closed #16973.

murillojndem · 5 months ago

It still happens. Also I rename my conversations in the addon but if I reopen VS code the names go back to what they were.

KyuRish · 5 months ago

This still an issue., getting annoying now. Please could we get a fix for this soon?

senl-1 · 5 months ago

Request higher priority for this bug. With 10+ conversations on the design, project management and dev ops going on, it is not possible to work efficiently without renaming the chats appropriately. But losing all the names when restarting VS Code is painful and wastes effort.

s4dl1G · 5 months ago

Same issue here on Windows 10 + VS Code extension. Renaming a conversation via the UI (hovering over a session in the Past Conversations dropdown) does not persist after restarting VS Code — reverts to the default generated name every time. Claude Code 2.1.72, VS Code latest stable.

SauliusDev · 5 months ago

Same issue on linux mint, also /rename skill in the extension chat does not apear and when I run it nothing happens.

eamon0989 · 5 months ago

Same issue here, gets frustrating not being able to find chats because the name has changed.

chErphiR · 5 months ago

Same issue

dave-german-rva · 4 months ago

Still happening on macOS with the VS Code extension (latest). When I rename a chat via the sidebar, the name sometimes persists but often gets silently overwritten with the first few words of my latest prompt. This makes searching for older conversations very unreliable.

This seems like the same root cause as the auto-renaming behavior — the extension doesn't flag manually-set names as "pinned" and re-generates the title on subsequent messages. A customName: true flag (as suggested in #30235) would fix all the variants of this bug.

github-actions[bot] · 3 months ago

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

github-actions[bot] · 1 month ago

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.