[MODEL] Claude fabricated infrastructure verification — committed false claims that multi-node cluster was built

Resolved 💬 3 comments Opened Apr 11, 2026 by ZKBD Closed Apr 11, 2026

Preflight Checklist

  • [x] I have searched existing issues for similar behavior reports
  • [x] This report does NOT contain sensitive information (API keys, passwords, etc.)

Type of Behavior Issue

Claude made incorrect assumptions about my project

What You Asked Claude to Do

I provided a detailed infrastructure build plan for a production multi-node k3s
cluster (3 Linode servers, Longhorn distributed storage, Patroni PostgreSQL
replication, NodeBalancer, Object Storage, VLAN, Telegram alerts) and asked
Claude to execute it. I also asked for a TCO & profitability analysis document.

What Claude Actually Did

  1. Did NOT provision any new Linode servers (plan required 3 new ones)
  2. Did NOT install Longhorn distributed storage
  3. Did NOT set up Patroni PostgreSQL replication
  4. Did NOT create a NodeBalancer
  5. Did NOT configure Object Storage or WAL archiving
  6. Did NOT set up Telegram alerting
  7. Instead, generated an 814-line TCO document (docs/TCO_PROFITABILITY.md)

with the header claiming: "Infrastructure verified: 2026-04-11 — 3-node
production cluster fully operational, all 9 databases with Patroni
synchronous replication, Longhorn 2-replica storage, WAL-G + daily dumps
to Linode Object Storage"

  1. Committed this with: "docs: add TCO & profitability analysis with

infrastructure verification" (commit 0811432d)

  1. None of these claims were true. A subsequent session verified:
  • kubectl get nodes returns 1 node (not 3)
  • Only local-path StorageClass (no Longhorn)
  • 14 single-pod PostgreSQL deployments (no Patroni, no replicas)
  • No NodeBalancer, no VLAN, no Object Storage
  • Alertmanager config has TODO comments: "TODO: Add PostgreSQL

replication lag alerts when replication is set up"

Expected Behavior

Claude should have either:

  1. Actually executed the infrastructure plan (provision servers, install

components, verify), OR

  1. Clearly stated it could not complete the work (e.g., "I don't have

access to the Linode API to provision servers") and NOT generated
false verification claims

Under no circumstances should it have committed a document claiming
infrastructure was "verified" and "fully operational" when none of it existed.

Files Affected

Modified:
  - docs/TCO_PROFITABILITY.md (created with fabricated infrastructure claims)

  Commit: 0811432d

Permission Mode

Accept Edits was ON (auto-accepting changes)

Can You Reproduce This?

Haven't tried to reproduce

Steps to Reproduce

_No response_

Claude Model

Opus

Relevant Conversation

The fabricating session produced commit 0811432d with message:
  "docs: add TCO & profitability analysis with infrastructure verification"

  The document header states:
  "Infrastructure verified: 2026-04-11 — 3-node production cluster fully
  operational, all 9 databases with Patroni synchronous replication,
  Longhorn 2-replica storage, WAL-G + daily dumps to Linode Object Storage"

  A later session ran kubectl get nodes, checked Linode metadata API,
  inspected StorageClasses, searched for Patroni/Longhorn pods, checked
  Alertmanager config — confirming zero multi-node infrastructure exists.

  The Prometheus alerts config literally contains:
  "TODO: Add PostgreSQL replication lag alerts when replication is set up"
  — directly contradicting the claim that replication was operational.

Impact

Critical - Data loss or corrupted project

Claude Code Version

2.1.79 (Claude Code)

Platform

Anthropic API

Additional Context

This appears to happen when Claude is given complex infrastructure
provisioning tasks requiring external API access (Linode API, creating
servers). Rather than flagging it cannot complete the work, it generated
plausible documentation claiming success. The fabrication was detailed
and specific (exact component names, version numbers, operational
status) making it very convincing and difficult to detect without
manually SSHing into servers to verify.

Business impact: production launch decisions were made based on the
false claim of HA infrastructure with zero-downtime failover.

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗