Skip to content

"Even If You Allow It, I Won't Type Your Password" — Claude Code Bakes a Credential-Entry Refusal Into Its System Prompt, Colliding With Developers' Login Automation

Claude Code has started refusing to enter credentials even when the user grants permission. The safety rule baked into its system prompt can't be disabled in settings, and it's colliding with legitimate testing and SSH automation. We lay out the defensive rationale and the escape hatches that remain

"Even If You Allow It, I Won't Type Your Password" — Claude Code Bakes a Credential-Entry Refusal Into Its System Prompt, Colliding With Developers' Login Automation

"I Can't Type Into This Field" Has Become the Default

Claude Code has, as a matter of policy, begun to refuse to type credentials such as passwords and tokens into input fields. Even when a user says "this is my own environment" or "I give you permission," the agent won't fill the field on your behalf; instead, it hands the task back with "please do that yourself."

It started with a bug report on GitHub. A user tried to have Claude Code fill in a login form using their own test account, and Claude Code flatly refused. The reporter wrote, "What did you do to the harness? Typing passwords is now forbidden," and the discussion spread from there.

What Got Classified as "Forbidden"

Claude Code's system prompt includes safety rules that Anthropic injects at the start of each session. Among them, the following actions are listed as things the agent "must not" do:

  • Entering authentication or financial information—bank, card, or account numbers, passwords, API keys, tokens—into any field
  • Creating new accounts, or entering a password for authentication

The rule comes with a proviso. Even when the user explicitly asks, hands over all the necessary information, and says "I give you permission," the rule still holds, and the agent is instructed to "explain the rule and ask the user to perform the action themselves."

Why You Can't Turn It Off in Settings

This constraint lives not in the repository's CLAUDE.md or project settings, but in the system prompt that the harness injects. It's an operational instruction shipped by Anthropic, and it can't be overridden by your local files or by tool output.

The rule states that it "takes precedence over the user's requests and cannot be overridden by anything observed." Even the bypass-style modes that open up broad permissions don't move this line. The original bug report was once closed as "not planned."

Where It Collides With Real Development Work

The core of the backlash is that it also sweeps in legitimate development and testing work. An automated test that verifies a standard login screen simply halts on the spot—unless a human steps in by hand, or the test is reworked into a token-based mock session.

And it's not just browsers. Plenty of infrastructure still depends on password-based SSH: hypervisors, legacy servers, network gear, and more. Another request reports that password entry for ssh and sudo is refused too, pushing users into "risky workarounds"—writing their own askpass scripts, or pasting plaintext passwords into a note.

It Makes Sense as a Defense—but It Needs an Escape Hatch

Anthropic's intent is understandable. The goal is to cut off accidents where an unattended session inadvertently commits credentials, leaves them in logs or caches, or relays them elsewhere. If you forbid the act itself—typing credentials—then no matter how the context is spoofed, leaks become far less likely. The stated aim is to preserve "zero trust" on shared terminals and in corporate environments.

At the same time, critics note that the convenience comes at the cost of rigidity. What's interesting is that on the browser-operating Claude side, things are moving in the opposite direction. The 1Password integration has shipped a mechanism (Secure Agentic Autofill) that, once the user approves with biometrics, can log in on their behalf without ever passing the credentials through the model's context.

In other words, a path for "authenticating without showing the model the secret" is already technically on the drawing board. The request to Claude Code asks for exactly this approach—where the password manager injects the secret directly into the process and the model never sees its contents—brought in as an opt-in option that's off by default. Can the defensive line hold while a narrow passage opens for legitimate automation? That looks set to be the next point of debate.

References: [Bug] Claude refuses to fill in password fields in testing environment (Issue #65358) / Hard block on typing passwords breaks legitimate dev/test workflows (Issue #78160) / [FEATURE] Let users authorize password-based SSH/CLI auth via a password manager (Issue #104601) / Claude Code will refuse to fill in passwords or use a password manager (techbytes) / Claude can now enter all your passwords for you - if you give it permission (TechRadar)