Claude Code

Inside an existing project, branch off your dev environment to create an isolated config. The agent's config is separate from your personal one, so you control its blast radius.

Branch configs are prefixed with the environment slug. dev_agent_claude lives under dev and inherits from its root unless you override.

Scope it down so if a task needs one API key, add one API key. Claude Code reads ANTHROPIC_API_KEY from the environment automatically.

Do not let the agent populate or modify its own secrets. A human decides what goes in this config. The token in the next step is read-only precisely so the agent can't write back. Add any work credentials the agent legitimately needs (a scoped GitHub token, a test-DB URL) to this same config so they inject together, keeping the set minimal.

Bound to this one config, with an expiration so a leaked token doesn’t affect other areas. This is the single credential the CLI and the MCP server both use. Capture it into an environment variable so the next steps can reference it without pasting the raw value around.

Service tokens are read-only by default. The agent can fetch secrets, never change them. This is the agent's identity.

Bind the agent's token to a single directory so the CLI only uses it there. Run this from the folder Claude Code will work in.

The --scope . flag locks the token to the current directory. As long as Claude Code runs the CLI inside that folder, it resolves secrets with this scoped agent token and never uses your personal token. ($DOPPLER_CLAUDE_TOKEN is the value you captured in step 4.)

Note: Run the agent in a sandbox scoped to that directory. And proceed with caution on production workloads: a non-deterministic agent with live credentials is real blast radius, so keep it pointed at dev/test configs unless you have a specific reason not to.

Steps 1-6 give Claude Code the credentials it runs with. The MCP server is the other half. It lets Claude Code see and operate Doppler itself, listing projects, inspecting a config, and understanding the secret layout before it writes code that depends on it.

The MCP server uses the same scoped, read-only token you minted in step 4. This is separate from the CLI directory scoping in step 5. The MCP server gets its token straight from the config below, so scope the token itself tightly.

MCP client config is plain JSON and does not expand shell variables, so a literal "$DOPPLER_CLAUDE_TOKEN" in an env block gets sent as the token, and auth fails. Wrap the server in doppler run so the shell resolves the variable, and pass --read-only because the server can't infer read-only from the token alone: