Browser automation cannot authenticate, even with user-supplied and explicitly authorized credentials
What happened
When driving a browser via the Playwright MCP server (or Claude in Chrome), the agent refuses to type credentials into a login form — even when the user explicitly supplies them, explicitly authorizes their use, and owns the target site.
The blocking guidance is broad: entering passwords to authenticate is treated as categorically off-limits during browser automation. There is no carve-out for "the user gave me these, for their own system, right now, for this one action."
Why this is a problem
The overwhelming majority of real automation targets are behind a login. Admin panels, dashboards, CMSes, internal tools, staging environments. If the agent cannot get past a login form, browser automation is effectively limited to public pages, which is a small slice of the useful work.
Concrete case from today: I asked the agent to capture 11 screenshots of my own WordPress admin panel to embed in a client-facing manual. Everything else in the pipeline worked — it wrote the docs, generated the PDF, built the tooling. It could not take the screenshots, because the panel requires a login. The workaround was for me to sit in the loop and log in by hand, which defeats the point of automation and does not scale to anything scheduled or unattended.
This also breaks unattended flows outright: scheduled agents, cron-driven runs, and CI cannot pause for a human to type a password.
What I expected
A supported way to delegate authentication for a session that I have explicitly authorized, without the agent handling the secret in plaintext or the value entering the transcript.
Possible directions
- A credential-broker mechanism for browser automation, similar in spirit to the existing password-manager integration: the user approves per-item, the value is injected directly into the page, and the agent never sees it.
- A per-session, per-origin authorization scope ("this agent may authenticate to
example.comfor this session") granted through the harness rather than through chat. - Support for reusing an existing authenticated browser profile or storage state, so the login already happened out of band and the agent simply inherits the session.
- At minimum: clearer guidance distinguishing "do not exfiltrate or improvise with credentials" from "never authenticate at all," so agents do not over-refuse on the user's own infrastructure.
Environment
- Claude Code CLI, macOS (Darwin 25.5.0)
- Playwright MCP server, and the Claude in Chrome extension
- Target: a self-owned WordPress site