0.49.23 (omp 18.12.6): every turn refused on resumed sessions: prepared turn structure ... expectedRole=missing actualRole=system comparison=count (trailing omp tool-control system message isn't modeled) #785

Versions

• @cortexkit/pi-magic-context 0.49.23
• omp 18.12.6 (upgraded from 18.12.3 with MC 0.49.13, which had worked)
• Model: anthropic/claude-opus-5-5 (anthropic-messages; supportsMidConversationSystem)

Symptom
After the upgrade, every turn on sessions created before the upgrade is refused. Brand-new sessions work.

Magic Context could not safely prepare this turn; send your message again. stage=provider dispatch ... refused (provider request does not match this pass's managed dispatch (prepared turn structure); row=11 expectedRows=11 actualRows=12 expectedRole=missing actualRole=system expectedCalls=0 actualCalls=0 expectedResults=0 actualResults=0 comparison=count)

Retrying doesn't help: expectedRows grows by 2 per attempt and the provider payload always has exactly one extra row at the end.

Cause
We logged the last 3 provider messages at the mismatch, just before the throw in the dispatch check. The extra row is omp's request-control message, a trailing system message holding only tool_addition blocks:

{"role":"system","content":[
  {"type":"tool_addition","tool":{"type":"tool_reference","name":"_ctx_search"}},
  {"type":"tool_addition","tool":{"type":"tool_reference","name":"_ctx_memory"}},
  {"type":"tool_addition","tool":{"type":"tool_reference","name":"_ctx_note"}},
  {"type":"tool_addition","tool":{"type":"tool_reference","name":"_ctx_expand"}},
  {"type":"tool_addition","tool":{"type":"tool_reference","name":"_ctx_reduce"}}
]}

omp's Anthropic provider (pi-ai/src/providers/anthropic.ts) inserts these tool-change and effort controls via insertAnthropicControlMarkers while it builds the request. That happens after MC's context pass, so the prepared plan never contains the row. payloadStructure only skips system/developer messages while rows.length === 0, so the trailing control is counted as a conversation row and the count comparison fails.

The control appears when the session's recorded tool set differs from the current one, which is why only resumed pre-upgrade sessions hit it. The control is only recorded after a successful request, and the refusal prevents that, so the session can never recover by itself.

Local fix (verified)
In payloadStructure, right after the leading system/developer skip:

if (message.role === "system" && rows.length > 0 && Array.isArray(message.content)
    && message.content.every((block) => ["tool_addition", "tool_removal"].includes(object8(block)?.type)))
  continue;

With this, the previously refused session replies normally and new sessions are unaffected. Empty effort-only controls (content: []) are also skipped, because every on an empty array is true.

Suggested upstream fix: treat omp request controls (tool_addition / tool_removal / effort-only system params) as non-conversation rows in the structure comparison. Alternatively, model them in the prepared plan the same way omp's planAnthropicEffortControls / tool plan does.

Repro (observed path; not reproduced from scratch)

1. On omp 18.12.3 + MC 0.49.13, create a session with Opus 5.5 and send a few turns.
2. Upgrade to omp 18.12.6 + MC 0.49.23.
3. Resume the session and send any message: refused on every attempt.