Session name set by /rename is overwritten after /resume

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/22994
2. https://github.com/anthropics/claude-code/issues/23274
3. https://github.com/anthropics/claude-code/issues/22938

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 can confirm that this issue can easily be reproduced on version 2.1.34

<img width="684" height="667" alt="Image" src="https://github.com/user-attachments/assets/fd00d8d7-fce0-48e0-bd16-c6691d8f3641" />

up

up, please this is really annoying!

Adding another voice here — this is a significant UX blocker for power users.

I run multiple concurrent Claude Code sessions across different projects and tasks. /rename is great for labeling terminal tabs, but the fact that session names don't persist through /resume makes session management painful in practice:

• After a restart, /resume shows a list of auto-generated titles that all look similar
• I've accidentally launched the same session multiple times because I couldn't tell them apart
• I end up hopping between sessions trying to find the right one

This feels like a small fix that would be a big unlock. /rename should durably set the session name so it survives resume cycles. Right now the feature is half-built — it names the tab but the name evaporates on resume.

Please fix this, it would be highly impactful.

ROOT CAUSE

In the compiled bundle (versions/2.1.39), the function yw8 performs a fast metadata read of session JSONL files for the /resume picker:

let BbR = 16384;  // 16KB tail buffer
let J = Math.max(0, R - BbR);  // offset = fileSize - 16KB
let W = /* read last 16KB of file */;
let Q = nKT(W, "customTitle");  // string scan for customTitle

The /rename command (function x$T) appends a single line to the JSONL:

{"type":"custom-title","customTitle":"my-name","sessionId":"<uuid>"}

This line is ~80–100 bytes. After 16KB of additional conversation (roughly 2–5 more exchanges depending on tool use), the custom-title line falls outside the tail window and nKT returns null.

The full JSONL parser (R1T) correctly reads custom-title events from anywhere in the file, but R1T is only used for the first ~10 sessions shown in the picker (the “enrichment” pass via A1T). All other sessions use the fast yw8 path and lose their titles.

---

REPRODUCTION

1. Start a new session:

``
claude
``

1. Rename it:

``
/rename test-rename-bug
``

1. Have a conversation that generates >16KB of JSONL content

(typically 3–5 exchanges with tool use, or ~10 text-only exchanges)

1. Exit the session

1. Run:

``
claude
``

1. Open /resume and search for test-rename-bug

1. Expected: Session appears with custom title
2. Actual: Session appears with first prompt text, not searchable by title

---

VERIFICATION

To confirm the bug on any session, check if the custom-title line is in the last 16KB:

python3 -c "
import os, json, sys
path = sys.argv[1]
size = os.path.getsize(path)
tail_start = max(0, size - 16384)
offset = 0
with open(path) as f:
    for line in f:
        if '\"custom-title\"' in line:
            in_tail = offset >= tail_start
            obj = json.loads(line.strip())
            print(f'{\"OK\" if in_tail else \"MISS\"}: {obj.get(\"customTitle\")} (offset={offset}, tail_starts={tail_start})')
        offset += len(line.encode('utf-8'))
" ~/.claude/projects/<project-dir>/<session-id>.jsonl

---

WORKAROUND

Re-append the custom-title line to the end of affected JSONL files. This puts it back within the 16KB tail window:

python3 -c "
import json, os
from pathlib import Path
TAIL = 16384
for d in (Path.home() / '.claude/projects').iterdir():
    if not d.is_dir(): continue
    for f in d.glob('*.jsonl'):
        size = f.stat().st_size
        title_line = title_off = None; off = 0
        with open(f) as fh:
            for line in fh:
                if '\"custom-title\"' in line:
                    try:
                        obj = json.loads(line.strip())
                        if obj.get('type') == 'custom-title':
                            title_line, title_off = line.strip(), off
                    except: pass
                off += len(line.encode('utf-8'))
        if title_line and title_off < max(0, size - TAIL):
            with open(f, 'a') as fh: fh.write(title_line + '\n')
            print(f'Fixed: {json.loads(title_line)[\"customTitle\"]}')
"

This can be automated via a Stop hook in ~/.claude/settings.json:

{
  "hooks": {
    "Stop": [{
      "hooks": [{
        "type": "command",
        "command": "claude-rebuild-session-index -q",
        "timeout": 10
      }]
    }]
  }
}

---

SUGGESTED FIX (UPSTREAM)

Option A (minimal):
In x$T (the /rename handler), after writing the custom-title event, also write it as the last line of the file. The duplicate is harmless since R1T uses Map.set() which overwrites, and nKT just does a string scan. This ensures it is always in the tail.

Option B (better):
In yw8, if nKT fails to find customTitle in the tail buffer, fall back to scanning from the head. The custom-title line is small and typically near the end of the non-message section, so a secondary scan of the first ~64KB would catch it.

Option C (best):
Avoid relying on tail-scanning for metadata. Write an explicit metadata header or maintain a small sidecar JSON file per session (e.g., <session-id>.meta.json) that stores customTitle, tags, and other metadata written by slash commands. This removes the dependency on JSONL byte offsets entirely.

---

RELATED ISSUES

• https://github.com/anthropics/claude-code/issues/23610

“Session name set by /rename is overwritten after /resume”

• https://github.com/anthropics/claude-code/issues/16973

“Conversation name lost in active session after /resume”

Both likely stem from the same 16KB tail-read limitation.

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.