/resume picker shows empty after process exit, regardless of /rename, real prompts, or synthesized live PID metadata

Resolved 💬 3 comments Opened May 6, 2026 by yuval-s-wiz Closed May 6, 2026

Preflight

  • Searched related issues: #19933 (closed), #23375 (closed), #44969 (closed), #24435 (open), #29205 (open). None match this exact reproducer.
  • Single bug report.
  • Latest version: 2.1.119.

Summary

The /resume picker shows an empty list in any container/host where past claude-code processes have terminated (cleanly via /exit OR via SIGKILL). JSONL transcripts persist on disk and claude --resume <uuid> loads them correctly (when invoked from the matching cwd), but the picker hides them.

We ruled out the most plausible hypotheses (see "Tests that did NOT restore visibility" below). Without source access we cannot determine the exact predicate; the data should let an engineer with source pinpoint it quickly.

Reproducer

A. Container with multiple disconnected-but-still-running claude-code processes (TTY died via SSH/docker exec disconnect, process kept running):

  • 9 ~/.claude/sessions/<pid>.json files, all with procStart matching /proc/<pid>/stat field 22
  • 9 JSONL transcripts in ~/.claude/projects/<encoded-cwd>/
  • /resume picker shows all 9.

B. Container where past claudes have exited (clean /exit OR kill -9):

  • 1 sessions/<pid>.json (the current claude only)
  • 4 JSONL transcripts in same encoded-cwd dir
  • /resume picker is empty (current excluded as expected; past sessions not visible)
  • claude --resume <uuid> loads any of the 4 fine (when run from the embedded cwd)
  • claude --continue resumes the most recent session (different code path)

Tests that did NOT restore visibility

  1. /rename my-name, /exit, restart claude: renamed session does not appear in the picker. (Custom title appears stored in sessions/<pid>.json, removed at exit.)
  2. Start a session with a normal user prompt (no slash command, no synthetic block as first message), /exit, restart: not visible in /resume.
  3. Synthesize ~/.claude/sessions/<pid>.json pointing to a real, currently-alive claude-code process (procStart matching /proc/<pid>/stat field 22, sessionId of one of the historical JSONLs, cwd matching): not visible in /resume.

Test 3 was specifically designed to satisfy the most plausible "picker reads from sessions/<pid>.json, requires alive PID" hypothesis. It does not restore visibility, so the predicate is something else.

Environment

  • Claude Code: 2.1.119
  • Linux 6.17.0-1013-aws in a Docker container
  • Sessions started via claude --add-dir <d1> --add-dir <d2> from a long-running container; clients connect via docker compose exec -t. Disconnect leaves claude-code running inside the container (this naturally produces case A).

What we'd need from you

  1. Either the actual filter predicate for the picker enrichment pipeline, or a --debug=resume flag (or similar) that emits the predicate per-candidate-session so users can self-diagnose.
  2. Confirmation of intended behavior. Should /resume show only currently-running claude processes, or should it also surface past JSONL transcripts? --help says "Resume a conversation", which implies past.

Workarounds

  • claude --resume <uuid> (works, bypasses picker - must be invoked from the cwd embedded in the JSONL)
  • claude --continue / claude -c (works, uses different code path)
  • Find the UUID by scanning ~/.claude/projects/<encoded-cwd>/*.jsonl directly

---

Reproducer collected via strace-based diagnostic during a debugging session. Happy to provide the diagnostic script and full strace output if useful.

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗