[BUG] Parking a mid-flight turn leaves the interactive session's probe stuck at status: "busy" forever (2.1.220)

Summary

Parking a turn that is mid-flight rewrites the interactive session's probe file at ~/.claude/sessions/<pid>.json with parkedJobId set, but leaves status: "busy" in place — and no further write ever corrects it. The session returns to an idle prompt and its probe claims busy for as long as the process lives.

Any tool that reads these probe files (the documented way to know what a session is doing) then shows the session as working indefinitely. Two of mine sat "working" for 22h and 32h.

Version: 2.1.220 (macOS 15, claude from a tmux pane).

Reproduction

1. Submit a prompt in an interactive session — probe goes status: "busy".
2. While that turn is still running, park it (background the job).
3. The parked job runs to completion in its background session and that session's probe goes idle.
4. The interactive session returns to an empty prompt, 0% CPU.
5. ~/.claude/sessions/<interactive pid>.json still reads status: "busy", forever.

Parking while the session is idle is fine — the idle status is preserved correctly. 4 out of 4 sessions on this machine followed that split: the two parked mid-turn were stuck, the two parked while idle were clean.

Evidence

The interactive probe, ~22h after the fact (session at an idle prompt the whole time):

{"pid":16304,"cwd":"…/nautiseven","kind":"interactive","status":"busy",
 "statusUpdatedAt":1786804845800,   // 09:40:45 — the busy transition
 "updatedAt":1786804861210,         // 09:41:01 — the park write, status left busy
 "parkedJobId":"d8d56f6f","bridgeSessionId":null,"version":"2.1.220"}

The background session that took the job — same cwd, matching id, correctly idle:

{"pid":56821,"cwd":"…/nautiseven","kind":"bg","status":"idle",
 "jobId":"d8d56f6f","statusUpdatedAt":1786847881206,   // 21:38, ~12h after the park
 "updatedAt":1786847881206,"version":"2.1.220"}

The interactive file was never written again (mtime = the park write). A second pair had the identical shape with an 891s gap between the busy transition and the park write.

Process state of the stuck sessions: S+, 0.0% CPU, children are only the configured MCP servers — no tool or agent subprocesses. The panes show a finished recap and an empty prompt.

For contrast, every genuinely-busy probe sampled at the same moment had updatedAt == statusUpdatedAt and no parkedJobId.

Expected

Parking a turn should write the interactive session's status transition (to idle, or to whatever state a session with a parked job should report) rather than leaving the pre-park busy frozen in the file. Alternatively, clearing parkedJobId and refreshing the status when the parked job finishes would also resolve it.

Workaround

Deleting the stale probe file clears it until the next park. Consumers can also detect the residue: on a stuck probe updatedAt > statusUpdatedAt — the last write did not set the status the file carries — whereas a genuine busy transition writes both stamps together.