Secure credential provisioning: non-developers cannot get a working local env

The gap

Claude Code is good enough that non-developers are now doing real work in real repos. The thing that stops them is almost never the code. It is credentials — and Claude Code currently has no safe way to help with them, so the assistant leads someone all the way to a working checkout and then goes silent at the one step that matters.

Concrete case

A designer working in a Nuxt + Supabase repo. To run the site locally they need three environment variables.

Every available path was closed:

1. vercel env pull returns empty strings. All three vars were marked Sensitive in Vercel, which makes them permanently unreadable — by the CLI and by the dashboard. (Two of the three did not need to be secret at all, but that is a config mistake this flow does nothing to surface.)
2. No access to the upstream project. Their Supabase login could not see the project, so they could not read the keys at the source.
3. A teammate could hand over a .env — except the recipient does not know what a .env file is, where it goes, or that it must not be committed. This is exactly the population Claude Code is otherwise serving well.
4. Claude cannot accept a pasted secret, correctly, because it would then live in the conversation transcript — a worse place for it than the file it was headed to.

So the assistant that just set up their entire environment has to say "ask someone else to do this part," to a person who does not know who to ask or what to ask for.

What is missing

1. A write-only credential channel. A way for a human to supply a value that Claude writes to disk or to a process environment without the value entering the transcript or model context. This primitive already exists in spirit — there is a credential-request path for password-manager-backed sign-in, where the user approves in the manager's own UI and Claude never sees the value. Local development environment variables need the same treatment. Claude should be able to say "I need SUPABASE_KEY" and have the runtime collect it out-of-band and write .env.

2. Team/shared secret provisioning. A sanctioned way for one team member to grant another's session access to a shared bundle, so onboarding is "run this" rather than "get someone to DM you a file and hope they explain what to do with it."

3. Guided env setup. Claude able to invoke a terminal-side prompt for missing values, rather than instructing a non-technical user to create a dotfile by hand.

Why it matters

The promise is that AI lets non-developers contribute to real codebases. Today that holds right up until authentication, and then it stops hard — not for a technical reason, but because the safe primitive does not exist. The workaround people will actually reach for is pasting secrets into chat, which is the outcome the current restriction is trying to prevent. The restriction is correct; the missing capability is what makes it costly.

Suggested shape

• A tool like RequestSecret({ name, purpose, destination }) that prompts in the terminal, writes to the target file or env, and returns only success/failure to the model.
• Optional integration with the OS keychain, 1Password/other managers, or the platform CLI already authenticated in the session (Vercel, Supabase, AWS).
• A dev-time warning when a platform's own settings make a value unrecoverable (e.g. Vercel "Sensitive"), so teams do not discover it at onboarding time.