Settle provider prompts that complete without starting a turn

[jerrison]

Fixes #1431.

The original diagnosis and narrow Claude Code fix are Jerrison's work. This
branch preserves that commit and credits Jerrison on the generalized change.

Problem

Claude Code handles /clear locally and returns a successful zero-work result:
there is no assistant message, stream event, or tool call to start a bb turn.
The result handler previously required state.currentTurnId, so it emitted no
turn/completed. The thread remained active, bb thread wait --status idle
hung, and accepted input queued behind the abandoned turn could not drain.

The underlying lifecycle problem is broader than Claude's /clear: a provider
can accept a prompt and then report a terminal signal before emitting any of the
ordinary activity that starts a bb turn.

Contract

Provider terminal translators now resolve the turn through one shared rule:

1. Complete the currently open turn when one exists.
2. Otherwise, start and complete a synthetic turn only while accepted input is
   still pending.
3. Emit nothing when neither condition holds.

The pending accepted-input queue is the ownership proof that keeps this narrow.
onTurnStart drains it, so a late terminal signal cannot open a second empty
turn after the real turn has already closed.

Provider coverage

• Claude Code: a terminal result can settle accepted input even when no
  earlier SDK message started the turn. This covers the /clear regression.
• ACP: turn/completed follows the same terminal-turn rule.
• Pi: agent_end follows the same rule, and the bridge reports when
  session.prompt() settles without producing an SDK event.

Codex is unchanged because its native lifecycle already settles this shape.

The synthetic lifecycle also drives the existing server completion path, so a
queued message is sent after the zero-work turn completes instead of remaining
stuck.

Deliberate non-goals

• Process-detach recovery remains separate and is covered by Settle pending turns when providers exit before turn start #1234.
• This does not add a general stuck-turn watchdog or reconciler.
• This does not introduce a provider-independent /clear command or a new
  first-class clear timeline event; it fixes settlement when a provider handles
  a prompt without ordinary turn activity.

Wire compatibility

HOST_DAEMON_PROTOCOL_VERSION is bumped to 115 because Pi now sends a
prompt-settled bridge event that can change host-daemon event output.

Verification

• @bb/agent-runtime: 941 tests passed across 46 files.

• @bb/server: 1,470 tests passed across 162 files.

• @bb/host-daemon-contract: 49 tests passed across 3 files.

• Typechecks passed for @bb/agent-runtime, @bb/server, @bb/host-daemon,
  and @bb/host-daemon-contract through Turbo.

• Live reproduction against the source-built app:

  bb thread tell <id> "/clear"
  bb thread wait <id> --status idle --timeout 60

  The thread reached idle in 1.6 seconds, and its accepted-message queue was
  empty afterward.

[jerrison]

Thanks @ymichael for the hardening commit — I have left it untouched.

Two updates: this is verified end-to-end now, and the branch is unconflicted again.

Verified against a running app

The caveat in the description no longer holds. I still have not built bb from source, so instead I applied the equivalent edit to the shipped daemon bundle of bb 0.37.0 on macOS, immediately before the minified gate if(i.currentTurnId){ in host-daemon/dist/daemon-bundle.mjs:

i.currentTurnId||i.pendingAcceptedUserMessages.length>0&&e.ensureTurnStarted({events:n,state:i,threadId:r});

I have an automated case in my own repo — a harness that drives the bb CLI against a real thread — which asserts the defect: send /clear, then expect the turn not to settle within 45s and the thread to still be active. On 2026-08-12 it flipped, on the same machine and bb version, with the patch as the only change:

	Before	After
bb thread wait --status idle --timeout 45	timed out	reached idle
thread status	active	idle
wall clock for the case	54.2s	5.5s

The 5.5s is the part I would look at: it is no longer waiting out the bound at all. sdk/conversation_reset still arrives first and the context is genuinely empty afterwards, so the Clear itself is unchanged — the turn now just ends with it. No second, empty turn opened on any run.

What this does not cover. It validates the logic, not your compiled artifact: my edit is the minified equivalent of the diff, applied by script and checked with node --check, not a source build. One machine, one provider (claude-code), model claude-haiku-4-5. Please read it as a strong signal rather than a substitute for CI.

Merged main, and took protocol version 113

#1427 landed with HOST_DAEMON_PROTOCOL_VERSION = 112 while this branch was also sitting on 112, so both sides claimed the same number and the same block of contract.test.ts. Resolved in 2fe2b95 by taking 113 and keeping #1427's 112 line in the version history, so the two read in landing order.

Worth flagging for anything else racing a protocol bump: commands.ts merged clean and was still wrong. Both sides had made the byte-identical 111 → 112 edit, so git saw no conflict and only the contract test caught the collision.

I merged rather than rebased so as not to rewrite your commit. Happy to squash or rebase if you would rather the branch were linear.

One question, and one ask

Question. #1427 adds clearActiveTurnState?() for the same class of bug — a provider reporting no active turn — but keys off isAcpProviderId and an ACP bridge error code, so it does not reach the claude-code result path. I have kept this on ensureTurnStarted. If you would rather it route through the new hook, say so and I will rewrite it.

Ask. The workflow run on 2fe2b95 is sitting at action_required — fork PRs here need "Approve and run". CI was green on 1eaac7c, and the only changes since are the merge and the 112 → 113 bump.

[ymichael]

Sorry my agent was too eager and pushed before I told it to - working on some changes here so we get this fix in for all providers - ty for your patience