[BUG] Desktop titles a session once at adoption and never re-reads aiTitle — CLI/VS Code-started sessions keep the raw first prompt, or a permanent generated placeholder name

Summary

Claude Desktop titles a Claude Code session once, at the moment it adopts it, and never
re-reads the aiTitle records the CLI keeps appending to the transcript. For sessions
started in Desktop this is invisible (Desktop is the one generating the title). For
sessions started in the CLI or the VS Code extension, the Desktop row is frozen forever
at whatever was available at adoption time:

• if the first prompt produced a title, Desktop stores the raw first prompt and keeps it

even after the CLI has replaced it with a real AI title;

• if the first prompt was too thin to title (mamamama), Desktop stores an empty title

and renders a generated placeholder name — spec-rippling-deer — which
survives quitting the app from the tray and relaunching, and only a manual rename clears it.

Meanwhile the CLI and the VS Code extension both read the transcript and agree with each
other. So the same session is called three different things depending on which client you
open, which defeats the point of the clients sharing one session store.

Why this hurts

Using the three clients interchangeably on one session store is a designed, supported feature —
and this bug is what makes it not work in practice. The session list is how you find your way
back to a piece of work, and the same session carries a different name in every client, so
there is nothing to recognise it by:

• a session I know as "Pandoc update failing with exit code 1603" in the CLI is a wall of

pasted shell output in Desktop;

• a session I know by its first words is spec-rippling-deer in Desktop — a name that

matches nothing I ever typed, and that stays wrong forever;

• Desktop's own rows are indistinguishable from each other when several sessions start with

the same pasted preamble, while the CLI's list of the same sessions reads cleanly.

So switching clients mid-task means re-identifying every session by hand, and renaming one
client's copy does not help the others. The inconsistency compounds: the longer a session
runs and the more the CLI refines its title, the further Desktop's frozen snapshot drifts
from the name I actually know it by.

Environment

• Claude Code CLI 2.1.246 (native install, ~/.local/bin/claude.exe)
• VS Code extension anthropic.claude-code-2.1.246-win32-x64 (bundles a byte-identical claude.exe)
• Claude Desktop 1.37937.1.0
• Windows 11 Pro 26200
• Auth: claude.ai subscription

Steps to reproduce

1. In the CLI, start a new session whose first prompt is too thin to title — literally mamamama.
2. Let the session settle, then open the Code tab in Claude Desktop.

• CLI and VS Code both show mamamama (first prompt as fallback).
• Desktop shows spec-rippling-deer.

1. Quit Desktop from the tray icon and relaunch it. The placeholder is still there.
2. Repeat with a titleable first prompt (what is the current date). All three clients agree

(Current date), because Desktop adopted the session after the title existed.

1. Repeat step 1 but start the session in Desktop. Desktop shows the first message —

no placeholder. The defect only affects sessions adopted from another client.

1. For the drift half: take any CLI-started session, let it run long enough that the CLI

rewords its aiTitle, and compare. Desktop keeps the original raw prompt.

Expected: all three clients show the transcript's newest aiTitle / customTitle.
Actual: Desktop shows a snapshot taken at adoption, or a placeholder name.

Evidence

Desktop's per-session record lives at
%APPDATA%\Claude\claude-code-sessions\<account>\<org>\local_<uuid>.json
and carries its own title / titleSource fields. Records written for Desktop-spawned
sessions carry a spawnSeed; records adopted from another client have spawnSeed: null.

Comparing every one of my Desktop records against the newest aiTitle / customTitle in the
matching ~/.claude/projects/**/<cliSessionId>.jsonl transcript:

| origin | matches transcript | mismatched | empty title |
|---|---|---|---|
| started in Desktop (spawnSeed set) | 26 | 0 | 0 |
| adopted from CLI / VS Code (spawnSeed: null) | 3 | 15 | 1 |

Every mismatch is the same shape — Desktop holding the raw first prompt while the transcript
has long since been retitled:

adopted | titleSource: auto
  desktop  : '[Image #1] why do i have 2 docker desktop showing in UnigetUI?'
  aiTitle  : 'Duplicate Docker Desktop entries in UnigetUI'

adopted | titleSource: auto
  desktop  : 'PS C:\Users\trax7> winget.exe update --id "JohnMacFarlane.Pandoc" -...'
  aiTitle  : 'Pandoc update failing with exit code 1603'

And the placeholder case — session 8f94555e-7576-4e4d-892f-a30328efdb1d:

// local_8f94555e-....json
{ "title": "", "titleSource": null, "spawnSeed": null, "completedTurns": 2 }

// 8f94555e-....jsonl  — the transcript has had a title all along
aiTitle: "Debug Link to Windows file access limitations"

Desktop renders that empty title as a generated placeholder like spec-rippling-deer. The
string never appears anywhere
under %APPDATA%\Claude\claude-code-sessions\, only in the app's https_claude.ai IndexedDB,
so it looks like a claude.ai-side placeholder that is displayed instead of, rather than
written into, the record — which is presumably why nothing ever overwrites it.

Why this is not a duplicate

• #83051 (Desktop import drops customTitle) is about the explicit title being lost at

import, and reports the record having no title field at all; on this build the field exists
and explicit titles do arrive. This is about the auto title never being re-read afterwards.

• #85431 (raw-first-prompt fallback has no disambiguation) accepts the raw-prompt fallback

and asks for disambiguation between identical rows. This report is that the fallback is
never replaced once a real title exists, and that a thin first prompt yields a permanent
placeholder instead.

Suggested fix

Treat the transcript as the authority the way the CLI and the VS Code extension do: re-read
the newest aiTitle / customTitle when listing sessions (or at least refresh it on adopt,
resume, and app start) unless titleSource == "user". Falling back to the first prompt when
there is no title yet would also match the other two clients and remove the placeholder names.