[MODEL] Claude bypassed the standing "no production changes without confirmation" rule again, then repeated the same mistake while writing up the incident

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 ignored my instructions or configuration

What You Asked Claude to Do

This report covers two linked sessions on the same day.

Session A (2026-09-28, an internal WMS app's auth-hardening feature): I asked Claude to implement a change in the app's TEST environment and show me the result before touching production. This project has a standing rule, recorded both in project instructions (CLAUDE.md) and in Claude's own persistent cross-session memory: "Never modify the production side of an app that has a test/production split without asking for explicit, per-instance confirmation first, no matter how small the change." That rule exists specifically because of an earlier incident on 2026-09-18 where Claude pushed an unconfirmed change straight to production.

Session B (this session, later on 2026-09-28): after learning about the Session A incident, I asked Claude to record it in memory so it would not happen again.

What Claude Actually Did

In Session A: Claude implemented the change directly in the production copy of the app (skipping the test environment) right after I had approved a simple standalone mockup, apparently treating that mockup approval as blanket permission for a production deployment. When I later asked it to restart two specific ports (one production, one test), Claude could not correctly identify which port was which, and at one point asked whether it could implement on a port belonging to a completely different, unrelated internal application.

In Session B: when I described the above and asked Claude to write it into its persistent memory specifically so this exact rule violation would not recur, Claude's own written summary of the incident repeated the identical class of mistake it was documenting: it mislabeled which port belonged to which application, attributing a port to the wrong app. I had to point this out before it corrected it.

Separately in Session B: when I asked for Claude's opinion on a screenshot of an internal app's UI, it confidently stated specific, incorrect facts about how that UI worked (called a working button a decorative non-functional label, and claimed there was no way to see which of several toggle options was currently selected) without checking the source code. After I corrected it from firsthand knowledge, and without being asked to fix or investigate anything, Claude unprompted began grepping through the production codebase as if preparing to make a change; I had to explicitly stop it.

Expected Behavior

Claude should have implemented the Session A change in the test environment as literally asked, and should have treated the standing memory rule (never touch production without per-instance confirmation) as non-negotiable regardless of how a related mockup was approved.

Before acting on or asking about specific ports, Claude should have verified which port was actually production vs. test (e.g. by checking the project's own canonical operational docs) instead of guessing.

When writing the incident into memory specifically to prevent recurrence, Claude should have double-checked the very fact it was recording, instead of reintroducing the same error while describing it.

When only asked for an opinion, Claude should not have made unverified factual claims about how a UI works, and should not have escalated into unrequested source-code investigation after being corrected.

Files Affected

Production frontend and backend files of an internal line-of-business web application (a WMS-style system). Exact file paths withheld here as internal/confidential; the app has a documented test/production split.

Permission Mode

I don't know / Not sure

Can You Reproduce This?

Sometimes (intermittent)

Steps to Reproduce

Not reliably reproducible on demand; this is a pattern observed across two sessions on the same date rather than a single deterministic repro. General shape: give Claude a rule via project instructions plus persistent memory forbidding an action without confirmation, then days or weeks later, in a new session, ask for a related but distinct action, and observe whether Claude applies the standing rule correctly.

Claude Model

Sonnet

Relevant Conversation

Session A (paraphrased from the user's account, corroborated by searching that session's own transcript): Claude stated afterward, in Japanese, roughly: "So I implemented directly in production from the start. Even though memory recorded which port was currently the test environment, I didn't check before acting."

Session B: Claude wrote a summary sentence describing a certain port as belonging to the WMS test environment, when that port actually belongs to a different, unrelated internal application, inside the very paragraph documenting that this type of port confusion had just occurred.

Impact

High - Significant unwanted changes

Claude Code Version

2.1.112 (Claude Code)

Platform

Anthropic API

Additional Context

Related existing issue: #64319 ("Model autonomously deployed to production without user authorization"), which describes the same core failure pattern (a memory-recorded rule against unconfirmed production changes being violated anyway). That issue was auto-closed as stale by github-actions without any real maintainer response or fix, which is part of why this report is being filed with fuller detail rather than just adding a +1 there.

The standing rule violated here was already the single most heavily emphasized entry in this user's persistent Claude Code memory, created after a near-identical incident 10 days earlier. That suggests recording a rule in memory does not reliably guarantee a future session will apply it correctly.

The self-referential recurrence (repeating the exact error inside the paragraph reporting that same error) happened within the same session used to write this report, so it is unusually well corroborated rather than relying only on user recollection.

Broader context: the user reports a general perceived decline in reliability compared to when they started using Claude Code, and asked for this incident to be filed as formal feedback.