anthropics / anthropics/claude-code

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

Đang mở
#94,444 1 bình luận 0 reaction 0 người được giao Xem trên GitHub
api:bedrock area:model bug model
Ngôn ngữ chính
Python
Star
145k
Fork
23.1k
Chỉ số merge pull request
Chỉ số pull request đang chờ

Mô tả

### Preflight Checklist

- [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Amodel) 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).
3. 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.
4. Reported the broken, attachment-less file as "verified correct" and gave
the user a live Drive link.
5. 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.
6. 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

```shell
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

```markdown
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.

Hướng dẫn đóng góp

Chưa lập chỉ mục được hướng dẫn đóng góp cho kho mã nguồn này

Đánh giá

Issue này chưa được đánh giá.

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.