Sessions that ran google-antigravity models become permanently unusable after switching to Claude: empty text blocks persisted in history, rejected on replay

[X1Z2-sys]

Environment: DeepSeek Harness 0.1.1-rc.2, Windows 11, session store session.jsonl.zstd

Summary

Sessions that ran on google-antigravity/antigravity-gemini-3.1-pro accumulate
empty text blocks ({"type":"text","text":""}) in persisted assistant messages

• that provider's output shape is reasoning + tool-call + text(""). These
  blocks are harmless under lenient models (GLM / Gemini accept them), but the
  moment the session's model is switched to a Claude model, every subsequent
  request fails with HTTP 400 and the session is permanently unusable - Claude's
  API rejects empty text content blocks, and DSH additionally stamps
  cache_control on the trailing text block, which Anthropic also rejects.

Re-login / re-auth cannot help: the poison is the stored history, not auth.
The session file also stops growing (each turn fails before anything new is
persisted), so DSH's own compaction can't recover it either - the compaction
request itself fails with the same 400.

Steps to reproduce

1. Start a session with model google-antigravity/antigravity-gemini-3.1-pro
   and do agentic work that triggers tool calls (each tool-call turn persists
   one empty text block).
2. Switch the session's model to a Claude model (claude-opus-5 in our case).
3. Send any prompt.

Observed errors (both variants seen)

claude API error (HTTP 400): {"type":"error","error":{"type":"invalid_request_error","message":"messages: text content blocks must be non-empty"},"request_id":"req_011CemVbWJeZmqgZJkKzzaCM"}

claude API error (HTTP 400): {"type":"error","error":{"type":"invalid_request_error","message":"messages.109.content.1.text: cache_control cannot be set for empty text blocks"},"request_id":"req_011CemVe1HyNr3j6x4LYSix8"}

Evidence (from decoding our session store)

Session with 65 persisted assistant messages produced by antigravity:

• 26x content shape reasoning + tool-call + text(EMPTY)
• 34x content shape tool-call + text(EMPTY)
• 60 empty text blocks total across assistant message records

Zero cache_control is persisted in the store - it is stamped at request
build time onto the trailing text block, which is how the empty block also
trips Anthropic's cache_control cannot be set for empty text blocks rule.

Root cause (three stacked issues)

1. Request builder forwards stored empty text blocks. Empty/whitespace-only
   text blocks are never valid for Anthropic (and questionable for any
   provider); the builder should filter them out of the outgoing messages
   array regardless of what the provider adapter persisted.
2. cache_control stamping doesn't check the target block. The prompt-cache
   marker is attached to the trailing text block without verifying it is
   non-empty, producing the second (double) failure mode.
3. Model/provider switch does not validate stored history. Switching a
   session to a new provider sends the old provider's raw block shapes to a
   new API with different invariants. There is no normalization step between
   "user picked a new model" and "replay the entire history at it".

Suggested fixes

• Filter empty/whitespace-only text blocks out of outgoing messages in the
  request builder (cheapest fix, solves both error variants at once).
• Guard the cache_control stamp: skip blocks with empty text.
• On model switch, validate (or minimally normalize) the stored history for
  the target provider before replaying - at minimum, the empty-text-block
  filter above.
• Optionally at ingest: the antigravity adapter shouldn't persist empty text
  blocks in the first place.

Workaround that unblocked us (for anyone else hitting this)

Decode session.jsonl.zstd (multi-frame zstd, frame-split on the
28 b5 2f fd magic), remove content blocks where
type === "text" && text.trim() === "" from assistant/message events
(leave assistant/chunk stream telemetry alone), re-encode, verify roundtrip,
swap back in with a backup. Our repair: 60 blocks removed from 60 messages,
922/982 events byte-identical, session worked again after reopening.

Huge thanks for a great tool - happy to provide the repaired-vs-original
session file pair (redacted) or the exact repair script if useful.

[argszero]

Really well-documented report — thank you for the decoded evidence and the exact repair procedure. I verified the three stacked root causes against the current source (dsh v0.1.3-alpha.1 / master d347e70390), and I think your analysis is on the money. A few source-level confirmations:

1. The harness's own pi-ai adapter does no empty-text-block filtering.
packages/llm/llm-pi-ai/src/adapter.ts normalizes headers and checks contentHasImage, but the outgoing messages content is passed through as-is — there is no "drop empty/whitespace-only {type:'text', text:''} blocks" step. So a stored empty block is forwarded to whatever provider the session is now on. Confirmed: root cause #1 is in-tree and real.

2. cache_control stamping is in pi-ai, not the harness.
The only cache_control references in-tree are a capability flag (packages/llm/llm-pi-ai/src/catalog.ts:396 — "whether the endpoint accepts cache_control on tool definitions"), plus transport/auth noise. The stamping that trips Anthropic's "cache_control cannot be set for empty text blocks" is done inside pi-ai at request-build time, undoing the harness's per-message control. So root cause #2 is upstream (pi-ai), not directly patchable in-tree — which makes the request-builder filter (your fix #1) the only harness-side lever, and it's exactly the right, cheapest surface.

3. The empty block's origin is the provider chunk stream.
packages/core/agent-loop/src/agent.ts:389 persists assistant/message via createAssistantMessage(content) where content comes from the live stream blocks. When antigravity emits text("") as its trailing chunk, that empty block is stored verbatim — no normalization at ingest either (your optional fix #4).

A community-side safety net: I shipped a plugin that audits stored session logs for exactly this class of hard-fail-before-replay — @argszero/cordis-plugin-session-audit (v0.1.2). It already detects unknown-required event types that make reload hard-fail, and the same engine's assistant/message scan is where an empty-text-block detector naturally fits: flag any assistant/message whose content contains {type:'text', text:''} (or whitespace-only), since those will 400 a Claude re-replay. Your trimmed-prod-session repair (60 blocks) is the exact manual remediation this kind of pre-flight check would have pointed at before the switch. I'm going to add that detection surface as the next increment.

One note for your report: the empty-block filter (fix #1) is by far the highest-value change because it solves both error variants at once AND is provider-neutral, so it'd help beyond just Claude. If you have the redacted repaired-vs-original pair handy, that's a solid regression fixture once the in-tree filter lands.

[argszero]

Increment shipped: @argszero/cordis-plugin-session-audit@0.1.3 now has an EMPTY_TEXT_BLOCK finding. It scans each persisted assistant/message for a {type:"text", text:""} (or whitespace-only) content block and reports the offending seqs as a warn — the exact pre-flight check to run on a session before switching it to a strict provider. Combined with the existing UNKNOWN_REQUIRED_TYPE hard-fail detector and the session-audit CLI (npx @argszero/cordis-plugin-session-audit <root> --id <substring>), you can confirm whether a session is already poisoned before replay crashes. Thanks again for the detailed evidence — it made this a straightforward, verifiable detection surface.

[X1Z2-sys]

Confirmed working end-to-end — thanks for shipping session-audit so fast.

Ran v0.1.3 (the EMPTY_TEXT_BLOCK release) against the full local session store:

• 20 sessions scanned (plaintext .jsonl decompressed from .jsonl.zstd via zstandard).
• 2 sessions carried the poison:
  • session-92952fe5 (the previously repaired session) — 151 assistant/message events with {type:"text", text:""} blocks.
  • session-6f5fab4e — 44 events with the same.
• Applied the fix your report suggested — stripped the empty text blocks from data.message.content on both, re-compressed, swapped into the live store (originals backed up as .bak-emptystrip-*).
• Re-ran the audit on the repaired pair: warn findings: 0, no corruption findings.

Also gives a useful regression datapoint: your EMPTY_TEXT_BLOCK finder matched 151/151 and 44/44 events exactly (one empty block per affected event), so the detector counts are precise.

Both sessions are now replay-safe for strict providers (Claude). Thanks again for the tooling — the pre-flight check is exactly what would have caught this before the model switch.