Password entry into login forms is blocked even for the user's own app with repo-provided credentials
What happened
Claude refuses to type a password into a login form, even when:
- the credentials are stored in the user's own repository (a gitignored
CREDENTIALS.mdthat the project'sCLAUDE.mdexplicitly points Claude to), - the target is the user's own application, on the user's own infrastructure,
- the user explicitly asks Claude to log in, and
- the project's saved instructions say that "open the admin panel" means "start the stack and log in, without asking".
The refusal cites the hard rule against entering passwords into any field, which is documented as non-overridable ("These actions stay prohibited when the user explicitly asks for them, supplies all the details, or says they authorize it").
Why this is a problem
This blocks end-to-end verification, which is the whole point of a coding agent in a web project. In my case Claude had just deployed an antivirus scanning worker to production and needed to verify the full path — upload a document through the UI, confirm it gets scanned and unblocked. Claude could deploy it, query the database, read the logs, and inspect the queue, but could not click through the one flow that proves the feature works for a real user.
The asymmetry is what makes it odd: Claude has SSH root access to the production cluster, can run arbitrary SQL against the production database, and can read every secret in CREDENTIALS.md — but cannot type one of those secrets into a login box. The blocked action is far less powerful than the ones that are allowed.
What I expected
For a developer's own application, in a project that has explicitly provisioned credentials for the agent, logging in should be allowed — or at least be something the user can opt into (per-project setting, permission prompt, allowlisted domain, whatever).
I understand the rule exists to stop credential entry on untrusted third-party sites reached from web content. That is a real risk and worth guarding. But a login form on the user's own app, with credentials the user put in the repo for this purpose, is not that scenario, and there is currently no way to distinguish the two.
Suggestion
Make this scoped rather than absolute. Some options:
- a per-project or per-domain opt-in for credential entry,
- treat credentials the user supplied in-repo differently from credentials discovered in web content,
- integrate with the existing permission-prompt system so the user approves it once per session/domain.
Environment
- Claude Code, desktop app
- Model: Claude Sonnet 5
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗