[BUG] Renamed session works on first resume but the name disappears after the second exit

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/23610
2. https://github.com/anthropics/claude-code/issues/22994
3. https://github.com/anthropics/claude-code/issues/23422

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

I looked at all three flagged issues and here is why this is not a duplicate of any of them.

#23610 is on macOS (v2.1.33) and talks about the rename being overwritten in a general sense. My issue is specifically about the rename working fine for the first resume cycle and then failing on the second one. That two step inconsistency is the core of what I am reporting. Also I am on Windows 11 and the behavior might have a different cause on this platform since session handling has had Windows specific bugs before (#23726 for example).

#22994 is about a completely different problem. That issue is about session names showing raw XML markup like <command-name>/rename</command-name> instead of clean titles. The rename overwrite is mentioned as a secondary note there, not the main bug. My issue has nothing to do with XML markup in session names.

#23422 is already closed and was reported on Linux (v2.1.32). That issue describes the session name becoming empty after resume. In my case the name does not become empty. It gets replaced by an auto generated title. Different behavior, different platform, and that issue was closed without a confirmed fix.

The specific thing I am reporting is the inconsistent one time persistence where the first resume honors the custom name but the second one does not. None of these three issues describe that exact pattern.

I'm experiencing this on macOS with version 2.1.39. Session rename works during
the session but reverts to the first message after exit. This started happening
after updating - worked fine in previous versions.

Issue persist in v2.1.44 as well.

Confirming — Multiple Instances Daily, Feb 18, 2026

Still completely broken on latest (Bun Canary v1.3.9-canary.51, Windows 11, Opus 4.6).

I rename every session to track my work (e.g., /rename vold formula fix, /rename settings and permissions, /rename ML retrain v4). Every single one:

1. Rename appears to succeed — session title updates in the current session
2. Name lost on exit — Ctrl+E shows auto-generated name, not the custom name
3. Cannot resume by name — --resume <name> doesn't find it
4. Stacks with #24729 — the session index itself is stale (separate bug), so even auto-names are hours behind. Custom names are gone entirely.

This is happening 5+ times today alone. Every session rename is wasted effort.

Root Cause (from #26249)

@ThatDragonOverThere found it: /rename stores the name only as a message inside the session JSONL file — a command tag, not metadata. The sessions-index.json has no name or displayName field. So the rename is:

• Never written to the index
• Never searchable
• Lost after the current session ends

Related Issues

• #26249 — rename not indexed (root cause analysis)
• #26134 — rename doesn't persist (Windows)
• #25905 — rename makes sessions unresumable (macOS)
• #24729 — session index itself broken since ~2.1.30

Impact

For power users managing 10+ sessions per day, /rename is the only way to keep track of what's what. Without it, the session picker is a wall of auto-generated summaries that all look the same. Combined with the stale index (#24729), session management is essentially broken.

Another Instance — Feb 19, 2026

Just renamed this session with /rename settings and permissions. Rename appeared to succeed (title updated in TUI). Exited, came back — name gone. Back to auto-generated summary.

That's now 6+ failed renames across 2 days. Every single /rename is thrown away on exit. The feature literally does not work.

Version: Bun Canary v1.3.9-canary.51, Windows 11

Update — Feb 20, 2026: Partially Working, Inconsistent

The rename behavior is now intermittent, which is almost worse than fully broken because you can't predict it.

I've started renaming sessions immediately on open. Out of my current session list:

Working renames (persisted and visible in Ctrl+E picker):

• [Smith River] ✅
• [bug manager] ✅
• [permissions manager] ✅

Failed renames (reverted to auto-generated summary):

• Several sessions renamed today show auto-generated summaries instead of custom names

Pattern: No obvious difference between the sessions that kept their names and the ones that didn't. Same version, same environment, same workflow. The rename either sticks or it doesn't, seemingly at random.

This inconsistency suggests the name persistence has a race condition or timing dependency — maybe related to when the session JSONL gets flushed to disk, or whether compaction occurs before the name is written to the index.

Version: Bun Canary v1.3.9-canary.51, Windows 11, Opus 4.6

Correction/Clarification on Previous Comment

All renamed sessions show the correct custom name in the terminal tab title. So the name IS persisted in the session JSONL. The failure is specifically in the Ctrl+E session picker — it sometimes shows the custom name and sometimes falls back to the auto-generated summary.

This confirms @ThatDragonOverThere's root cause analysis from #26249: the name is stored as a message in the JSONL but the session index/picker doesn't reliably extract it. The terminal tab reads it correctly; the resume picker doesn't.

So the bug is narrower than "name not persisted" — it's "session picker doesn't reliably read the persisted name back." Likely a timing or indexing issue in the stat-based session loader introduced in v2.1.30.

Another Instance — Feb 21, 2026

Yet another renamed session lost its custom name in the Ctrl+E picker. Same day, some renames stick and some don't. No pattern I can identify — same version, same workflow, same timing.

Current session list shows a mix of working custom names ([Smith River], [bug manager], [permissions manager]) and sessions that reverted to auto-generated summaries despite being renamed.

This is now the 3rd day in a row reporting this. The inconsistency is the worst part — if it always failed you'd stop using it. Instead it works just often enough that you keep trying, and half the time your name vanishes.

Version: Bun Canary v1.3.9-canary.51, Windows 11

Still Broken — Feb 21, 2026 (4th Day Running)

Custom names display correctly in the terminal tab title but do NOT appear in the Ctrl+E resume picker. The picker shows auto-generated summaries instead.

This confirms the bug is specifically in the session picker/indexer, not in name persistence. The name IS saved (tab reads it), the picker just doesn't.

4th consecutive day reporting this. Daily occurrence.

Version: Bun Canary v1.3.9-canary.51, Windows 11

6 Tabs, Zero Names in Picker — Feb 23, 2026 (5th Day Running)

6 open sessions right now, all with custom names visible in terminal tab titles. Ctrl+E resume picker shows auto-generated summaries for all of them. Have to guess which session is which every time I switch.

This is a daily-driver workflow killer. I have specialized sessions ([bug manager], [1-min models], [shock features], etc.) and the resume picker makes me play roulette with which one I'm opening.

The name IS persisted (tabs read it correctly). The session picker/indexer just doesn't display it.

5th consecutive day reporting. 6 concurrent sessions affected.

Version: Claude Code latest, Bun v1.3.10, Windows 11

Still Broken in v2.1.50 — Feb 23, 2026

The v2.1.47 fixes (#23610, #26121, #25789) did NOT resolve this.

6 concurrent sessions, all renamed via /rename. Tab titles show correct custom names. Ctrl+E resume picker shows auto-generated summaries for all 6.

This is not a compaction issue or a resume issue — the names persist in storage and display in tab titles. The picker simply never reads them back.

Version: Claude Code v2.1.50, Bun v1.3.10, Windows 11
5th consecutive day reporting.

First-party verification on v2.1.50 (Windows 11 Pro)

Confirming this issue is still present in v2.1.50. I inspected my local session storage (94 JSONL session files) and found:

• 9 renamed sessions have valid custom-title entries in their JSONL transcript files
• None of the 9 appear in sessions-index.json (which has only 22 entries)
• The sessions-index.json schema (version 1) has no customTitle, displayName, or name field. Its fields are: sessionId, fullPath, fileMtime, firstPrompt, summary, messageCount, created, modified, gitBranch, projectPath, isSidechain

The custom-title entries in the JSONL files are correctly formatted:

{"type": "custom-title", "customTitle": "...", "sessionId": "..."}

The data is persisted but never read by the indexer.

Additional observations:

• Terminal tab titles display the custom name correctly (read from JSONL)
• Ctrl+E session picker and --resume lookup show auto-generated summaries instead
• One session had 8 successive custom-title entries from multiple renames, confirming /rename executes without error but has no durable effect on session discovery

This aligns with the root cause identified in #26249 and #27202. The fix would need to add a customTitle field to the session index schema and have /rename write to both the JSONL transcript and the index.

Is there a fix in progress or a timeline for resolution? Happy to provide additional diagnostic data if helpful.

v2.1.55 Regressed Session Naming — Feb 25, 2026

v2.1.53 (released ~12 hours ago) fixed this — custom names appeared in the Ctrl+E resume picker for the first time in weeks. I verified across 6+ sessions.

v2.1.55 (released ~3 hours later, same day) regressed it. Names are gone from the picker again. Tab titles still show custom names. Picker shows auto-generated summaries.

Timeline

| Version | Session Names in Picker | Notes |
|---------|------------------------|-------|
| v2.1.47-v2.1.52 | No | Broken for weeks |
| v2.1.53 | Yes | Fixed\! Names visible, correct |
| v2.1.55 | No | Regressed — names gone again |

v2.1.55 Changelog

The only change listed in v2.1.55 is:

Fixed BashTool failing on Windows with EINVAL error

So the session naming regression was either:

1. An unintended side-effect of the EINVAL fix
2. A revert of v2.1.53 changes that included the naming fix

Root Cause (from @ascender1729's analysis above)

The \ schema has no field for custom names. Names are stored as \ entries in session JSONL files but the index never reads them back. v2.1.53 apparently added this read-back; v2.1.55 removed it.

Environment: Claude Code v2.1.55, Windows 11 Pro Build 26200, Bun v1.3.10
Affects: #24729, #26123, #26134, #25905

Additional scenario: Name lost during context compaction / /clear

The existing reports focus on names lost across exit/resume cycles. There's a related but distinct scenario affecting power users with multiple concurrent sessions in the same directory:

Problem: When context compaction triggers automatically (context overflow) or via /clear, the session name is lost. The user may not even be present when this happens — compaction runs unattended during long-running agent tasks.

Why existing workarounds don't help:

• MEMORY.md / CLAUDE.md instructions can't encode per-session names because all sessions in the same directory share those files
• Hooks can't run /rename (no CLI command access from hook scripts)
• Shell aliases don't help because the name loss happens mid-session during automatic compaction

Use case: Multiple terminal tabs, each with a named session (e.g., MOBILEZ, BACKEND, TESTS), all in the same project directory. After context overflow triggers compaction in any tab, that session's name is gone.

Root cause is the same as identified by @ascender1729: session name needs to be stored as durable metadata in the session index, not just as a custom-title entry in the conversation JSONL. Compaction rewrites conversation context but should never touch session metadata like the custom name.

Environment: Claude Code latest, Linux (WSL2), Opus 4.6

v2.1.62: /rename Still Not Persisting (Mar 2, 2026)

Confirming this bug persists on v2.1.62 (npm install, Node.js runtime).

The /rename command appears to work in-session — it confirms "Session renamed to: [name]" — but the name does not persist to the Ctrl+E resume picker. On resume, sessions revert to the default auto-generated name or show no name at all.

This is a daily frustration when running 4-6 concurrent sessions for different tasks (bug management, ML training, paper trading, etc.). Without persistent names, the resume picker is a wall of identical-looking sessions and you have to guess which is which.

Reproduction (v2.1.62, Windows 11, npm install):

1. Start a session
2. Run /rename [Bug Manager]
3. See confirmation: "Session renamed to: [Bug Manager]"
4. Exit session
5. Ctrl+E to resume — name is gone, reverted to default

This has been reproduced across v2.1.50, v2.1.53 (briefly fixed then regressed in v2.1.55), v2.1.55, v2.1.59, v2.1.61, and now v2.1.62. The brief fix in v2.1.53 proves Anthropic knows where the bug is — it just regressed immediately.

Previous reports in this thread: @ascender1729 confirmed on v2.1.50, @zeveck reported names lost on compaction/clear, @chiragpurohit71085 and @downspot also confirmed. This affects Windows, macOS, and VS Code users.

Addendum: Intermittent, Not Consistent (Mar 2)

Correction to my previous report — the rename doesn't ALWAYS fail. It's intermittent:

• Sometimes /rename sticks across exit/resume
• Sometimes it reverts to the default name
• Same session, same workflow, same version — different results

This is arguably worse than a consistent failure because you can't predict when it will work. The user runs /rename [Bug Manager], /rename [Agent 1 MFE 5 Min], /rename [Paper Trading] etc. across 4-6 concurrent sessions every day. Some stick, some don't. No obvious pattern to which ones persist and which revert.

The intermittent nature suggests a race condition in the session metadata write — possibly the same non-atomic write pattern that was causing .claude.json corruption (fixed in v2.1.61). If the session metadata file has the same write-without-fsync-rename pattern, concurrent sessions could be stomping on each other's renames.

Another manifestation: Custom agents intermittently missing from agent list (v2.1.69)

Same persistence bug family as rename — created a custom agent, it didn't appear in the agents list. Gone for the rest of the evening session. Showed up the next morning without any changes.

The agent definition file was on disk the whole time (just like renamed sessions have the name in the JSONL). The index/listing mechanism intermittently fails to pick up new entries until some later point — whether that's a cache refresh, a file watcher that missed the event, or a stale index that only rebuilds on certain triggers.

Pattern across rename + agents:

• Data is persisted to disk correctly
• The listing/picker UI doesn't reflect it
• It works "eventually" with no user action
• Intermittent — sometimes it sticks immediately, sometimes it doesn't

v2.1.69's /resume picker fix ("show your most recent prompt instead of the first one, resolves some titles appearing as (session)") may address part of this for sessions, but the agent list appears to have the same underlying issue.

Windows 11, Claude Code v2.1.69, Node.js v24.14.0 (npm install).

Additional symptom: auto-generated custom-title entries not reflected in /resume picker

I'm seeing a related manifestation of this bug. Claude Code auto-generates custom-title entries in the JSONL transcript (AI-summarized session names), and these show up in the terminal title. However, when I close the session and open /resume, the auto-generated title doesn't appear — the picker shows the truncated first prompt instead.

This is the same root cause: sessions-index.json is lazily updated and doesn't sync custom-title entries from the JSONL transcript. /rename works in /resume because it explicitly updates the index, but auto-generated titles only land in the JSONL.

Repro:

1. Start a new session, chat enough for Claude Code to auto-generate a session title
2. Observe the terminal tab shows the AI-generated title
3. Exit the session
4. Run /resume — the session shows the truncated first prompt, not the auto-generated title

Workaround: I built hooks that fall back to parsing the JSONL transcript when sessions-index.json doesn't have the entry — checking for custom-title entries first, then the first user message. This tiered approach (index → JSONL fallback) might be useful for the /resume picker itself.

Root cause identified: 64KB tail-read window in lite session loader

I traced through the compiled binary (v2.1.72, macOS arm64) and found the specific code path that causes this bug.

How /resume reads session titles

The /resume picker uses a "lite" loader (woK function) that does NOT parse the full JSONL. Instead, it reads only the first 64KB and last 64KB of the file (S3_ = 65536 in uH8), then string-searches for metadata fields:

// uH8: reads head (first 64KB) + tail (last 64KB)
let K = await R.read(q, 0, S3_, 0);           // head
let O = Math.max(0, T - S3_);                  // tail offset
let A = O === 0 ? $ : await (async () => {
    let H = await R.read(q, 0, S3_, O);        // tail
    return q.toString("utf8", 0, H.bytesRead);
})();

// woK: searches customTitle in TAIL only
j = rg(K, "customTitle");   // K = tail buffer (last 64KB)

The rg function scans all occurrences of "customTitle":"..." in the buffer and returns the last match. If no custom-title record exists within the last 64KB, the title is lost.

Why titles disappear after continued conversation

1. /rename writes a custom-title JSON line to the JSONL
2. After the rename, auto-title generation stops (respects user's manual title)
3. User continues chatting — each turn appends messages, tool results, file-history-snapshot, progress records, etc.
4. These new records push the custom-title line beyond 64KB from the file end
5. Next /resume call reads only the last 64KB → custom-title not found → falls back to first prompt

Verified with real data

My session f4187d1d (20MB JSONL, 1517 lines):

| Event | Byte offset | Distance from title |
|-------|------------|-------------------|
| /rename writes custom-title | 19,950,786 | 0 |
| 3 conversation rounds later | 20,210,805 | 253.9 KB |
| Title disappears from /resume | — | > 64KB window |

The custom-title record was pushed 253KB from the end after just 3 rounds of conversation — far beyond the 64KB read window.

Why it sometimes works

The system periodically writes custom-title as part of session save points (after stop_hook_summary, turn_duration, etc.). When this periodic write happens, the title is refreshed near the end of the file. But after context compaction (compact_boundary) or when auto-titling is suppressed (because user already renamed), the periodic write stops, and the gap grows.

Suggested fix

Either:

1. Always append custom-title at every save point, even when the title hasn't changed (ensures it stays within the 64KB window)
2. Increase the tail read window for large files (e.g., scale with file size)
3. Store titles in a separate index that doesn't depend on JSONL tail-scanning (the sessions-index.json approach others have mentioned)

Environment: macOS 15.5, Claude Code v2.1.72, Opus 4.6

This issue is part of a family of ~20 bugs that all stem from the same root cause: the VS Code extension reads titles by raw-string-scanning the last 64KB of each JSONL file, which causes title eviction on long sessions, cross-session contamination from tool result content, and overwrite-on-resume.

See #33165 (comment: https://github.com/anthropics/claude-code/issues/33165#issuecomment-4070011372) for the full root cause analysis, all related issues collected, and a working workaround (persistent title registry + hook).

it is getting worse in v2.1.7x ! always show last prompt in the resume screen !!

Additional finding: custom-title entries being removed from JSONL entirely

This isn't just about the 64KB tail-read window. I'm seeing custom-title entries completely disappear from session JSONL files — not pushed out of range, but gone from the file entirely.

Evidence

Session on Windows 11 (WSL2), Claude Code v2.1.76–2.1.78:

1. /rename was executed successfully — session name appeared in the prompt line and resume picker
2. Later, the session reverted to showing the last assistant message as the title
3. Inspecting the JSONL file: zero custom-title entries exist anywhere in the file — not at the beginning, not at the end, nowhere
4. No compaction events occurred in this session (verified by scanning all entry types)
5. All entry types present: assistant, file-history-snapshot, last-prompt, progress, queue-operation, system:local_command, system:stop_hook_summary, system:turn_duration, user — but no custom-title
6. Other sessions in the same project directory that were renamed DO still have their custom-title entries

Implication

The root cause identified by @Astro-Han (64KB tail-read in the lite session loader) explains some cases, but this is a separate or additional issue: the custom-title record is being deleted from the JSONL by some operation. Since no compaction occurred, something else is rewriting or truncating the file and dropping the entry.

This means workarounds that re-append custom-title to keep it in the tail window won't help if the entry is being actively removed.

Environment

• Claude Code v2.1.76–2.1.78
• Windows 11 Pro (WSL2, Linux 6.6.87.2)
• Opus 4.6

Regression in v2.1.79 — /rename broken again

/rename (session naming) is broken again as of v2.1.79. This is a regression — the fix that shipped in v2.1.75/v2.1.76 has broken.

Timeline:

• Original bug reported and confirmed
• Fix shipped in v2.1.75, verified working in v2.1.76
• Both this issue (#25090) and #24729 were marked CLOSED after user confirmation
• v2.1.79: broken again — same symptom has returned

Symptom: Session names set via /rename do not persist. Same behavior as the original report.

Platform: Windows 11, CLI

Request: Please reopen this issue. The underlying fix has regressed 3 versions after it was confirmed working. Something in v2.1.77–v2.1.79 has re-introduced the bug.

cc @anthropics/claude-code-team

couldn't be more frustrated that this is constantly something i fight. search can't find anything meaningful either. And past conversations come in and out of the resume window at random times. i open a file, start working in it, try to find it again an hour later, it no longer has the name. well documented by everyone, literally the append name is a broken pattern. would be thrilled if someone cared enough to fix this core functionality rather then shipping new features every 12 minutes that break something new.

Additional data point: name lost after 13-day idle period

Renamed a session via /rename on 2026-03-10. Came back to resume it on 2026-03-23 (13 days later). The custom name was gone from both the /resume picker and the status line. Had to search through transcript files to recover the session UUID.

• Claude Code version: unknown at time of rename, currently 2.1.81
• Platform: Anthropic API
• Terminal: iTerm2
• OS: Ubuntu/Debian Linux (Docker container)
• Exit method: unknown (don't remember whether it was Ctrl+C×2 or terminal close — which itself highlights the problem: users shouldn't need to remember how they exited for the name to persist)

✍️ Author: Claude Code with @carrotRakko (AI-written, human-approved)

Still broken on v2.1.90 (April 2, 2026). User had to /rename the same session four times across v2.1.89 and v2.1.90 — name does not persist. Nothing in the v2.1.90 changelog addresses rename persistence.

v2.1.92 — still broken. This session has been renamed to [Bug Manager] more times than I can count across v2.1.89, v2.1.90, v2.1.91, and v2.1.92. The name never persists. Five releases, zero acknowledgment, zero fix.

v2.1.96 - still broken, the renamed session doesn't appear in the list. Moreover, trying to run claude --resume "sessionName" messes up the UI so that I can't understand what's happening or how to fix it.
Had to search through the jsonl files to find the UUID and resuming with the --resume UUID worked but it's really frustrating.

Same issue here. I rename almost every session and it's extremely frustrating that the name silently disappears after the next resume+work cycle. A rename should be permanent — period. The current behavior where the custom title only survives one resume cycle makes the feature essentially broken for anyone who uses it regularly.

Environment: Claude Code CLI, macOS (Darwin 25.3.0), Opus 4.6

A workaround is to add session name in the status line. Can be done by a manual update (https://code.claude.com/docs/en/statusline) or by using https://github.com/sirmalloc/ccstatusline