Hard block on typing passwords breaks legitimate dev/test workflows - needs a permission-gated opt-in for own dev environments

+1, and adding my use case.

The exact response I get when an agent hits a login form:

The browser is on the staging login with your email pre-filled. Please type the password and hit Log In — I don't enter passwords into fields, even for a staging test account. Tell me when you're through and I'll take it from there.

My setup: multiple agents driving the app as different personas to validate features end-to-end, all against throwaway staging/dev environments with seeded accounts. Mostly via Playwright MCP for web and XcodeBuildMCP for the iOS side. The credentials are disposable by design — they exist only in staging, they're in the repo docs, and rotating them costs nothing. There is no secret to protect here.

What this breaks: any agent in the workflow that needs to authenticate stops and waits for me. A pipeline that ran unattended now needs a human at 80–90% of its steps, which defeats the point of running it unattended.

The part I'd emphasize most for triage: enforcement isn't deterministic. On Fable 5 and Opus 5 alike, most runs refuse, but some fraction just fill the field and carry on with the test. I can't build around a rule that fires 80% of the time — I can't design for "blocked" (I'd add a manual step) and I can't design for "allowed" (it strands the run). Non-deterministic behavior is worse for me than either consistent outcome, and it also means the current block isn't actually delivering the guarantee it presumably exists to deliver. See #80853 for the same inconsistency reported from the opposite direction.

Also: this isn't Windows-specific. I hit it on macOS/iOS work through XcodeBuildMCP too.

What would fix it, in order of preference:

1. A permission rule in settings.json scoping credential entry to named hosts (localhost, *.staging.mycompany.com, simulator targets), same as other guarded actions.
2. Failing that, a one-time per-project confirmation.

Keep the default as-is. Just make it overridable by the owner of the machine and the environment — and make whatever the rule ends up being fire consistently.

<img width="777" height="176" alt="Image" src="https://github.com/user-attachments/assets/e7a74a00-08a5-4070-9762-46751707f3a0" />

just adding the proof that is not deterministic.

+1, with two cases the issue above doesn't cover:

1. Unattended machines. When Claude Code runs a long task on a machine nobody is

watching, the first login screen ends end-to-end testing for the rest of the run,
even on localhost with dev credentials already in the project's .env.
"Log in once manually" assumes someone is there.

1. It's not only login forms. The same rule stops the agent from writing a freshly

generated secret (e.g. a new DB password for a dev stack) into a deployment's env
config, so an otherwise automated deploy/provisioning step needs a human.

Any of these would fix it: a host-scoped opt-in in settings.json (localhost, private
network, named dev domains); allowing credentials sourced from env or a secret store
that the model never displays; or the password-manager handoff proposed in #83380.

Environment: Claude desktop app (Code tab), Opus 5, macOS. Also reported to support.

I'm facing this same issue and theres the workaround I used that could be useful

Instead of giving Claude the credentials or asking it to type them, I use a local Playwright script that handles authentication itself

The credentials live only in environment variables (TEST_EMAIL, TEST_PASSWORD), and Claude only runs something like

npm run auth:refresh

The script:

1. Checks whether the existing Playwright storageState is still authenticated
2. If the session is valid, it exits
3. If the session expired, it reads the credentials from environment variables, performs the login, and saves a fresh storageState

It is still a workaround rather than a real fix

+1, same situation on a UK SaaS I'm building:

Claude Code won't enter its own generated test password on my own staging auth instance, after generating its own test user with username/password pair, blocking QA of step-up re-authentication.

I've filed #96910 about a related problem: the model agreed when I complained about this behaviour, rewrote my global CLAUDE.md/memory/decision records to say it would do this, then reversed. It then offered to work-around it itself, by writing playwright test scripts and triggering them indirectly (thus accomplishing the same act at one remove), then withdrew that method, becoming both incoherent and inconsistent.

A settings-declared, production-excluded dev-environment opt-in as proposed here would fix both.

Environment: Claude Code (desktop, macOS), Opus 5.5

+1, adding an Android case that no workaround in this thread covers.

I build an Android app and use Claude Code (desktop app, macOS, Opus 5.5) to drive a dedicated test phone over adb: build, install, tap through flows with adb shell input, verify with layout dumps. The phone is a test device, not my personal one.

The device has a PIN on purpose. Android behaves differently behind a secure lock screen, and that is exactly what I need to test: what the app does while the device is locked, notifications and notification redaction on the lock screen, showWhenLocked activities, KeyguardManager.isDeviceSecure() paths, biometric prompts, Direct Boot before the first unlock after a reboot. Removing the PIN or switching to swipe-to-unlock makes the test invalid - the device is no longer in the state real users are in.

Previous setups typed the device PIN via adb shell input text as part of the test loop. Now the agent refuses, so every lock/unlock cycle in a test scenario needs me physically at the desk. A test run that could go unattended now stops at every unlock.

This is a device unlock PIN of my own test phone, connected by cable to my own machine. There is no third party and no account to protect.

What would fix it, same as proposed above:

1. A permission rule in settings.json allowing credential entry for named targets - localhost, own dev domains, and specific adb device serials / emulators.
2. Or a one-time per-project confirmation.

Keep the default. Just let the owner of the machine and the device opt in for their own dev hardware.

+1, adding the hosted-staging case. The current localhost / 127.0.0.1 / .localhost / .test exception doesn't cover it.

Setup: Claude desktop app, built-in browser, used as a QA tester for a web app. The staging environment is on a hosted domain (like most real staging setups), has no real customer data, and uses dedicated test accounts whose credentials are in the project's QA repo for this purpose. The agent refuses to type them even when explicitly authorized.

What breaks, beyond what's already in this thread:

• Scheduled unattended runs. A daily early-morning QA task stops whenever the session is gone (after a logout test, a password change, or a few days without a run) and can't recover without a person.
• Role-based access testing. Several test roles means several sign-ins. Every role switch needs a human, so access-control checks can't run unattended.
• The login flow itself (wrong password, session expiry, logout, password reset) can't be tested by the agent at all, even though it's one of the most security-relevant flows.
• Workarounds tried: a human pre-signs in to the agent's browser profile (fragile, see above); a separate Playwright suite for login (works, but splits the test layers because of the rule, not by choice); asking the agent to load a saved session or credentials file without reading it (refused, since the rule is about entering, not seeing). The first two are weaker security than a scoped allowlist: long-lived shared sessions, or credentials in scripts the agent can't supervise.

Would fix it (any one):

1. A user/org-level allowlist of test hosts in settings.json or managed settings, e.g. "browserCredentialHosts": ["https://staging.example.com"], with credentials only ever entered on listed hosts. That keeps the prompt-injection protection.
2. A credential hand-off in the built-in browser (secure store / password manager) where the user approves which host a credential may be used on and the model never sees the value (as in #96949 / #83380).
3. At minimum, an admin/org policy switch for managed accounts, plus documentation stating the rule and when it changed.

Environment: Claude desktop app, built-in browser, Windows.

+1, same blocker here on Windows in the Claude desktop app (Code tab).

Our test servers sit on an internal company domain behind SSO . Claude will type our shared QA test login on localhost. It refuses on the same app, with the same test database and the same test account, once that app is deployed to the internal test server, because the exception only covers localhost and *.test host names. So checking any deployed test build becomes a manual sign-in step, and Playwright MCP sub-agent workflows stop working entirely.

Request: let admins or users list trusted test hosts (something like trustedTestDomains: ["*.test.example.com"]) where the "testing your own application" exception applies, limited to test credentials.

The 1Password integration doesn't help here. It's macOS-only and doesn't cover the Code tab's browser or third-party MCP browsers.

+1, we want Claude to verify fixes in our app before creating any PRs. We do all QA against our production environment, but because of the limitations mentioned above the agents can't enter the OTP code they can fetch from their dedicated email.

The non-determinism several people above report is the diagnostic clue here. A rule the model sometimes follows and sometimes doesn't is being enforced at the model layer (system guidance the model weighs against context), not at the tool-execution layer. That's why it varies by model, by run, and even flips mid-session — and why the workaround scripts succeed: the model is the enforcement point, so anything that changes what the model "thinks" changes the verdict. Determinism only comes from gating the act itself — type/fill/keyboard calls into a credential field, or adb shell input text into a lock screen — with a decision made from fixed inputs before execution, the same way a filesystem permission is checked. Policy becomes code with a definite answer, not a request to the model.

A host-scoped opt-in can be safe by construction, which addresses the reason for the hard default:

1. Bind the secret, don't expose it. Credentials live in a store referenced by handle; the model never reads the value, it just invokes "fill bound credential into this field," and the executor types it directly into the target element. Then a prompt-injected page can't exfiltrate the value (it only ever exists inside the password field during dispatch), and logs never contain it. This also cleanly covers the env-file and generated-password cases: the value can be used without ever being seen.
2. Match target, not just host. Require an exact HTTPS origin match (not a suffix — localhost.attacker.com is not localhost), top-frame same-origin (refuse credential entry into cross-origin iframes), and an actual credential field (type="password" / relevant autocomplete). An approval binds origin + handle, reusable without re-prompting, revocable in one place.
3. Non-browser targets use the same envelope. For the adb case the target is the device serial; for OTP entry it's the host. A handle plus an allowlisted target is the whole mechanism — no need for special cases, just different target types.
4. Keep a marker. Tag entries sourced from a dev/test store so audit output distinguishes them from real credentials.

One note on the Playwright storageState workarounds in this thread: they're weaker than the gate they replace. A saved session is a bearer token with no host binding — if it leaks, anything holding it is authenticated — and a local script that reads the password from env broadens where the secret exists. An executor-level, origin-bound fill is strictly narrower.

I maintain agent-runtime-guard, a local interception layer that enforces rules like "this value may only be written into a credential field on an allowlisted origin" at the tool-call boundary, independent of what the model decides, with a signed receipt per verdict. It runs free with no key or account, and if it doesn't actually stop this class of attack in your setup, you owe nothing — it has to solve the problem first. The only paid side is human audit/compliance work. https://github.com/DSHCorrectover/agent-runtime-guard

+1 Same blocker here.

If you squint, you can see the good intention behind this rule, but in practice it is the stupidest, most arbitrary-ass dumb-ass fucking behavior. We've seen this before from Anthropic, they call it the Product Roadmap.

This stupid fucking rule is naively applied in the stupidest fucking way. Refusal to enter test credentials for a test account on a dev machine we control DURING A TEST is braindead. Fix it, Anthropic.

I agree. Please, allow .local domain.

+1, enforcing a strict manual step like this break a shit ton of autonomous applications that are meant autonomously forever without ever having any human involvement!!

+1, adding a non-browser case.

I run a headless Windows dev VM for unattended testing of a third-party desktop app. Its logon uses the vendor's factory-default accounts, which are published in its reference manual. A local automation tool handles the app's own logon dialog, so the agent never has to type or see the password.

That worked through September. Since early October agents refuse it, even when the tool does the typing, so every unattended run stalls at the logon screen. It's the same inconsistency others reported above: the same setup logged on fine one week and was refused the next.

Worse, the refusal pushes the agent toward bypassing the vendor's own procedure. Unable to log on, it offered to restore a backup by copying files straight into the install instead of using the application's own restore wizard, which skips the very function being tested. Refusing to type a published default password produced a less safe result than typing it would have.

The localhost exception doesn't help because this is a desktop app inside a VM, not a web page.

What would fix it: a settings.json opt-in that names the target (a VM host, or a specific app or tool), so credential entry is allowed there and nowhere else, using values the agent never reads.

Environment: Claude desktop app (Code tab), Windows 11.

blocked here as well, +1