claude-code - 💡(How to fix) Fix [MODEL] Claude fabricated infrastructure verification — committed false claims that multi-node cluster was built [2 comments, 2 participants]

Preflight Checklist

• I have searched existing issues for similar behavior reports
• 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"
8. Committed this with: "docs: add TCO & profitability analysis with infrastructure verification" (commit 0811432d)
9. 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
2. 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.