[BUG] Interactive session was backgrounded with no user input (dispatch source "slash") while a /loop was running

What's Wrong?

The user did not touch the keyboard. ~/.claude/history.jsonl has no input at all between 20:36:07Z and 21:03:19Z (no /bg, no /background, nothing).

Yet at 20:56:07Z the transcript shows system: "Backgrounding after the current tool finishes…", then continued-in at 20:56:10Z.

~/.claude/daemon/roster.json for the new job:

"source": "slash",
"launch": {"mode": "resume", "fork": true, "flagArgs": ["--reply-on-resume","--permission-mode","auto"], "restoresTranscript": true},
"seed": {"intent": "[Request interrupted by user]", ...}

daemon.log: daemon start version=2.1.281 origin=transient at 20:56:10.543Z, bg spawned <id> (slash).
The original session file shows "status":"busy","parkedJobId":"<id>".

The same second, ~/.claude/.last-update-result.json records a native auto-update 2.1.280 → 2.1.281 at 20:56:10.075Z.

We checked that no local helper program sent a / or ← key at that time, and the assistant's tool calls in that window contain no key-sending commands.

What Should Happen?

A session should only be backgrounded when the user runs /bg / /background or presses ← on an empty prompt (per https://code.claude.com/docs/en/agent-view). It should not be backgrounded with no input, and the dispatch should not be labelled as a slash command the user never typed.

Steps to Reproduce

Not reliably reproducible by us. Circumstances:

1. Interactive session on 2.1.280 with a /loop 3m task firing, assistant mid-turn.
2. Native auto-update to 2.1.281 completes (binary already downloaded earlier).
3. No user input for 20+ minutes.
4. Session is backgrounded at the same second as the update result is written.

Claude Code Version

2.1.280 → 2.1.281

Additional Information

Windows 11 Home (build 26200.9550), Windows Terminal 1.24, Korean IME. Claude Code native install; interactive session started on 2.1.280, native auto-update to 2.1.281 recorded at 2026-09-23T20:56:10Z (the same second the session was backgrounded).

Side effect: the /loop in the new background session stopped firing on its own (separate report).