[Bug] Interactive resume of re-homed background session corrupts terminal PTY

Bug Description
Claude Code background-session interactive-resume corrupts terminal (survives fresh terminal + tab close, no live process afterward)

Version: first observed on 2.1.232; affected session originated on 2.1.227 and lived through 5 consecutive binary auto-upgrades (2.1.227→228→229→231→232) while running as an idle background job.
Platform: Linux, Tilix terminal emulator, Claude Enterprise account, Remote Control was active on the affected session.

Summary:
A long-lived background session ("bg" job, started via a slash command in an interactive session) survived multiple binary auto-upgrades over ~2 days. daemon.log shows the background worker being silently re-homed to a new spare process across restart cycles — evidence below (session ID is a random UUID, not identifying):

[2026-08-12T09:12:09.409Z] [bg] bg spawned <session-id> (slash)
[2026-08-13T06:49:01.325Z] [bg] bg settled <session-id> (done)
[2026-08-13T06:49:36.232Z] [bg] bg claimed-spare <session-id> (fleet)
[2026-08-13T09:30:51.946Z] [bg] bg adopt: adopted=0 respawned=0 dead=3
[2026-08-13T09:31:01.421Z] [bg] bg claimed-spare <session-id> (fleet)
[2026-08-14T09:30:36.535Z] [bg] bg settled <session-id> (killed)
[2026-08-14T09:31:00.218Z] [bg] bg claimed-spare <session-id> (fleet)

Note the "adopted=0 respawned=0 dead=N" line immediately followed by "claimed-spare" — the original worker died across a supervisor restart and got reattached to a fresh spare process, with no user action, on more than one occasion during this session's lifetime.

After this pattern, resuming the session through either interactive attach path — the claude agents "needs input" list, or the /resume picker inside a running session — reliably left the terminal in a corrupted state: keystrokes (arrows, Ctrl+C, typed text) were echoed back as literal raw control sequences (e.g. ^[[A, ^[[B, ^C), with no working prompt. This reproduced every time via either interactive path, including in a freshly opened terminal tab after closing the corrupted one.

Notably:

• Resuming the SAME session non-interactively via claude --resume <session-id> --fork-session on the command line did NOT reproduce the corruption — full history replayed cleanly, no crash, no garbage.
• reset and stty sane typed blindly into the corrupted pane had zero visible effect (no prompt ever reappeared) — suggesting the pty's master side may already have been closed, not just left in raw mode.
• ps showed no process anywhere referencing the affected session ID once corrupted — the backing worker had already exited.
• Workaround found: from claude agents, press Ctrl+X twice to stop/delete the stuck background job, then run /resume on the same session ID — this reattaches cleanly under the same ID.

Hypothesis: bug is in the interactive-picker reattachment path specifically for background sessions that have been silently re-homed to a new spare worker across one or more supervisor restarts/binary auto-upgrades. Reproduces via interactive attach only, not via direct non-interactive --resume.

Likely related to but distinct from #12483, #18418, #38578 (terminal left in raw mode by a still-identifiable crashed process) — here reset/stty sane had no effect at all and no process remained, pointing at the background-job reattachment/spare-handoff logic rather than a generic raw-mode leak.

Environment Info

• Platform: linux
• Terminal: vte-based
• Version: 2.1.232
• Feedback ID: 581e3c12-673a-469c-9a18-066e3beb8627

Errors

[]