Session name lost after compaction — /rename breaks when context compacts

Bug Description

When a Claude Code session is /renamed (e.g., /rename gsd-plan), the name is stored as a custom-title entry in the session JSONL file tied to a specific session UUID. When the user runs /clear, a new session UUID is created but the name is not carried forward. The old named session becomes an orphan with stale history, and the running instance continues on an unnamed session.

Root cause confirmed: /clear creates a new session JSONL file with a new UUID. The custom-title entry from the old session is not copied to the new session. The user's named session is now stuck pointing at pre-/clear history.

Evidence from JSONL forensics

Original session (be04e4d2, named gsd-plan):

• Last entry: 2026-04-01T17:31:18.973Z — turn_duration system message, 374 messages
• Has custom-title: "gsd-plan" entry

Continuation session (cd957439, unnamed):

• First entry: 2026-04-01T17:39:07.579Z — file-history-snapshot
• Second entry: /clear command (<command-name>/clear</command-name>)
• No custom-title entry — name was not carried forward
• User later renamed to gsd-planning (slightly different name, user error because they didn't realize the original name was lost)
• No parentSessionId field — no link back to the original session

Timeline: old session ends at 17:31 → 8 minute gap → new session starts at 17:39 with /clear as first real command.

Steps to Reproduce

1. Start Claude Code: claude
2. Rename the session: /rename my-session
3. Do some work (build up conversation history)
4. Run /clear
5. Observe: new session UUID created, name lost
6. Exit and try: claude --resume my-session
7. Result: Resumes the pre-clear session state, not the post-clear continuation

Expected Behavior

• /clear should preserve the session name on the new session UUID
• The custom-title entry should be written to the new JSONL file after /clear
• If /clear cannot preserve the name, it should warn: "This will create a new session. Your session name 'my-session' will need to be re-set with /rename"
• parentSessionId should be set on the new session linking to the old one (enables session chain traversal)

Actual Behavior

• /clear creates a new UUID and JSONL file without the custom-title
• The old JSONL retains the name but is stale (pre-clear state)
• The running Claude instance is now on an unnamed session
• User loses the ability to resume by name
• No parentSessionId field links the sessions

Impact

This is especially painful for long-running workflows where:

• Multiple named sessions run in parallel tmux panes (gsd-plan, gsd-execute, meta-director)
• Sessions are expected to survive across /clear operations (which are recommended by GSD workflows: "/clear first → fresh context window")
• Scripts use --resume <name> to reconnect (e.g., claude --resume gsd-plan)
• The session name is the only discoverable handle — UUIDs are not human-usable

GSD workflows routinely recommend /clear before heavy execution phases to free context. Every /clear silently orphans the session name, making --resume useless.

Suggested Fix

On /clear:

1. Read custom-title from the current session JSONL
2. Write it as the first entry in the new session JSONL
3. Set parentSessionId on the new session pointing to the old UUID
4. Optionally: --resume <name> should follow the parentSessionId chain to find the latest session with that name

Alternative: Store session names in a separate index file (name → latest UUID) rather than embedding in JSONL. Update the index on /clear, compaction, or any session fork.

Environment

• Claude Code v2.1.89
• macOS Darwin 25.3.0
• tmux 3.x with multiple named sessions
• Model: Opus 4.6 (1M context)