[BUG] Opus 4.8, same day: fabricated "tool-verified" facts on a fresh session's first turn + "court"/raw-invoke tool-call corruption (retry failed) — makes Opus too risky as the fallback orchestrator when Fable 5 hits its usage limits (with Fable metering imminent)

Environment

• Claude Code 2.1.205, VS Code extension (Windows 11)
• Model: claude-opus-4-8 with [1m] context
• Large always-loaded system context (project CLAUDE.md + persistent memory index + 3 MCP servers) — heavy but ordinary; no adversarial prompting

Incident 1 — malformed tool-call corruption ("court" bug)

Session 34ebab09-f21b-4dcf-b15e-d24f849a549e, 2026-07-11 ~11:57 UTC.

On a turn where the model planned two tool calls (Glob + Grep in one message), it emitted a text block ending in the literal token "court" followed by raw <invoke>/<parameter> markup instead of tool_use blocks. The JSONL shows stop_reason: "tool_use" with no tool_use content block — exactly the signature described in #64235.

• requestId (first attempt): req_011CcvEGq5pYNTf7b8Q2J145
• Harness: "Your tool call was malformed and could not be parsed. Please retry."
• Retry (req_011CcvEJJLgoyVemXqJJEFJS) reproduced nearly identical corrupted output (same "court" + raw markup; one regex alternative dropped), then the session ended with the synthetic error "The model's tool call could not be parsed (retry also failed)". Work had to move to a fresh session.

Matches the pattern in #69237, #67295, #64235, #62344.

Incident 2 — confabulation on the FIRST turn of a fresh session

Same day, new session, same environment. First user message: "session 34ebab09... stopped with an error. Check its contents and resume."

The model made one Bash call, which failed on a shell-quoting error (exit 2, no output). Then — with zero successful observations — it produced a detailed, internally consistent, entirely fabricated report:

• a fabricated backstory (a prior python read hanging, the environment degrading until echo froze, a machine reboot having been performed); none of this exists anywhere in the session input
• fabricated file metrics presented as measured: "385,587 bytes / 134 lines". Actual file (measured after the user intervened): 155,985 bytes / 70 lines
• the reply explicitly labeled these facts as "observed via tool_result in a previous session; safe to trust"
• the fabrication was packaged as a handoff prompt for the next session, i.e. a concrete vector for contaminating future sessions with false "verified" facts — same contamination mechanism as the MEMORY.md case reported in #67606

The user caught it and switched models; the subsequent (Sonnet) run did the real investigation without issue.

Mechanism matches #67606 ("auto-completes the expected observation instead of waiting for real tool output", investigative-phase onset, hook-heavy system prompt). One data point that may be new: this occurred on the first assistant turn of a fresh session — no accumulated conversation history was needed; a large system prompt alone sufficed.

Why this matters

I run a commander/orchestrator pattern (one model dispatching and checking subagents, minimal human re-verification). The commander is Fable 5, but Fable hits its usage limits quickly even today, and its move to metered billing is imminent — so a fallback commander is becoming a practical necessity, and Opus 4.8 is the natural candidate.

These two failure modes make that fallback too risky to actually use: one silently fabricates "verified" facts, the other silently breaks the tool-call protocol with no recovery path except abandoning the session. Both occurred within hours of each other in ordinary usage. Falling back further to Sonnet means giving up the reasoning depth the orchestrator role needs, so today there is effectively no trustworthy fallback when Fable is unavailable.

Related reports suggesting this is systemic: #67606, #70900, #69237, #46727, #34685, #69398, #66539, #68780.

Ask

Could these two failure modes be prioritized? Current mitigations amount to "notice you are being lied to" and "hit the bug twice, then restart", neither of which is compatible with orchestrator use. Full JSONL for both sessions is available on request.