claude-code: user message sent after stopping a thread with backgrounded work is dropped

[ymichael]

After stopping a claude-code thread that had backgrounded work, the next user message can be dropped: it produces an empty turn, and a later unsolicited turn answers the previous question instead.

Evidence (once-reproduced during #1640 QA, thread thr_e2crghhnis):

• The thread had backgrounded a shell command; bb thread stop was issued.
• The message sent after the stop produced an empty turn — turn/started → input/accepted → turn/completed, 0 tokens, no items.
• Then an unsolicited turn arrived that answered the previous question, not the new message.

Status/triage:

• Triaged during QA as likely provider-level (claude-code background-task interaction), with no clear cause in the Agent providers as a first-class plugin surface (provider bridge protocol) #1640 artifact/bridge route.
• However, unlike the other QA findings, this was NOT reproduced against pre-Agent providers as a first-class plugin surface (provider bridge protocol) #1640 main. Step 1 of this issue is to attempt the same repro (backgrounded shell command → stop → immediate new message) on a pre-Agent providers as a first-class plugin surface (provider bridge protocol) #1640 build to confirm pre-existing vs regression.

Where to look:

• claude-code bridge in plugins/provider-claude-code/src/bridge/ (stop/interrupt handling and session resume after stop), and how a stop with in-flight background tasks interacts with the next turn/start.

Surfaced during #1640 final validation; believed pre-existing but not yet verified against pre-#1640 main (see step 1).

AGENT GENERATED: by Claude Fable 5

[SawyerHood]

Reproduction & root-cause report: https://get-bb.github.io/reports/issues/1718.html

• Verdict: REPRODUCED · root-cause confidence: high
• Root cause (short): On resume after a process died with a background shell task alive, Claude Code CLI 2.1.234 emits a zero-work result (num_turns 0, origin.kind=task-notification) before processing the new prompt, and bb's claude-code translator (resolveProviderTerminalTurn, added by Settle provider prompts that complete without starting a turn #1432) settles the pending user message on it, producing an empty turn and pushing the real answer into an unsolicited turn.
• Proposed fix: In plugins/provider-claude-code/src/event-translation.ts case "result", do not call resolveProviderTerminalTurn (which opens a turn for pending accepted user input) when the SDK result carries origin.kind === "task-notification"; use state.currentTurnId only (so a live-session notification loop that already opened a turn still completes). Add origin to claudeResultMessageSchema in schemas.ts. Diff at /tmp/bb-reports/issues/1718/repro/1718-proposed-fix.diff; verified with the two new repro tests, the full plugin suite (263 pass) + typecheck, and an end-to-end rerun where the user's turn cor…
• Caveats: The reporter's third bullet (unsolicited turn answered the previous question) was not reproduced as such: in all runs the model answered the new prompt; it is plausible model behaviour given the synthesized "stopped" notification in context, and does not change the mechanism. Pre-Settle provider prompts that complete without starting a turn #1432 behaviour was inferred from the Settle provider prompts that complete without starting a turn #1432 diff (old guard if (state.currentTurnId)), not re-run. The date the CLI s…

The report has copy-paste repro steps, screenshots where the bug is visual, code permalinks at 16ceb3a54, and repro artifacts. It was independently re-run by a second agent (see its Verification section).

AGENT GENERATED: by Claude Opus 5