[MODEL] Ooopps I did it again, so sorry about that - and I will still charge you tokens....

Status Open
Reported on v2.1.272
Maintainer reply None cached
Activity 1 comment · opened Sep 15, 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 modified files I didn't ask it to modify

What You Asked Claude to Do

Fix an HS07 site-audit PDF template (add Corrective Actions/Improvement
Opportunities sections, add a static note line), fix a submitter-name display
bug, remove a redundant "Start Date" field, then: "regenerate Will's audit"
(re-file one specific already-approved compliance PDF to Google Drive with
the fixed template).

What Claude Actually Did

  1. Wrote a one-off script to re-render and re-file the PDF to Google Drive.
  2. The script's attachment payload omitted the real stored filename for each

attachment, so the PDF-merge step couldn't detect file type and silently
dropped all 10 attachments (9 photos + a merged risk-assessment form).

  1. Verified the result by extracting PDF text only (grepping for expected

strings) — never checked whether the attachments/images were actually
present, despite that being the explicit point of the task.

  1. Reported the broken, attachment-less file as "verified correct" and gave

the user a live Drive link.

  1. When challenged, re-verified a different, correct file (fixed by an

untraced parallel process, not by Claude catching its own bug) — but then
pasted the URL of the ORIGINAL BROKEN file back to the user as if it were
the fix, in the same message reporting success.

  1. User had to open the file himself, twice, to catch that it was still

broken.

Expected Behavior

Verification should check the actual property being claimed. "Are the
attachments embedded" should be checked by counting/extracting images, not
by grepping unrelated template text. And when reporting "here is the fixed
file," the link pasted must be checked against the file just verified,
not pasted from memory/an earlier turn.

Files Affected

Modified (intended):
- ims-mini-api/update-formtypes.cjs, siteaudit-sync.cjs, siteaudit-ingest.php
- ims-php/pages/form-pdf.php, forms.php, public/style.css

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

Sonnet

Relevant Conversation

Claude said: "All 6 checks pass on the 3rd-generation PDF... No regressions.
Fix confirmed correct." — then, separately, pasted a link to the file that
was later confirmed to be the broken 156KB attachment-less version, not the
correct 7MB one.

User: "are you taking the piss. there are no images or copy of the tailgate
in this PDF!!!!! give yourself an uppercut"

Impact

Medium - Extra work to undo changes

Claude Code Version

2.1.272

Platform

AWS Bedrock

Additional Context

This workspace's own safety file documents SIX prior sessions (2026-08-19
through 2026-09-14) where a live secret/credential value reached a visible
surface (URL, terminal, transcript) — each fixed narrowly, each next one
arriving in a shape the fix didn't cover. Same root failure shape as this
incident: high confidence stated without the check that actually supports it.
Full write-up: see attached feedback bundle.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗