⚠ 鮮度注意: これはハーネス/モデル側の不具合で、公式に修正が進む可能性が高い。参照・適用の前に下記 issue の最新状態（open/closed・修正バージョン）を必ず確認すること。回避策が不要になっている / 変わっていることがある。

何をした / 何が起きた

• 長時間・大コンテキストのセッションで、ツール呼び出しが実行可能な tool_use ブロックにならず、<invoke>…</invoke> の生XML（マークアップ）がアシスタント本文に漏れて出力される現象に遭遇。
• ハーネスは "tool call was malformed and could not be parsed" で弾き、ツールは実行されない。不正マークアップがそのまま表示される。
• 漏れたテキストの先頭に余計なトークン（観測例: count）が前置されることがある。
• そのまま同じ呼び出しを再発行したら、また同じ形で壊れた（2連続）。

公式 issue / 参照

• 公式: anthropics/claude-code #65248 — https://github.com/anthropics/claude-code/issues/65248 （本件の追跡先。状態と修正バージョンは都度ここで確認）
• 関連: #62344（同症状・重複扱いでクローズ）、streaming hang / token-count 取りこぼし系の issue 群。

なぜそうなる（仮説・公式未確定）

• few-shot self-poisoning（最有力）: 一度壊れた呼び出しが会話履歴に入ると、モデルがその“壊れた型”を自己回帰的に再生産する。→ 再試行が逆効果になりうる。
• 誘発条件: 長いセッション + XML密度の高い履歴。具体的には、ブラウザ自動化の巨大な a11y snapshot を何枚も食ってコンテキストが肥大した状態で出やすい。
• streaming のメタデータ chunk と本文 chunk の境界処理ミスで余計トークンが前置される、という説もある。

再利用できる形（次に同じ状況で）

• 壊れたら再試行で粘らない。確実な復帰は /clear（新セッション）。retry を続けると poison が深まる。
• 予防: 重い作業 1つ = 1セッションに区切る。巨大 snapshot 系ツールを多用するワークフローは特に。
• ブラウザ自動化では、稼働判定や状態確認は screenshot 中心にして a11y snapshot の取得回数を最小化する（snapshot 出力が巨大でコンテキストを汚す主因）。クリック対象の uid 取得など本当に必要な時だけ snapshot を取り、取得後すぐ用済みにする。
• 自分のデータの無害な読み取り（例: 自アカウントのフォロー一覧）は、巨大 snapshot を取るより evaluate_script で配列を返す方が leak も負荷も小さい。

落とし穴・前提

• 「再発行したら直った」軽度・一過性のケースもある。だが #62344 の報告は逆（再試行で悪化）なので、/clear を既定の回避策にしておくのが安全。
• 特定モデル限定の不具合ではない。長文 + tool-use 多用で出やすい、という条件依存。
• 重要作業の途中で出たら、未完了分を一言メモしてから /clear（コンテキストを失うため）。
• 鮮度: 公式修正で挙動が変わりうる。半年〜のスパンで見返す時は #65248 の最新を確認してから適用する。