/rename without arguments still broken on resumed sessions (stale-closed #26686)

Found 2 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/26686
2. https://github.com/anthropics/claude-code/issues/27668

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

This is session-state carryover failure at the command boundary.

If /rename without arguments is still broken specifically on resumed sessions, then something in the resumed session state is preserving a stale closure or invalid command context that the fresh-session path does not have.

Why it matters:

• resumed sessions are supposed to preserve useful continuity, not preserve broken command state
• commands that work fresh but fail after resume undermine confidence in whether session restoration is actually coherent
• when a stale-closed issue reappears only on resumed sessions, users cannot trust that lifecycle transitions preserve a valid control surface

I would want clarity on:

1. whether the resumed session is restoring stale command metadata, stale UI bindings, or a previously invalid argument state
2. whether /rename is failing before command parsing, during command resolution, or in the post-resume session adapter
3. whether resumed sessions can run a lightweight command-surface reinitialization so built-ins do not inherit broken closed state

Session continuity needs fresh validity, not stale residue. If resumed sessions keep a broken /rename path alive after the original issue was considered closed, the resume boundary is rehydrating the wrong state.

@0xbrainkid Great analysis — you're on the right track. Did some more digging and here's what I found:

Root cause: JSONL replay failure on resume, not stale command state

The /rename auto-generate reads from the in-memory conversation message history that the harness loads from the session JSONL file at startup. "No conversation context yet" literally means: the loader didn't reconstruct any usable message history into memory.

So it's not really a command-parsing or argument-resolution issue — /rename itself works fine. The problem is upstream in the conversation replay that feeds it.

Why resumed sessions hit this

Session JSONL files are append-only logs with no upfront index. On resume, the loader scans sequentially to find the "live" conversation endpoint. There are known failure modes here (some previously fixed, clearly not all):

1. Dead-end branch anchoring — if the session wasn't cleanly closed (force-quit, crash, terminal kill), the loader may anchor on a dead-end branch instead of the live conversation chain. This was partially fixed in a prior release (Fixed --resume/--continue losing conversation context on large sessions when the loader anchored on a dead-end branch), but clearly doesn't cover all cases.

1. Write gaps — if the JSONL buffer wasn't fully flushed on exit, the next resume encounters incomplete records. The loader can't confidently determine where the conversation ends and falls back to an empty context.

1. Subagent interleaving — subagent messages landing near a main-chain write gap can cause the loader to bridge into an unrelated conversation branch (also previously fixed for some cases).

The key point: the harness successfully "resumes" the session (you can keep chatting, tool use works, Claude has context via the system prompt and compacted history) — but the parsed message objects that /rename reads from may not be populated. The LLM gets context through a different path (compacted prompt) than what /rename inspects.

This also makes me wonder — why does /rename use a separate context source at all? The LLM clearly has enough context to continue the conversation coherently. It can reference earlier turns, recall tool outputs, maintain topical continuity. If /rename auto-generate simply asked the same LLM "suggest a short name for this session," it would work every time, regardless of session lifecycle. Instead it inspects a raw message list that may or may not be populated depending on how the JSONL loader fared. Feels like the LLM context is the more reliable source of truth here.

What "not properly closed" means

A session is not properly closed when the process exits without writing a terminal state marker or flushing the JSONL buffer — e.g., Ctrl+C during a tool call, terminal window closed, SSH disconnect, or process crash. On next resume, the loader has to guess where the live conversation ended.

Why this also happens in fresh sessions (per #26686)

The original report (#26686) noted this happening in fresh sessions too (not just resumed ones), which suggests there may be a second issue: the in-memory message list that /rename checks might not be the same object that accumulates conversation turns. Could be reading from a separately-scoped context that never gets populated.

Reproducing

I can confirm this is still broken on v2.1.123. In this very session (long multi-turn conversation with extensive tool use), /rename without arguments returned the same error. Providing a name explicitly works fine.

What would fix it

The simplest and most robust fix: make /rename auto-generate a model call using the same conversation context the LLM already has. Ask the model "suggest a short name for this session" — it already knows what the session is about. This sidesteps all the JSONL replay fragility entirely.

If that's too heavyweight for a slash command, then at minimum:

1. Fall back to reading the session JSONL file directly when the in-memory message list is empty
2. Fix the error message — "no conversation context yet" implies it'll work later, but it never does in the same session; it should say "conversation context not available" and suggest the explicit /rename <name> form

Reproducing on Linux/WSL with Bedrock backend, and one fresh data point

Same bug, different environment:

• Claude Code 2.1.132
• AWS Bedrock (CLAUDE_CODE_USE_BEDROCK=1, eu.anthropic.claude-opus-4-7)
• Linux 6.6.87.2 / WSL2

Triggers in active sessions too, not just resumed ones — happens consistently in tool-heavy multi-turn conversations (mine: 75 user + 119 assistant messages, plenty of plain text content, ~260-line transcript on disk).

Diagnostic — narrows it down

I ran with CLAUDE_CODE_DEBUG=1 and --debug. The renaming flow y38 → LnH → k38 has three silent null-returning paths, only the third logs:

async function LnH(messages, signal) {
  let q = k38(messages);
  if (!q) return null;            // path 1 — silent
  try {
    let K = await DN({...});
    let A = T7(N9(K.message.content));
    if (A && typeof A === "object" && "name" in A
        && typeof A.name === "string") return A.name;
    return null;                  // path 2 — silent (model output schema mismatch)
  } catch (K) {
    y(`generateSessionName failed: ${NH(K)}`, {level:"error"}); return null;  // path 3 — logged
  }
}

generateSessionName failed: does not appear in the debug log — so this is not a model-call exception. It's either path 1 (k38 returning empty for an in-memory message list whose shape differs from disk) or path 2 (model output failing the {name: string} schema check).

Suggested fixes

1. Distinguish the three failure modes in user-facing message + log all three.
2. Fall back to a deterministic name (truncated first user prompt) when path 2 fails.

Workaround confirmed: /rename <explicit-name> works.

Hi @sosukesuzuki is this fixed? Why is it marked as closed?

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.