Feature request: cross-device secret lockbox with broker injection (agent can USE secrets, never READ them)

Problem

Agentic multi-machine workflows have no sanctioned way to move or use secrets. Real scenario from a
cross-machine build (Windows owner PC + Mac build host, headless claude -p loops):

• The agent's permission layer correctly walls off .env (deny rules) and the auto-mode classifier

correctly blocks agent-driven transfer of credential files as an exfiltration shape. Good -- those
protections work.

• But the workload legitimately NEEDS those secrets on the second machine (DB gates, analytics gates,

deploy tokens). With the agent correctly locked out, the only remaining mechanism is the HUMAN
hand-couriering values between machines (clipboard, retyping, throwaway private repos). Every
multi-machine agent project hits this wall, and the human becomes the least secure part of the system.

• apiKeyHelper gestures at the right idea but is a single-credential hook, not a store, not synced,

and not enforced against model reads.

Proposal: a "lockbox" -- synced secret store with broker injection

1. A secret store in the Claude Code app/CLI, synced across a user's devices (like settings/auth already

are), encrypted at rest, OS-keychain-backed locally.

1. Secrets are marked never-readable-by-model: values can NEVER enter model context. Not via Read, not

via Bash cat, not via env dumps in tool output (redact on the way into the transcript).

1. A broker primitive the agent CAN invoke: "run <command> with lockbox secrets X, Y injected as env

vars." The broker resolves values into the child process env at exec time; the agent sees exit codes
and (redacted) output, never values. Per-secret session grants, user-approved once; audit log of
which session used which secret when.

1. Per-session opt-in: a session sees nothing from the lockbox unless the user enables it, and can be

granted individual secrets rather than the store.

Why this completes the existing security story

The current layers (deny rules + exfil classifier) are half the design: they stop the agent from
touching secrets but leave no sanctioned path for the workload to use them, so users route around the
protections themselves (which is worse). A broker makes the safe path also the easy path: the agent can
run db-migrate with DATABASE_URL injected on any of the user's devices, while the value stays
provably outside model context on all of them.

Filed by a Max user running multi-machine agentic builds who has now hand-couriered secrets between
machines three times. "Secrets should be protected, of course, but on all the machines where they are
needed. Not locked to the machine where I created them and not hand couriered by the operator."