[BUG] Session name lost after context compaction

+1, facing the same issue

related:

• #27195 — /rename sessions can't be found via claude -r <session-name> — session lookup is unreliable
• #30377 — /rename loses conversation history before the rename point
• #26134 — rename does not persist, --resume <name> never finds it (marked duplicate)

cc-memory addresses this with a different approach that's already working.

Instead of improving compaction, it moves context outside the window entirely:

• Full conversation turns stored in SQLite + ChromaDB (summarized,

just moved out)

• Semantic retrieval injects only relevant prior context back when needed
• Tiered injection: pinned decisions always included, past context

scored by relevance

• Cerebras compresses history for free before hitting Anthropic —

no token cost from your subscription

• Smart compaction with adaptive threshold — the proxy monitors context

density and only triggers compaction when the window crosses a dynamic
threshold. The threshold itself adjusts based on content type:
decision-heavy turns raise it, tool output-heavy turns lower it.
Compaction never fires blindly at a fixed percentage

• Density check before compaction — if the context is thin or mostly

recoverable content, compaction is skipped entirely

• Tool result summarization — bulky file reads and command outputs get

summarized before they bloat the window, recoverable content evicted first

• Second dedup pass after compression — if two turns converge after

cleaning, the duplicate never hits the API

The result: Claude remembers schema decisions, variable names,
architectural rationale across sessions — not just within one session.
Compaction becomes a last resort, not a constant interruption.

Working implementation if you want to try it today:
https://github.com.AbdoKnbGit/claude-code-memory

Please go away with the sales pitch spam.

just proposing an solution

I'm still seeing this, it's not clear to me what the point of /rename is if this isn't fixed.

Session metadata loss after compaction is a symptom of the same underlying problem — the JSONL gets rebuilt from a summarized state and anything not in the summary structure is lost.

We built Cozempic to defer compaction by pruning JSONL bloat before it fires, keeping the file lean enough that the original session structure (including metadata) survives longer. The doctor command also has a claude-json-corruption check that can detect when metadata has been dropped.

pip install cozempic && cozempic doctor

Open-sourced it because session data loss on compaction kept costing us work. Curious if others are seeing the name loss tied to specific session sizes — there may be a threshold pattern here.

What is it with all the sales pitches to use some third party solution that doesn't even fix the problem? Minimizing compaction does not fix the issue.

Fair point — my comment was off-target for this specific issue. Session name loss after compaction is a metadata persistence problem, not a bloat problem, and deferring compaction doesn't fix it. I shouldn't have stretched the framing. Leaving the original comment in case it's useful to anyone hitting the bloat-related symptoms, but you're right that it doesn't address the rename bug directly.

Claude Code's own comment on this bug:

Observation and hypothesis from a Claude session (2026-04-27), shared with the user's permission — analysis by Claude Sonnet 4.6

I hit this today and did some informal forensics on the session files. Sharing in case it helps narrow the root cause.

What I observed

The session was renamed via /rename several times during an active session. After context compaction triggered, a second Claude session described this
session as "unnamed", and the name badge in the bottom-right of the UI was absent on resume. Running /rename again in the resumed session immediately
restored the badge.

On the "new JSONL file" theory

I initially assumed compaction writes a new session file (new ID, name not carried over). The file evidence doesn't support this: the original JSONL
continued receiving writes after the compaction event, and claude -r <original-id> still resolves correctly. There appears to be only one session ID
throughout.

Proposed mechanism

If the JSONL stays in the same file, the name loss likely happens at the client's display layer rather than at the file level:

1. /rename writes a custom-title entry at some point T in the JSONL.
2. Compaction later injects a summary/continuation marker at T+N, and the client treats this as the logical start of the current context window.
3. When rebuilding display state (session list, name badge), the client reads JSONL entries from the compaction marker forward — the custom-title at T is

now behind that boundary and is not re-read.

1. No visible custom-title → session falls back to unnamed (or uses the compaction preamble text as the title).

This would explain why /rename after compaction works fine (the new entry lands after the boundary), and why any name set before compaction is silently
dropped.

Possible fix direction

When writing the compaction marker to the JSONL, emit a new custom-title entry immediately after it, copying forward any existing name. This keeps the
name within the "current window" regardless of when it was originally set.

---
This is behavioural inference — I haven't read the source. If the actual compaction path is in a known file it would be worth checking whether
custom-title is explicitly excluded or just overlooked during the continuation write.

Still reproducing on v2.1.149 (also v2.1.150) — ~90 versions past the #26121 "fix."

Additional findings from a forked session under explicit /compact <custom-args> (not auto-compaction):

1. The clobbered title is the parent session's custom-title, not a freshly-generated AI title

The fork's JSONL contains zero ai-title records — /compact did not trigger AI title regeneration. The value that overwrites the user's rename is byte-identical to the parent session's existing custom-title. So this isn't the auto-title generator misbehaving; it's a stale title being re-applied from inherited/parent state.

2. custom-title and agent-name are written as a pair — twice, back-to-back

Window around the bug in the fork's .jsonl:

line 2902: type=last-prompt        lastPrompt="<user prompt resumed from /compact>"
line 2903: type=custom-title       customTitle="Renamed Title B"        ← correct
line 2904: type=agent-name         agentName="Renamed Title B"          ← paired with 2903
line 2905: type=custom-title       customTitle="Original Title A"       ← BUG (parent's title)
line 2906: type=agent-name         agentName="Original Title A"         ← paired with 2905
line 2907: type=file-history-snapshot
line 2908: type=user               <next user message>

Two (custom-title, agent-name) pairs are written ~milliseconds apart, by two different code paths. The first writes the in-memory current value (correct). The second writes the parent's value (wrong). Whichever path runs second wins.

3. Earlier in the same session, the rename was working fine

The user's /rename is at line 1566; the title stays correct for ~1,300 records and through several earlier /compact invocations without args. The clobber happens only on the /compact that had custom args. May or may not be a coincidence — worth checking whether /compact <args> takes a different code path than /compact alone.

4. Other context

• Fork has sessionKind: "bg" (spawned via background mechanism). Unclear whether non-bg fork sessions show the same behavior — may be worth checking if title resolution diverges for bg sessions.
• Fork was created from a parent whose own custom-title had been set well before the fork point. Don't have data on whether a fork from a parent with only an ai-title would still get clobbered (would pinpoint whether the source is parent's custom-title field specifically or whatever the parent's "display title" resolves to).

Repro

1. In session A, set a custom title.
2. Fork A → B (B inherits A's title display).
3. In B, rename to a new title via the rename UI; verify it sticks for several turns.
4. Run /compact <any custom instruction> in B.
5. After compaction, B's title silently reverts to A's custom-title.

Side effect on /resume

Multiple forks of one parent all converge to the parent's title, making the picker ambiguous. Workaround: claude --resume <sessionId> directly, or append a fresh custom-title record to the JSONL with Claude Code closed.

Follow-up: this bug is not cosmetic. The clobbered title gets injected into the model's context as a behavioral steering signal, so it can silently override /compact's custom args.

What I found in the same JSONL

Continuing right after the bug moment (line 2905 = clobber, line 2908 = next user prompt), the very next records are:

line 2908: [user]                 "<the user's actual new prompt — a debugging question on a different topic>"
line 2911: [user/system-reminder] "<system-reminder>The user named this session 'Original Title A'.
                                    This may indicate the session's focus or intent.</system-reminder>"
line 2914: [user]                 "<verbatim re-injection of the parent session's original opening prompt>"

Two things happen at the moment a prompt fires after a title-clobbering /compact:

1. A <system-reminder> is injected telling the model the session's intent — using the clobbered (wrong) title. Whatever code path generates that "session intent" reminder reads the session's custom-title field. Because the bug has just overwritten it with the parent's title, the model is now being told the session is about Topic A, not the topic the user explicitly redirected to via /compact <custom-args>.

1. The parent session's original opening prompt is re-injected verbatim as a user-type record. This further anchors the model to the parent topic.

Observed downstream effect

After those injections, the model in this session spawned 21 Task sub-agent calls doing research on the parent's topic (not the user's new debugging topic). ~1,300 transcript records of work landed before the user noticed and hit Escape.

Why this matters

The original report frames this as titles reverting on /compact. The deeper failure mode is:

• /compact <custom-args> is the documented way to redirect a session to a new topic.
• The custom args do land in the /compact prompt itself.
• But the title-overwrite races with that, and the session-intent reminder injected on the next turn pulls from the post-clobber title, plus the parent's original opening prompt.
• Net effect: the model treats the user's redirect as a side-question and continues working on the parent topic. The user thinks they're in a new debugging session; the agent thinks it's still on the old one.

This bypasses one of the supported ways to refocus a session, so the impact is significantly larger than a wrong label in the picker.

Suggested investigation angle

Whatever code emits the "The user named this session '<title>'..." reminder should at minimum:

• Read from the session's current in-memory rename intent, not whatever the disk says the title is at injection time, or
• Suppress the reminder for N turns after /compact <args> ran, since the user has just made an explicit topic-redirect statement that should take precedence.

And separately, the parent-prompt re-injection on a forked session under /compact looks like fork-state-restore pulling from the parent rather than from the fork's own initial state — worth auditing the same path.