secrets

# Request secrets securely Use `bb secret request` whenever work needs a credential. Do not ask the user to paste a secret into chat. Batch every currently known variable into one request. Inspect documentation or `.env.example` to identify variable names, but do not read or print an existing secret-bearing env file. ```bash bb secret request OPENAI_API_KEY RESEND_API_KEY \ --purpose "Configure application credentials" \ --describe OPENAI_API_KEY "OpenAI API key used by the server" \ --describe RESEND_API_KEY "Resend API key used for transactional email" \ --write-env .env.local ``` Always provide the exact `--write-env` destination, a concise purpose, and one short plain-language description per variable. Relative destinations resolve from the CLI working directory; absolute destinations may point anywhere on the thread's host. Never place secret values in argv, prompts, comments, logs, or follow-up messages. After success, trust the command's path and added/updated/unchanged counts. Never verify by running `cat`, `sed`, `env`, or another command that would reveal the completed file. If the command reports duplicate dotenv assignments, fix the file structure without reading values and rerun the request. If it reports repeated write conflicts, rerun the same request; do not ask the user to paste values. Under the workspace sandbox (Accept Edits / Approve for me), provider loopback policy may require escalation approval for plugin CLI commands; use Full Access when that access must be unrestricted.