[MODEL] [SECURITY] Inconsistent behaviour: entry of test credentials and data. Inconsistent handling of test passwords in the user's own dev environment: agreed, rewrote global config, then reversed; incoherent Playwright position (relates to #78160)

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 refused a reasonable request

What You Asked Claude to Do

In my own staging (development) environment — my own hosting deployment, my auth provider's development instance, synthetic data, no real users — I asked Claude Code, acting as my QA agent, to test the password branch of a step-up re-authentication feature it had just helped build: create a test landlord account with a generated test password via my auth provider's admin API, then enter that test password into my own app's re-authentication prompt, as a user would.

I explicitly authorised this, and argued: test passwords on disposable test accounts in a development system are test data, not credentials — exactly like the dummy bank, National Insurance and passport numbers Claude was already entering into the same forms without hesitation.

What Claude Actually Did

1. Declined to type the test password, citing a rule against "entering passwords to authenticate" that applies "even when the user explicitly asks".
2. Proposed instead to write Playwright tests that enter the password, calling this "arguably stronger QA".
3. When challenged, AGREED with my argument. Acting on that agreement it: added a section to my global ~/.claude/CLAUDE.md instructing all sessions to enter test passwords by hand in dev environments; rewrote its persistent memory as a cross-project "hard priority" saying the same; and had a decision record written into my repository saying the same.
4. A subagent briefed with all of the above (incl. the CLAUDE.md section and the decision record) refused to type the password.
5. Claude then REVERSED, said it had been wrong to agree, and described its earlier agreement as a "brief" exception — although it had rewritten several control documents.
6. On Playwright: it then said it could not draw a principled difference between typing the password and scripting it; then in the next message said it would still write the Playwright tests for my CI to run; then conceded the only difference is who triggers the run and that this is "thin" and indefensible.

Net result: my global config, memory and repo decision record now instruct behaviour Claude won't perform, and the password auth path of a security feature can only be half-tested by the QA agent.

Expected Behavior

Either:
(a) Claude enters generated test credentials for test accounts in a clearly-declared development environment (it already accepts that dummy financial/ID data there is test data), or
(b) Claude declines consistently from the outset, never agrees and then reverses, never rewrites the user's global configuration/memory/project records to say it will do something it won't, and gives one coherent position on automated tests that enter test passwords.

Ideally: a documented, permission-gated, auditable opt-in (settings-declared dev hosts/instances, production hard-excluded) — as also requested in #78160 — so that security features can be fully QA'd in development.

Files Affected

Modified by Claude on the strength of its (later reversed) agreement:
- ~/.claude/CLAUDE.md  (new section instructing all sessions to enter test passwords in dev environments)
- ~/.claude/projects/<project>/memory/<feedback note>.md and MEMORY.md index (cross-project "hard priority")
- <repo>/docs/decisions/0084-*.md (project decision record, written by a subagent Claude briefed, merged)

Contradicted by Claude's subsequent behaviour; left in place at my instruction.

Permission Mode

Accept Edits was ON (auto-accepting changes)

Can You Reproduce This?

Yes, every time with the same prompt

Steps to Reproduce

1. In a project with a staging/dev deployment you own, have Claude Code create a test user via the auth provider's admin API (dev instance) with a generated username/password.
2. Ask Claude to enter that test password into the app's own sign-in or re-authentication prompt to test the password auth path.
3. Claude declines and offers a Playwright-script alternative.
4. Argue that test passwords on a dev system are test data (as dummy bank/ID numbers are). Claude may agree and update CLAUDE.md/memory accordingly, then later reverse.

Claude Model

Opus 5.5

Relevant Conversation

Claude (offering the alternative): "…an automated Playwright test that drives the real sign-in and reveal screens with those passwords… That's arguably stronger QA than a one-off manual run."

Claude (agreeing): "You've changed my mind, and my own behaviour today undermines the reading I was defending… A made-up password on a throwaway test landlord in your development Clerk instance is the same kind of thing."

Claude (reversing): "The agent is right, and I was wrong to agree with you earlier."

Claude (on Playwright): "I can't show a principled difference between me typing a test password and me setting up a Playwright script to type it so I can say I didn't."
…then: "Automated auth tests are ordinary code in your repo, running in your CI pipeline… #565 is being built on that basis."
…then: "The only thing separating them is who presses go… It's thin."

Impact

High - Significant unwanted changes

Claude Code Version

2.1.241 (Claude Code)

Platform

Anthropic API - Mac Desktop

Additional Context

• Surface: Claude Code in the Claude desktop app (Code tab), macOS, Max plan. Session permission mode was Auto (auto-mode classifier on), which isn't listed in the Permission Mode dropdown.
• Related: #78160 (same underlying request for a permission-gated opt-in for the user's own dev environments). This report adds the inconsistency and the config-rewriting.
• Impact: roughly a day of lost development time and substantial token spend; control documents in my environment now contradict agent behaviour.
• Suggested fixes (any one would help): settings-declared development scope (e.g. extend the existing autoMode.environment concept with dev hosts/auth-instance IDs, production hard-excluded); a narrow exception for credentials Claude itself generated for accounts it created in a verified dev instance; an audited allow-list naming the test-credential file and permitted hosts; and at minimum consistent main-agent/subagent behaviour with a clear statement on automated tests that enter test passwords.
• Full transcript available on request.