fix(server): stop Claude resume handshakes from completing turns that never ran

[gfsaaser24]

What Changed

A Claude SDK result arriving when the adapter has no local turn state no longer emits a turn.completed with no turnId. The token-usage emission stays; a structured claude.turn.result-without-active-turn log replaces the event so the trigger stays measurable in the field. As defense in depth, ingestion's lifecycle guard now only applies completions that name their turn when no active turn is tracked.

Why

Resuming a Claude session makes the CLI answer with system/init plus a result(num_turns: 0, zero usage) handshake. The adapter's result handler treated that like any other result: with no turnState it emitted an untargeted turn.completed, and ingestion's strict guard — which rejects untargeted completions while a turn is active — fell through to accept them when activeTurnId was null. That is exactly the state while a turn start is pending, so the phantom flipped the session from "starting" back to "ready" for a turn that never ran.

A result with no local turn is never a real turn's completion: real turns get turnState in sendTurn, and assistant messages arriving outside a turn auto-start a synthetic one. What lands in that branch is the resume handshake, a late result for a turn already completed locally, or a stream failure with nothing in flight. Every adapter was audited before tightening ingestion — Codex populates turnId from notification.params.turn.id on the wire; Grok, Cursor, and OpenCode attach it unconditionally — so no legitimate completion becomes rejectable. Consumers were audited too: nothing reads the suppressed event's payload, checkpoint capture already requires a turnId, and no client consumes raw turn.completed.

Three new tests. The two suppression tests fail against the unfixed code (verified by reverting the sources and re-running); a targeted-completion control proves late-but-real completions still land. ClaudeAdapter + ProviderRuntimeIngestion: 114/114 on this base, typecheck clean.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes (no UI changes)
• I included a video for animation/interaction changes (n/a)

---

Change authored by Claude Fable 5 via Claude Code.

---

Note

Medium Risk
Changes provider runtime event emission and orchestration turn lifecycle guards; behavior is narrow and well-tested but affects session state transitions during Claude resume and pending turn starts.

Overview
Fixes a bug where resuming a Claude session could flip thread session state from starting to ready even though no user turn had finished.

Claude adapter: When a SDK result arrives with no local turnState (resume handshake num_turns: 0, late results, etc.), the adapter no longer emits an untargeted turn.completed. It still records token usage and logs claude.turn.result-without-active-turn for observability.

Ingestion (defense in depth): If no active turn is tracked, turn.completed is applied only when the event includes a turnId. Untargeted completions are ignored so they cannot clear a pending turn start.

Tests cover adapter suppression, ingestion reject/accept behavior, and a small harness dispatch helper.

^{Reviewed by Cursor Bugbot for commit e670eb0. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Fix Claude resume handshakes from emitting untargeted turn.completed events with no active turn

• When ClaudeAdapter receives a result with no active turnState (e.g. during a resume handshake), it no longer emits an untargeted turn.completed event; it logs a claude.turn.result-without-active-turn info entry and only emits token usage.
• ProviderRuntimeIngestion now rejects untargeted turn.completed events (those lacking a turnId) when no active turn is tracked, preventing the thread lifecycle from advancing incorrectly.
• Targeted turn.completed events that include a turnId are still accepted regardless of whether an active turn is tracked.
• Behavioral Change: sessions that previously transitioned out of starting due to a spurious untargeted completion will now remain in starting until a real turn completes.

^{Macroscope summarized e670eb0.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 4a8002ec-665e-4f09-8ae4-dc6897f465cf

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[macroscopeapp]

Approvability

Verdict: Approved e670eb0

This is a well-scoped bug fix that prevents Claude resume handshakes from incorrectly completing turns that never ran. The changes are defensive (rejecting invalid events), clearly documented, and include comprehensive test coverage for both the rejection and acceptance paths.

^{You can customize Macroscope's approvability policy. Learn more.}

Dismissing prior approval to re-evaluate e670eb0

[gfsaaser24]

Pushed e670eb0 to fix the Check failure.

The two tests I added each seeded their session with an inline Effect.runPromise(harness.engine.dispatch(...)), which took ProviderRuntimeIngestion.test.ts from 31 to 33 manual runtime calls — one past its no-manual-effect-runtime-in-tests baseline.

The harness already wraps its other runtime entry points (readModel, drain), so dispatch is wrapped the same way: one dispatch helper next to the engine, used for the three seed commands in createHarness and exposed on the harness for the new tests. That puts the file at 29 occurrences — under the baseline — rather than raising the baseline number.

Test-only, no production code touched. Locally: vp check clean, ProviderRuntimeIngestion 47/47, ClaudeAdapter 67/67, server typecheck clean.