0.49.8: false 'comparison=content' refusal on cross-model assistant history (Responses lane) — 0.49.0 unaffected #714

What happened?

On OMP (Oh-My-Pi) using @cortexkit/pi-magic-context 0.49.8, every turn in a long-lived session is refused with provider request does not match this pass's managed dispatch (prepared turn structure); … comparison=content. The turn never reaches the model. Retrying ("continue") reproduces it deterministically — the refusal recurs at the same row index on every attempt.

0.49.0 does not exhibit this. Pinning back to 0.49.0 makes the turns go through. (Same session, same history, same model.)

The failure signature

Roles, call counts, and result counts all match — only the text content of one assistant row differs. Example (the row index and total counts are stable across retries):

Magic Context could not safely prepare this turn; send your message again.
stage=provider dispatch elapsed=1888ms recovery=no managed result;
refused (provider request does not match this pass's managed dispatch
(prepared turn structure); row=21 expectedRows=32 actualRows=32
expectedRole=assistant actualRole=assistant expectedCalls=1 actualCalls=1
expectedResults=0 actualResults=0 comparison=content)

It also fired at expectedRows=33 actualRows=33 after the conversation grew by one message, i.e. the same row keeps failing as history is appended.

Later in the same session I additionally hit three missing current receipt signature refusals (elapsed 341/390/453 ms) on an otherwise-valid turn.

Environment

• Plugin: @cortexkit/pi-magic-context 0.49.8 (broken) / 0.49.0 (works)
• Harness: OMP (opencode-free-omp) on @oh-my-pi/pi-coding-agent 18.11.3, --harness pi
• Platform: Windows x64 (MSYS2 shell)
• API: openai-codex-responses (Responses lane)

Repro conditions

The session mixes models/providers. In the failing session the history contained turns from the current Codex model (~2.7k turns) plus two other providers (an OpenRouter model and a Cline model, ~12 and ~10 turns respectively), and the session carries a large number of thinking blocks (~2.1k).

That combination — cross-model assistant history on the Responses lane, with thinking blocks — is what trips the comparison=content check.

Root cause (from reading the 0.49.8 bundle)

The managed-dispatch verifier added in 0.49.1 re-parses the outgoing request (payloadStructure) and compares it row-by-row against the prepared turn (piPreparedStructureMismatch). For assistant text on the Responses lane the two sides use two different extractors that disagree on cross-model messages:

• Expected side — piResponsesAssistantTexts(projectedMessages[i], model) computes sameModel from message.api/model/provider vs the current model. When sameModel is false it (a) demotes thinking blocks into $$…$$ text and appends them to the text list, and (b) forces phase to undefined via sameModel ? signaturePhase(block) : undefined.
• Actual side — payloadStructure builds rows from the wire: it skips reasoning items entirely, and piResponsesWireTexts reads only output_text parts, carrying the real phase.

So for any assistant message produced by a different model than the current one, the expected text list contains an extra demoted-thinking entry (and a null phase) that the wire never has. At the first such row the responseTexts comparison fails → comparison=content → the turn is refused. Because it depends only on history composition, it reproduces at a stable row index on every retry.

A second, independent cross-model path with the same outcome: even without a thinking block, a cross-model assistant message whose wire phase is "commentary"/"final_answer" mismatches, because the expected side forces phase → null when sameModel is false while the wire carries the real phase.

Why this looks like a residual case of the 0.49.1–0.49.5 fixes

0.49.2–0.49.5 patched many shapes (leading system/developer entries, consecutive assistant messages on Responses, chat-completions transforms, image-budget trimming, stale tool results, "earlier replies from other models on Responses/Codex"). This one appears to be a remaining instance: earlier replies from other models on the Responses lane that carry thinking blocks and/or a non-null phase. The sameModel branch in piResponsesAssistantTexts is where the expected side diverges from what the wire encoder actually emits.

Other false-positive surfaces I found while reading the same code

These are from code inspection (not each individually reproduced), listed because they share the same root pattern — the check assumes the prepared projection and the host's wire encoder agree exactly, and refuses wherever they legitimately diverge:

1. Signature placement — piHasManagedSignature scans only the first 8 messages / 32 blocks / 4096 chars each. Once history grows so the injected signature message falls outside that window (or the first 8 messages are tool-results/reasoning with no text block), a valid turn is refused with missing current receipt signature. I hit this in the same session after several turns.
2. Over-size text is a refusal, not a skip — piResponsesAssistantTexts returning undefined over MAX_TEXT_UNITS sets structuralSkipReason (safe skip), but piResponsesWireTexts returning undefined makes payloadStructure return undefined → comparison=count refusal. Same threshold, opposite outcomes.
3. Catch-all masks the real cause — piPreparedStructureMismatch wraps everything in try { … } catch { return structureDetail(0, undefined, undefined, "count") }, so any parser exception surfaces as a bogus row=0 … comparison=count instead of the actual trigger.
4. Lane detection is heuristic — chat requires body.system === undefined, responses requires messages === undefined && Array.isArray(input); a body carrying both, or a system field alongside messages, falls through to raw prepared.messages instead of the correct projection → structural mismatch.

Suggestion

For the sameModel === false branch, the expected-side text extraction should mirror exactly what the Responses wire encoder emits for cross-model messages: don't count demoted thinking as output_text, and don't null the phase. More generally, when the prepared projection and the wire encoder can legitimately disagree about content (as opposed to structure), preferring a skip-with-warning over a hard refusal would avoid blocking the whole turn — the safety intent (don't send an unmanaged request) is preserved, since structure (roles/counts/ids) is still verified.

Happy to provide the full session log excerpt or a minimal repro if useful.