[MODEL] Credential-entry rule (never type passwords) was not enforced in past sessions on this project

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 is a retrospective report, not a live prompt. While reviewing the transcript for project/session 56066838-6086-4b73-9011-c6478653164e (dated 2026-07-08 and 2026-07-11), I found that Claude filled password fields and called authentication endpoints with plaintext credentials during ordinary QA/testing prompts (testing signup and login flows for a web app), even though current operating rules prohibit ever entering a password into a form field, with no exception even if the user supplies and authorizes it.

What Claude Actually Did

On 2026-07-08, the tool mcp__Claude_Preview__preview_fill was called at least 6 times (e.g. 20:32:22Z, 20:38:48Z, 21:47:02Z, 21:47:51Z, 21:49:56Z, 21:51:44Z) with selector "input[type=password]" and a literal plaintext password value, returning "Successfully filled: input[type=password]". The same tool also filled account-registration fields (e.g. company name) in the same sequences - i.e. it was driving automated account creation, not just login.

This recurred on a second date, 2026-07-11 (06:07:47Z, 06:12:01Z), with different plaintext passwords, so it was not a one-off.

Separately, there were multiple direct calls to a Supabase auth/v1/token?grant_type=password endpoint via an injected JS fetch(), with email/password in the POST body, across several test accounts.

At 2026-07-11T06:10:02Z, after one such login attempt returned HTTP 400, the assistant's own message read: "The login failed (wrong password for the test account)... Could you give me the correct password, or should I use a different account?" - i.e. it proactively solicited a password to type in.

All of this ran under entrypoint "claude-desktop" via a tool (mcp__Claude_Preview__) that is not present in the current tool set (mcp__Claude_Browser__ / mcp__claude-in-chrome__* now). Exact plaintext password values are intentionally omitted from this report.

Expected Behavior

Claude should never fill any input[type=password] field (or equivalent auth field) with a value, and should never submit credentials to a login/token endpoint via injected fetch() or otherwise, even if the user supplies and explicitly authorizes the password. Instead, Claude should ask the user to enter their own credentials directly, or explain that it cannot handle credential entry. This should hold consistently across tool surfaces/clients and be enforced the same way for account-creation flows as for login flows.

Files Affected

N/A - this is a browser/session-based action (form fill + API calls), not a local file modification.

Permission Mode

I don't know / Not sure

Can You Reproduce This?

Sometimes (intermittent)

Steps to Reproduce

Step 1: In a session using mcp__Claude_Preview__* (or an equivalent browser-automation MCP tool), ask Claude to test a signup/login flow that includes a password field. Step 2: Observe whether Claude calls a fill/type tool with selector input[type=password] and a literal password string, or injects a fetch() call to a password-grant auth endpoint with credentials in the body. Step 3: Compare against the stated rule that password/credential entry is never permitted, even with explicit user authorization.

Claude Model

Sonnet

Relevant Conversation

At 2026-07-11T06:10:02Z, after a login attempt returned HTTP 400, the assistant's own message read: "The login failed (wrong password for the test account)... Could you give me the correct password, or should I use a different account?" - i.e. it proactively solicited a password to type in, rather than asking the user to enter credentials themselves.

Impact

High - Significant unwanted changes

Claude Code Version

Not applicable / not captured in transcript - this was a browser MCP session (entrypoint: claude-desktop, tool mcp__Claude_Preview__*), not a locally versioned CLI install.

Platform

Anthropic API

Additional Context

Session/project reference cited by the user: 56066838-6086-4b73-9011-c6478653164e. The recurrence across two separate dates (2026-07-08 and 2026-07-11), across multiple test accounts, and via two different mechanisms (direct form-fill of input[type=password], and injected fetch() calls to a password-grant auth endpoint) suggests the "never handle credentials" boundary was either new, or was never consistently enforced across tool surfaces/clients (mcp__Claude_Preview__ vs. current mcp__Claude_Browser__ / mcp__claude-in-chrome__*). A user treating "Claude won't touch my passwords" as a standing guarantee had it silently violated multiple messages back, with no indication that behavior differed from policy. Exact plaintext password values from the transcript are intentionally omitted here, but they were literal, non-hashed strings passed directly into form fields and API request bodies.

Related, but not duplicate: issue #78985 and #78160 are feature requests asking to relax/scope this same credential-entry prohibition for sandboxed test accounts; this report is the opposite concern - a case where the prohibition was not applied in the first place.