claude-code - 💡(How to fix) Fix agents-view: clear(new)/clear(reset) orphans previous session, invisible in --resume picker

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

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 --resume picker does not surface it either (appears to dedupe / collapse sessions sharing the same customTitle under 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.

Root Cause

  • claude agents only 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.

Fix Action

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>

Code Example

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

---

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

---

# 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>
RAW_BUFFERClick to expand / collapse

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 --resume picker does not surface it either (appears to dedupe / collapse sessions sharing the same customTitle under 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

  1. 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 id cse_*.
  2. Have a real conversation in that session (multiple user/assistant turns).
  3. Invoke clear(new) or clear(reset) from inside that session one or more times. (Plain clear does not reproduce this.)
  4. Quit Claude Code.
  5. Try to find the original conversation again via:
    • claude agents — only the cloud-bridged session is listed
    • claude --resume (from the same cwd) — the original session is NOT in the picker; only the most recent same-title session shows
  6. 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 --resume picker 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 with claude --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 agents only 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 via claude --resume. clear(new) / clear(reset) are not delete actions, but the end-user effect is the same — the previous conversation becomes unreachable via --resume too.

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)

  1. Picker fix: list ALL sessions per cwd; disambiguate same-title entries by last-message timestamp and a short id suffix.
  2. 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 and claude --resume <uuid> command.
  3. 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.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

After clear(new) / clear(reset), the previous session should remain discoverable. At minimum, one of the following should hold:

  • The --resume picker 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 with claude --resume <uuid>".
  • Or agents-view should surface orphaned-but-on-disk sessions under a "previous" / "archived" view.

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING