[BUG] Backgrounding a conversation (left arrow) continues it under a new session id; --resume shows a stalled duplicate of the original

Summary

Moving a conversation to the background (left arrow in an interactive session) continues it under a new session id. The original transcript stops within a few seconds and remains in ~/.claude/projects/<cwd>/ as a separate file. Both then appear in the --resume picker with the same title, and picking the original reopens the conversation as it was at the moment it was backgrounded. Nothing in the picker or the session indicates that the id changed.

The conversation is not lost — it continues under the new id. The problem is that the old id looks like the same conversation and resumes a stalled copy.

Version: 2.1.233–2.1.235, macOS 26.5.1, zsh, iTerm2. Reproduced in a plain iTerm session with no wrapper. Also reproduced inside a tmux-based wrapper; behaviour is identical.

Reproduction

1. claude, send one prompt (test), wait for the reply
2. Press the left arrow. The screen switches to the session list with the banner "Your conversation moved to the background — enter opens it · esc returns to it · ctrl+c twice quits"
3. Return to the conversation. All three ways behave the same: press esc; press Enter on the highlighted (same) session; or open a different session from the list and come back later
4. ls ~/.claude/projects/<cwd>/ now shows two jsonl files whose first timestamp field matches to the millisecond. The original has stopped; the new file carries the conversation on
5. claude --resume lists both with the same title

4 out of 4 attempts (esc, Enter, another session, and once in plain iTerm). 46 other sessions in the same project directory that were never backgrounded have no such twin.

Observed

Transcript files from one attempt (ids shortened; first timestamp of each file, last timestamp, line count):

5cfd35ef  first=03:15:56.647Z  last=03:16:13.286Z  26 lines   original, stopped
81ded1b0  first=03:15:56.647Z  last=03:21:38.639Z  46 lines   continues

~/.claude/sessions/<pid>.json for the same attempt:

pid 68531  sessionId 5cfd35ef…  kind:"interactive"  tmux:"…"  parkedJobId:"81ded1b0"
pid 53456  sessionId 81ded1b0…  kind:"bg"                      jobId:"81ded1b0"

So the interactive process records the new id as parkedJobId, and a second process of kind:"bg" runs under that id. The evidence block of #87131 (a different symptom) shows the same parkedJobId / jobId pair, so this is not specific to my machine.

Why it matters

• In the --resume picker the two entries show the same title and differ only in age and size, so the stalled one is easy to pick. Resuming it opens a conversation that ends at the background move. In one real case that was five hours of work that appeared to be missing until the other id was found
• The stalled file's mtime is still touched afterwards. Observed once: content ends 08-18 10:17 local, mtime 08-19 20:43, size 4,096,009 bytes. The picker showed it as "45 minutes ago" while its content was a day old. I have not identified what touches it
• Inferred, not measured: a tool that remembers the original id and later runs claude --resume <original-id> (a tmux wrapper, a session manager) will reopen the stalled copy after a process restart, with nothing to warn it. I hit this through such a wrapper, which is how I found the issue

Expected

Either keep the session id across the background move, or make the stalled original distinguishable in the picker (and leave its mtime alone), so the two entries can be told apart.