agents-view: clear(new)/clear(reset) orphans previous session, invisible in --resume picker
Summary
When a session in agents-view has a customTitle and the user invokes clear(new) or clear(reset) inside it, Claude Code writes a brand new jsonl that reuses the same customTitle but is NOT linked to the original cloud session (cse_*). The previous jsonl — which holds the actual conversation content — is left on disk but becomes unreachable:
- agents-view no longer shows it (only the active cloud-bridged session is listed)
claude --resumepicker does not surface it either (appears to dedupe / collapse sessions sharing the samecustomTitleunder the same cwd)
The conversation transcript still exists at ~/.claude/projects/<encoded-cwd>/<session-id>.jsonl, but there is no UI path that leads back to it. The only way to recover is to know the exact session UUID and run claude --resume <uuid> manually.
Plain clear (transcript clear without starting a new session) does NOT trigger this bug — only the variants that allocate a new session id (clear(new), clear(reset)) do.
Environment
- Claude Code version: 2.1.143
- OS: macOS 15.x (Darwin 25.5.0)
- Shell: zsh
- agents-view feature: enabled (introduced 2.1.139+)
Steps to reproduce
- In a project directory, start a session via agents-view and set a
customTitle(e.g. "Project X workflow review"). The session becomes bridged to a cloud session idcse_*. - Have a real conversation in that session (multiple user/assistant turns).
- Invoke
clear(new)orclear(reset)from inside that session one or more times. (Plaincleardoes not reproduce this.) - Quit Claude Code.
- Try to find the original conversation again via:
claude agents— only the cloud-bridged session is listedclaude --resume(from the same cwd) — the original session is NOT in the picker; only the most recent same-title session shows
- Inspect
~/.claude/projects/<encoded-cwd>/. The original jsonl is still there, with full user/assistant content intact.
Expected behavior
After clear(new) / clear(reset), the previous session should remain discoverable. At minimum, one of the following should hold:
- The
--resumepicker should list ALL sessions in the current cwd, disambiguating same-title entries by timestamp / preview / id suffix. - Or
clear(new)/clear(reset)should give a clear UX hint: "your previous conversation has been archived; resume it withclaude --resume <uuid>". - Or agents-view should surface orphaned-but-on-disk sessions under a "previous" / "archived" view.
Actual behavior
The previous session becomes a "ghost":
- exists on disk
- has full conversation content
- has zero UI path to recover it
- user has no way to know its session UUID without manually grepping the projects directory
Evidence from a real case
In one user's project directory, five .jsonl files all share customTitle = "<same title>":
session first_ts (TW) last_user_ts last_asst_ts u-count a-count bridge
e514e217 05/15 20:47 05/18 10:17:47 05/18 10:17:47 306 605 -> cse_01... (current cloud-bridged session, last
assistant content is
"No response requested." - a hook event)
761c8d15 05/16 02:39 05/18 10:09:24 05/18 10:10:09 142 230 none <- ORPHAN: contains the real last conversation
93784464 05/18 10:11:18 05/18 10:11:18 (none) 1 0 none <- clear(new) artifact
8c7efc15 05/18 10:11:38 05/18 10:11:38 (none) 1 0 none <- clear(new) artifact
4ed081de 05/18 10:16:44 05/18 10:16:44 (none) 1 0 none <- clear(new) artifact
Timeline:
10:09:24 user msg in 761c8d15 (real workflow review discussion)
10:10:09 assistant response in 761c8d15 <- last real conversation turn
10:11:18 user invoked clear(new) -> 93784464 created (1 user msg, no response)
10:11:38 user invoked clear(new) -> 8c7efc15 created (1 user msg, no response)
10:16:44 user invoked clear(new) -> 4ed081de created (1 user msg, no response)
10:17:47 e514e217 receives a system hook event
(assistant content: "No response requested.")
10:39:50 e514e217 last bridge-session heartbeat
claude agentsonly displays the active cloud-bridged session (e514e217).claude --resume(in the same cwd) lists at most one entry for that title — apparently the most recently mtime-updated one (e514e217, because its bridge-session heartbeat keeps updating mtime). The user selects it expecting to land back in the workflow review, but the actual conversation in that jsonl ends with "No response requested." — they are dropped into the wrong session.- The real last conversation is in
761c8d15, which is invisible to both UIs.
Impact
- Users lose access to real conversation history via the documented UI.
- "Where did my conversation go?" is hard to diagnose; the user must know how to grep
~/.claude/projects/and identify session UUIDs by hand. - The
clear(new)/clear(reset)actions implicitly violate the contract suggested by documentation: docs say deleting from agents-view keeps the transcript available viaclaude --resume.clear(new)/clear(reset)are not delete actions, but the end-user effect is the same — the previous conversation becomes unreachable via--resumetoo.
Workaround
Manually recover the UUID and force-resume:
# find candidate jsonls in the encoded project dir
ls -lat ~/.claude/projects/<encoded-cwd>/*.jsonl
# inspect customTitle and last assistant timestamp inside each jsonl
# then force resume by UUID
cd <original-cwd>
claude --resume <session-uuid>
Suggested fixes (any one would help)
- Picker fix: list ALL sessions per cwd; disambiguate same-title entries by last-message timestamp and a short id suffix.
clear(new)/clear(reset)fix: when the previous jsonl has substantive content, either keep it bridged to the same cloud session, or print a clear recovery hint with the UUID andclaude --resume <uuid>command.- agents-view fix: add an "archived" / "previous turns" view that surfaces orphaned but on-disk jsonls under the same
customTitle.
Notes
- Data is NOT lost — this is purely a discoverability bug.
- Severity: medium-to-high for users who rely on long-running agents-view sessions and use
clear(new)/clear(reset)as a "soft reset" mid-task. - Plain
clear(transcript clear only) is unaffected.
This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗