Credential handoff for browser logins: password manager integration for headless/mobile sessions

Problem

I run an IT consultancy and manage infrastructure for a dozen or so client organizations. A routine, unavoidable part of that work is signing into browser-based admin panels: domain registrars, firewalls, PBX consoles, WordPress installs, vendor portals. Many of these have no API at all, so the browser is the only interface.

Claude Code cannot enter a password into a login form. That limit holds even when I own the account, I supply the credential, and I explicitly authorize it. The result is that Claude does the entire job right up to the sign-in box and then stops, and I have to finish it by hand.

This hurts most in the case I rely on Claude Code for the most: working from my phone, away from my desk. Claude can research the problem, reach the systems, diagnose the fault and tell me exactly which fields to change, but cannot get through the one login standing between it and finishing. On a phone that is the difference between a task being done and a task being parked.

Concretely, this week Claude diagnosed a broken WHOIS record for a client domain entirely on its own, using registrar WHOIS, the DNS provider's API, and Google Workspace admin tooling, and identified the exact four fields that needed correcting. It could not sign into the registrar to make the four edits. Everything hard was automated. The trivial part was not.

Supporting evidence: this behavior changed between model versions

I asked Claude to check rather than speculate, and it searched my own Claude Code transcripts under ~/.claude/projects (524 sessions, 563 MB).

• 17 password entries into web login forms between 2026-06-05 and 2026-07-24, using browser_fill_form, browser_type, and browser_evaluate.
• Every one of them was claude-opus-4-8.
• The last one was 2026-07-24. The first claude-opus-5 message in my history is 2026-07-25, the following day.
• Zero password form fills under claude-opus-5 across 8,965 messages.

I am not reporting this as a regression to be reverted, and I understand why the limit exists. I am reporting it because it shows the workflow was real and that I built around it, and because the change removed a capability I depend on without leaving any supported way to accomplish the same thing.

Note that Claude Code does not store system prompts in its transcripts, so it could not determine whether the underlying instruction changed or model compliance did. I would rather flag that as unknown than guess.

Requested solution

A supported credential handoff, where the secret goes from a password manager or OS keychain to the page without the model ever seeing or typing it, and the user approves each item in the password manager's own interface.

Claude tells me a mechanism along these lines is described to it but is not available in this environment. If that is accurate, exposing it in Claude Code is the whole request. It solves the problem without a model handling plaintext credentials, which seems strictly better than the status quo for everyone.

Useful properties, in rough priority order:

1. Works headlessly and from mobile, since that is the case that hurts.
2. Per-item approval rather than a blanket unlock.
3. Scoped to a specific origin, so approving a login for one site does not authorize others.
4. Auditable, so I can see afterward which credentials were used where.

Alternatives considered

• settings.json permissions. Does not apply. The allow and deny lists take tool call patterns such as Bash(ssh user@host:*). This is not a tool permission, so no entry reaches it.
• Hooks. PreToolUse and PermissionRequest hooks intercept tool calls and can approve or deny them. Wrong layer, same reason.
• CLAUDE.md or saved memory. These shape how Claude works, they do not grant permissions.
• Selecting an older model. Opus 4.8 is still available and by the evidence above still exhibits the old behavior. This is not a real answer. I do not want to pick models based on which one will do a login, and it leaves me on an older model for unrelated work.
• Doing the logins myself. What I do now. It defeats the purpose when I am away from a computer, which is exactly when I lean on Claude Code hardest.

Use case

Solo IT consultant, roughly a dozen client organizations, heavy Claude Code user across desktop and mobile. Typical sessions involve reaching client infrastructure over SSH and WinRM, driving vendor APIs, and administering Google Workspace and Microsoft 365 tenants. Credentials are already stored in a password manager and a documentation platform.

The pattern is consistent: everything with an API, Claude handles end to end. Everything browser-only stops at the login box. Given how much client infrastructure is administered through vendor web consoles with no API, that gap is large and it is growing.

Environment

• Claude Code 2.1.220
• macOS 26.4
• Models: claude-opus-5 and claude-opus-4-8