(bug) First approval on a non-first turn always evicts the parked warm session and replays cold

[mmabrouk]

When an agent run pauses on a tool approval and I answer it from the playground, the runner evicts the parked warm session and replays the whole turn cold, but only when the gated turn is NOT the session's first user turn. The first turn resumes warm as expected.

Observable in the runner logs when it happens:

[keepalive] approval-mismatch (history) ...; evict + cold
[HITL] cold replay: ... resumeFrame=approval

Steps to reproduce (dev stack, Pi harness, permission mode allow_reads):

1. Start an agent session, send any first message, let it finish.
2. Send a second message that triggers a gated bash call and wait for the approval card.
3. Approve it and watch the runner logs: the parked session is evicted with approval-mismatch (history) and the turn replays cold.
4. Same experiment on a fresh session's very first message resumes warm, no eviction.

The answer still reaches the model correctly, so this is a performance and latency bug, not a correctness one: every non-first-turn approval pays a full cold replay, which is most expensive exactly when the turn carries attachments. Subsequent approvals in the same turn resume warm again, which is why it looks intermittent.

Seen on the v0.107.0 base plus the multi-modality train, 2026-08-01; the comparison logic on main is stricter and hits related cases (see #5593).

[linear-code]

AGE-4050

[dosubot]

This looks closely related to #5593, which you already referenced — the same [keepalive] approval-mismatch (history) eviction pattern appears there too.

The likely root cause is in how the history fingerprint is compared on resume. The keep-alive pool hashes "ordered user message texts and tool-call IDs" when parking a session [1]. On a first turn, the history is trivial (one user message, no prior tool calls), so the hash the playground sends back matches easily. On non-first turns, two things can diverge between what was parked and what the playground reconstructs for the resume /run call:

1. Tool message synthesis in prior turns — the playground stores approved tool calls as a two-message sequence (assistant + synthesized role: "tool" with empty content). If the runner's parked fingerprint included tool-call IDs from earlier turns in a different form than the playground's reconstruction, the hash breaks.

2. Message filtering on reconstruction — constructChatHistory runs validity checks and .filter(Boolean) before sending, and uses includeLastMessage: false in some resume paths. If any prior-turn messages get filtered out (or the triggering user message gets excluded), the fingerprint won't match what the runner stored.

Since the fingerprint includes tool-call IDs from all prior turns, a first-turn session has none to mismatch on, while every subsequent turn accumulates more surface area for divergence between the playground's reconstructed history and the runner's stored version.

The eviction-on-mismatch behavior itself is a separate concern tracked in #5596 — the runner should refuse a bad match gracefully instead of destroying the parked session [2].

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[mmabrouk]

Fix implemented on the multi-modality train (branch wp2-runner-delivery, PR #5615): the park now records whether its request asserted full history, and a minimal park's resume compares the history tail from the last user turn instead of the whole transcript. The edited-transcript eviction guarantee is preserved and pinned by tests (edited tail text, swapped attachment id, and changed tool-call ids all still evict).