Background-job sessions unrecoverable via --resume despite intact transcripts (no signal they exist)

Bug: Background-job sessions are unrecoverable through normal --resume, despite intact transcripts

Summary

A completed background-job session (sessionKind: "bg") cannot be restored through the
normal resume flow, even though its transcript is fully intact and valid. The session does
not appear in the interactive --resume picker, and claude --resume is silently scoped to
the current directory's project bucket — so from the "wrong" cwd it finds nothing. The net
effect is a perfectly recoverable session that appears permanently lost. This is a UX/clarity
defect: there is no signal telling the user the session exists but is filtered out or filed
under a different project.

Environment

• Claude Code: 2.1.175 (session created) / 2.1.177 (current)
• Platform: Linux
• Session kind: background job (daemon backend), launched with --agent claude --permission-mode auto

What happens

1. A background job runs to completion (state: "done" in ~/.claude/jobs/<id>/state.json).
2. User later tries to restore the session via the interactive --resume picker → the session

is not listed (the picker only surfaces foreground sessions).

1. User tries claude --resume from their default/home directory → not found, because resume

is scoped to the current directory's project slug, and the transcript was filed under a
different project (the session had /cd'd into a subdirectory, so its records carry several
cwd values and the file lands under the final cwd's slug, while the job's originCwd
differs).

1. Conclusion a normal user reaches: "the session is gone / corrupt."

Reality (verified)

• Transcript file exists, ~1 MB, 644 lines, every line valid JSON, ends with newline — no

corruption, no truncation. Contains 93 user + 188 assistant turns.

• The session does resume correctly when invoked by explicit full ID *from the matching

project directory*: claude --resume <full-uuid> -p "..." → succeeds, exit 0.

So nothing is lost — but discovering the correct invocation required manually inspecting
~/.claude/projects/**/*.jsonl and ~/.claude/jobs/<id>/state.json. A typical user has no way
to know any of this.

Expected behavior (any one of these would resolve it)

• Background-job sessions should be discoverable/listable in --resume (or a clearly labeled

equivalent), not silently filtered out.

• When claude --resume <id> is given an ID that exists under a different project dir than the

current cwd, emit an actionable message (e.g. "session <id> exists under project <path>; cd
there or run from that directory") instead of "not found".

• The jobs UI should expose a direct "resume this session" affordance for completed bg jobs.

Why this is worth fixing

The data layer is correct; the failure is entirely in surfacing and messaging. Users experience
it as data loss. Clear signposting (list it, or tell them where it lives) turns an apparent loss
into a one-line fix.

Repro sketch

1. Start a background job; let it /cd into a subdirectory during its run; let it finish.
2. From your home directory, run the interactive --resume picker → bg session absent.
3. claude --resume <that-session-id> from home → not found.
4. cd into the subdirectory the session ended in, re-run claude --resume <id> → works.