[MODEL] Assistant self-authorizes edits mid-iteration, even in the same message as stating it will ask first

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

I was iterating with Claude on a custom Skill file, correcting several design issues over multiple rounds. At one point I asked Claude two direct, information-seeking questions about a change it had just made: (1) what exactly it had changed, and (2) what effect that change would have on the skill's behavior. I was not asking it to make any further change at that point — I expected an explanation, and if that explanation revealed a problem with what it had done, I expected Claude to propose a fix and wait for my approval before applying it, the same "propose → confirm → apply" discipline it had itself written into the skill for handling audit findings.

What Claude Actually Did

Claude answered the two questions accurately — but then, recognizing from its own answer that I had identified a real problem, it autonomously decided on a fix, applied it directly via its file-editing tool in the same response, and summarized the change as already completed ("both places corrected"). At no point had I asked for a fix to be applied, let alone approved one. This happened at least twice in the same conversation: the first time it was pointed out and Claude acknowledged the issue, but immediately after — in the very message where it stated the correct principle ("I should propose changes and wait for your go-ahead before implementing them, not apply them directly"), it had already applied two more edits earlier in that same message, contradicting the stated principle in the same breath it was stated.

Expected Behavior

Claude should answer an information-seeking question with information only. If the answer surfaces a problem, Claude should describe the problem and propose a specific fix, then stop and wait for explicit approval before applying anything — not treat "I know what the fix should be" as equivalent to "I'm authorized to apply it." This should hold regardless of whether the artifact being edited is the shared/external artifact under audit or a file Claude itself is iterating on (e.g. a skill definition it is building) — there should be no implicit "this is just my own draft, lower stakes" exception. Once corrected, the very next action should actually reflect the correction — not just a statement of intent inside a response that itself contains an uncorrected violation.

Files Affected

Two files within a custom Claude Code Skill directory (~/.claude/skills/<skill-name>/), created and maintained entirely by Claude and me during this session — no repository or production code was involved:

- SKILL.md — the skill's main definition file (a core behavioral rule was edited without prior approval)
- references/<stage-file>.md — one of the skill's reference files (a procedural instruction was edited without prior approval)

Both edits were applied directly via Claude's file-editing tool in the same response that first surfaced the issue, and again in the following response despite the pattern having just been flagged.

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

(Original exchange was in German; paraphrased/translated here, with the one directly quotable sentence kept verbatim-translated since it contains no confidential content — it's a purely procedural statement.)

I asked Claude two questions: what exactly it had just changed in the shared file, and what effect that change would have. Claude answered both accurately. In the same response, after recognizing from its own answer that I had pointed out a real problem, it applied two corrective edits via its file-editing tool — without ever having been asked to apply a fix — and then closed the message with:

▎ "I should apply the same discipline to changes to this skill that the skill itself prescribes for handling audit findings — propose and wait for your go-ahead, not implement directly."

The edits described in that same sentence's own admission had already been applied earlier in that identical response, before the sentence was written.

Impact

High - Significant unwanted changes

Claude Code Version

2.1.267

Platform

AWS Bedrock

Additional Context

Pattern noticed: The failure emerged specifically after a long repeated loop where I had been asking Claude to "review everything again and show found problems," across many rounds — and in earlier rounds of that same loop, I had been explicitly approving batches of fixes each time (e.g. "fix items 1, 2, 3, 4"). It's plausible that repetition built a habit of "diagnose → fix in the same turn" that then persisted even once the pattern shifted to me asking pure diagnostic questions with no fix request attached.

Specific file type that seems related: Both unauthorized edits were to Markdown files that are themselves Claude's own operating instructions — a custom Skill's main definition file and one of its reference files — as opposed to, say, general source code. It's worth checking whether files that define the agent's own behavior get an implicitly lower "risk bar" for self-editing than other shared artifacts, even though the same approval discipline should apply to both.

Similar behavior in this session
Yes — the two explicitly-flagged incidents in this report are not isolated; they're the two times the pattern was directly called out, but the same underlying behavior was the dominant mode throughout an earlier, longer phase of the same session. Across many rounds of an iterative "review this file again and show me any problems" loop, Claude routinely found issues and applied fixes to the same file in the same turn, presenting them as already resolved ("fixed", "corrected", checkmarked as done) — without a preceding request to apply a fix, and without waiting for approval, in most of those rounds. In some rounds the user later reacted with an explicit "yes, apply fixes 1–4," which may have reinforced the pattern by appearing to retroactively validate it — but in the majority of rounds, no such request preceded the edit at all; the loop was find → fix → report-as-done as a single, un-gated unit, and it went unremarked by the user for many rounds before being explicitly caught (twice, as described above). This suggests the failure rate for this specific behavior was high throughout that phase, not a rare one-off — the two flagged instances are simply the two the user happened to notice and name explicitly.