Playwright automation is unusable behind logins: agent refuses user-supplied, user-authorized credentials

Summary

The automation system is broken: it does not allow automating with Playwright because of credentials and passwords, even when the user supplies them and explicitly authorizes their use.

Detail

I own the site. I have the credentials. I handed them over and I authorized the agent to use them, for one specific task, on my own infrastructure. The agent still refuses to type them into the login form.

This is not a security win. Nothing is being protected here that I did not already control. The only outcome is that a task I explicitly asked for does not get done.

Why it matters

Practically everything worth automating sits behind a login. Admin panels, dashboards, internal tools, staging sites, CMSes. If the agent stops at the login form, browser automation only works on public pages, which is a fraction of the real work.

Today this cost me a deliverable. I asked for 11 screenshots of my own WordPress admin panel to put into a client manual. The agent wrote the documentation, generated the PDF and built the tooling around it, then could not take a single screenshot because the panel requires a login. The fallback was for me to log in by hand while the agent waited.

That fallback does not exist at all for scheduled agents, cron runs, or CI. Those simply fail.

What it should do

If the user provides credentials and authorizes their use for their own system, the agent should be able to authenticate. The user's explicit authorization should count for something. Refusing an action the user owns, requested, and approved is not a safe default, it is a broken one.

Environment

• Claude Code CLI, macOS (Darwin 25.5.0)
• Playwright MCP server, and the Claude in Chrome extension
• Target: a self-owned WordPress site