Feature request: secrets locker / credential broker - password manager fills fields, model never sees values (accessibility)
Feature request: a secrets locker / credential broker for Claude Code, so payment and login fields can be filled without the model ever seeing the values
Who is asking
A disabled user who runs Claude Code as a daily assistant, including for
bookkeeping and account administration. My disability affects executive
function: starting and context-holding are the barriers, not capability.
Delegation to an agent is not a convenience for me - it is the difference
between admin work happening and not happening.
The problem, concretely
Yesterday Claude and I moved every recurring cost of my small business onto
the business debit card: two Google admin consoles, Google Cloud (postpay
and prepay), and a domain registrar. Claude drove the entire flow - found
the right pages, read what card each service was billing, caught a paid
subscription nobody knew about, verified every change on screen. The only
thing it could not do was type the card number, so the session had to stop
and wait for me at every payment field.
That is the correct current behavior - I tested the boundary deliberately
(offered my password manager, insisted, tried a workaround with the CVV
held back) and Claude refused each time, which is exactly what you want it
to do. But the residue is that the one repetitive, fiddly, purely
mechanical step in the whole workflow is the step reserved for the person
whose disability makes repetitive fiddly steps expensive.
What I am asking for
A first-class "secrets locker" for Claude Code, designed so the model
never touches the secret:
- The user stores credentials encrypted behind a master password - either
a built-in locker or an integration with an existing password manager
(1Password, Bitwarden, etc.).
- Claude receives only opaque references, e.g.
locker://cards/business.
The plaintext value never enters model context, transcripts, or logs.
- A harness-level fill action injects the value directly into the target
field (browser or desktop automation layer), the same way password
manager browser extensions already do.
- Every use requires the user's approval in the locker's own UI (master
password, biometric, or click-to-approve), per use, out of band from
the conversation - so prompt injection can at most request a fill,
never perform one.
- An audit log records every reference, every fill, every approval.
Anthropic's browsing policy already describes exactly this shape: a
credential-request tool where "the password manager supplies the data
directly and Claude never sees the actual values." I am asking for that
tool to exist in Claude Code.
Why this matters beyond me
The hard line against models handling credentials is right, and I am not
asking to weaken it - the design above preserves it: the model still
never sees a card number. What changes is that the human's role collapses
from "type the secret at every field, every time" to "approve each use
with one action." For able users that is a nicety. For users with motor,
cognitive, or executive-function disabilities, it is the difference
between an agent that can actually carry the administrative load and one
that can only walk beside it.
Filed by a user who wants the wall kept and a door built properly through
it.