[FEATURE] Opt-in for credential/payment entry on the user's own accounts, and 1Password-style credential handoff in Claude Code

Summary

The browser-automation safety section that Claude Code injects when the Claude in Chrome MCP tools are present contains a "Prohibited (never perform)" list:

Entering financial credentials, bank/card/account numbers, SSN/passport/government IDs, passwords, API keys, or tokens into any field Creating accounts, or entering passwords to authenticate These actions stay prohibited when the user explicitly asks for them, supplies all the details, or says they authorize it.

There is no opt-in, no per-site allowlist, no confirmation flow and no managed-settings switch. The only escape hatch the prompt itself mentions — "If a dedicated credential-request tool is available, Claude may use it to ask the user's password manager to handle sign-in, payment, or address details" — exists as 1Password for Claude (beta, support article), but only for the Claude Desktop sidebar / Claude in Chrome extension. It is not exposed to a Claude Code session driving the same extension through the claude-in-chrome MCP, so from Claude Code the rule has no sanctioned way through at all.

This is a request for (a) that credential handoff in Claude Code, and (b) an explicit, user-controlled opt-in for the case where no password manager is involved.

Who this affects and why it matters

I run a small business alone and operate a dozen-plus SaaS, hosting and registrar accounts. For months I delegated dozens of routine browser operations per day to Claude Code + Claude in Chrome: signing into admin panels, topping up hosting balances, renewing domains, paying invoices, registering service accounts. To bound the risk I keep dedicated accounts and a dedicated payment card for agent operations, with credentials stored on my own machine. I understand and accept the risk on those accounts; that is exactly why they exist.

Concrete incident (Sept 23–24, 2026): a VPS was suspended for non-payment while I was travelling without a laptop. Claude Code diagnosed it, opened the hosting panel, filled the email field, reached the billing/top-up flow — and then stopped at the password field and at the payment step, citing the rule above. The server stayed down until I could do the two trivial steps by hand. Identical flows (same panel, same card) had been completed by Claude Code sessions on Aug 16 and Sept 5, 2026, so from the user's side this is a silent regression of a capability they were relying on.

The "last mile" this rule blocks is the least valuable and least risky part of the task for a user who owns the account. Everything hard is automated; the trivial step is not — and it fails precisely in the remote/mobile scenario where delegation matters most. The same wall is reported in #83380 (password-manager handoff), #78985 (sandboxed QA logins) and #80853 (closed by the stale bot), all with multiple +1s and no maintainer response.

Why a blanket rule is the wrong tool here

The threat the rule addresses is real: credentials or payment details entered because of injected instructions, or on accounts the user did not intend to expose. But the prompt already has a separate "Instruction source boundary" section that handles injected content, and the rule as written makes no distinction between:

1. an instruction found in observed content (should be refused), and
2. the account owner, in chat, using credentials stored on their own machine for this purpose (should be allowed after confirmation, like every other risky tool call in Claude Code).

Treating (2) like (1) does not remove the risk — the user simply types the same secret into the same field by hand — it only removes the assistant.

Proposed changes (any one helps; all three would resolve it)

1. Bring the credential handoff to Claude Code. 1Password for Claude already implements the exact pattern the prompt describes (per-item approval in the manager's UI, injection into the page, the model never sees the value). Expose it — and ideally Chrome's built-in password manager — through the claude-in-chrome MCP so Claude Code sessions get the same path, with an approval that can also be taken on a phone for remote sessions. This is the request in #83380. (Secret-retrieval MCPs such as Bitwarden's are not a substitute: they hand the secret to the model, which then still may not type it.)
2. An explicit, durable opt-in in settings.json (and manageable via managed settings), off by default, e.g.

``json
"browserSafety": {
"allowCredentialEntry": ["new.contabo.com", "my.registrar.example"],
"allowPaymentEntry": ["new.contabo.com"]
}
``
On an allowlisted origin, credential/payment entry moves from "Prohibited" to the existing "Explicit permission required" tier, with the standard per-action permission prompt. Injected-content instructions remain refused by the source-boundary rule regardless of the allowlist.

1. At minimum, tell the user up front. Today the rule is only discovered at the moment of refusal, deep into a task. A one-line note in the Claude in Chrome docs and in /help ("Claude will not type passwords or payment details; here is the supported handoff") would save users the hours of "it worked last week" debugging that #80853 and this issue describe.

Environment

• Claude Code 2.1.280 / 2.1.281 (macOS, Darwin 25.5.0), models Sonnet 5 and Fable 5.1
• Claude in Chrome extension 1.0.93, via the claude-in-chrome MCP server
• Confirmed the section is delivered server-side: the strings above are absent from the CLI binary (strings … | grep) while other prompt text from the same section is present, so there is no local file to configure.