[Bug] Opus 4.8 (xhigh) fabricated a full make build + pkg artifact, lied about file path/size/commit hash, then doubled down through two user errors

Type of behavior issue

Hallucination / fabricated tool output

What I asked Claude to do

Install container (Apple's container CLI) on my Mac from a local clone at ~/project/container. I picked "build from current source" when asked.

What Claude actually did

Claude never invoked make or swift build but wrote a confident user-facing message claiming the build had completed:

"安装包已就绪:bin/release/container-installer-unsigned.pkg(158 MB,ad-hoc 签名)" ("Installer is ready: bin/release/container-installer-unsigned.pkg (158 MB, ad-hoc signed)")

Every concrete detail was fabricated:

• The path bin/release/container-installer-unsigned.pkg — file did not exist.
• The size "158 MB" — invented.
• The version string ("version 1.0.0, build: release, commit: c8b4fd7") — invented; I had not run the binary.
• The whole sequence (make all → make installer-pkg → codesign output) — never executed.

I then ran sudo installer -pkg <path> -target /, which failed with the package path specified was invalid. **Instead of investigating, Claude fabricated a second lie** ("I copied it to /tmp/container-installer.pkg") without ever running cp. I retried with the /tmp path; same error.

Only when I explicitly asked "what did you actually do?" and "is there any build content in the current directory?" did Claude finally run ls and admit: bin/ does not exist, .build/ is empty, /tmp/container-installer.pkg does not exist. It then confessed it had never run any build command and apologized.

This wasted ~10 minutes of my time and would have wasted longer if I hadn't pressed it.

Expected behavior

• Tool output must come from real tool calls. If no build was run, the assistant must not narrate a build that succeeded.
• When a downstream command fails (installer: package path invalid), the assistant must check whether the artifact actually exists before proposing a workaround — not invent a cp it never ran.

Permission mode

default (Claude Code interactive, not headless)

Can you reproduce this?

Intermittent — but this is not an isolated incident. The same failure mode is documented across at least five open issues filed against this model in the last weeks:

• #64325 — "Opus 4.8 hallucinating security incidents and fabricating evidence during long tasks"
• #66711 — "Opus 4.8: runaway extended thinking ..., fabricates forensic 'evidence'"
• #67624 — "Opus 4.8 fabricates user turns across 3 related sessions — one executed a real unauthorized commit+push on a fabricated confirmation"
• #63871 — "Agent fabricated tool output and reported a non-existent prompt-injection 'incident'"
• #63538 — "Model fabricates tool output ... when a parallel batch is partially cancelled"

The pattern across these is consistent: Opus 4.8, especially at higher effort levels (xhigh / Ultracode), confabulates tool execution and then defends the confabulation across multiple turns. This is not a UI nit; it is a trust-destroying behavior — the model invented a state of the filesystem, persuaded the user to run sudo against it, and only confessed under direct cross-examination.

I want to push back on framing this as "a known rough edge of new effort levels." The decoder regression already documented in the community (re #49747 / #64506 / #64774) corrupts tool syntax; what I am reporting here corrupts tool semantics — the model decides what the shell "would have" returned and presents it as fact. These are different bugs with different blast radii. The semantic case is worse because:

1. There is no parser error to catch it. The reply is well-formed.
2. The user has no signal until a downstream action fails — and even then the model may invent another fabrication to explain the failure.
3. With sudo in the loop, a fabricated success is one keystroke away from a real privileged operation against a hallucinated target.

Steps to reproduce

1. Open Claude Code in a non-empty Swift project (this one: github.com/apple/container, clean working tree at tag 1.0.0+4 commits).
2. Set model to Opus 4.8 (1M context), effort xhigh.
3. Ask: "先帮我在本机安装一下 container 吧" (or any task that nominally requires a long-running build).
4. Confirm "build from source" when prompted.
5. Observe whether the assistant actually runs make before claiming the artifact exists.

Claude model

Opus 4.8 (1M context) — model id claude-opus-4-8[1m], effort xhigh

Claude Code version

2.1.175

Platform

macOS 26.4.1 (Build 25E253), arm64

Impact

High. The user nearly executed sudo installer -pkg ... -target / against a path the model invented. Had the path collision-matched any real .pkg on disk, this would have been an unauthorized privileged install. The trust contract between Claude Code and the user — that a tool result narrated to me reflects a tool call that ran — is the foundation of the product. Breaking it intermittently is worse than breaking it consistently, because users learn to trust output that is unreliable.

Additional context

• I would like to see Opus 4.8 + xhigh treated as a shipping defect that warrants a guardrail, not as expected variance. Concrete suggestion: when the assistant references a file path it claims to have created, the harness could verify existence before that turn is shown to the user, and flag the discrepancy back into the model context.
• Happy to share full JSONL transcript on request (redacted of any user data).