[BUG] Interactive session moves to the background with no /bg typed; /exit then only detaches
Summary
An interactive session moved to a background session twice on Linux and once on macOS. No /bg or /background was typed, and I didn't knowingly press ←. The new session continued the conversation under the original's name (on macOS with (2) appended). /exit in the terminal then only detached it; claude stop <id> was needed to end it. First seen on 2.1.287.
Environment
- Linux (Jetson, aarch64), tmux 3.4, used over SSH from iTerm2; Claude Code 2.1.296 at the first move and 2.1.292 at the second
- macOS Tahoe 26.6.2, iTerm2, Claude Code 2.1.287
"editorMode": "vim"
The two moves on Linux
| | first | second |
|---|---|---|
| time (UTC) | 2026-10-15 17:56:01 | 2026-10-16 03:53:05 |
| version | 2.1.296 | 2.1.292 |
| last turn ended | 11m42s before | 21 s before |
| background task running | one Bash command | none |
| daemon.log | bg spawned cfd02c45 (slash) | bg claimed-spare 2afb20bc (slash) |
In both cases the original transcript ends with a continued-in record naming the new session, and the new job's state.json has "template": "bg", "interactiveLineage": true, and "intent" set to my last prompt in the original session. My prompt history, which records slash commands, has no /bg or /background.
Which inputs move a session
Claude Code 2.1.292, each case a fresh session at an empty prompt. "tmux": tmux 3.4 with mouse on and extended-keys on, input written to an attached client. "No tmux": Claude Code on a bare pty, where it enabled mouse tracking (?1003h, SGR ?1006h), focus reporting (?1004h), and the kitty keyboard protocol (>5u). "Yes" means daemon.log recorded a (slash) spawn and the screen showed "Your conversation moved to the background".
| input | tmux | no tmux |
|---|---|---|
| ← (CSI D) | yes | yes |
| ← (ESC O D) | not run | yes |
| Esc, then ← | yes | yes |
| ←, then typing within 0.2 s | yes | not run |
| typing text, then ← | no | not run |
| trackpad scroll left or right (SGR wheel buttons 66, 67) | no | no |
| Option+← (CSI 1;3D, ESC b) | no | no |
| Shift+← (CSI 1;2D) | no | no |
| Esc, then h | no | no |
| Esc, then j | no | no |
| focus out and in (CSI O, CSI I; four combinations) | not run | no |
Only ← moves the session, and it produces the same daemon.log entry as both moves. I don't use tmux panes or arrow-key tmux bindings, and I wasn't typing in the session at either time, so I don't know what sent a ←, if anything did.
Expected
A session stays in its terminal unless I move it to the background. If one ← at an empty prompt is meant to move it, a confirmation step would keep a stray keypress from doing so.
Related
#83971: backgrounding seeds the new job with only the last prompt.