[FEATURE] Built-in secrets management with optional third-party integrations

7 min read Original article ↗

Preflight Checklist

  • I have searched existing requests and this feature hasn't been requested yet
  • This is a single feature request (not multiple features)

Problem Statement

Claude Code has no first-class way to handle secrets. The current reality is that users paste API keys, database URLs, and tokens directly into the chat to get things working. For experienced engineers, this is a bad habit. For the growing wave of non-engineers using Claude Code to build, it's the only workflow they know.

I lead engineering at a startup where non-technical team members use Claude Code daily. Secrets management is our single biggest bottleneck to safe, autonomous building. When a non-engineer needs to connect to an API, the natural path is: paste the key into chat → Claude writes it into a .env file or a command → the key is now persisted in conversation history, potentially in plaintext on disk, and visible to anyone with access to the account.

Multiply this across every Claude Code user. Thousands of API keys, database credentials, and service tokens are likely being pasted into Claude conversations every day, turning Claude accounts into an aggregated honeypot of sensitive credentials. This is a ticking security incident.

Workarounds like Doppler or 1Password CLI exist, but they require CLI setup, environment configuration, and shell knowledge that non-engineers don't have. And non-engineers are exactly the population Claude Code is rapidly onboarding.

Proposed Solution

A built-in secrets manager with optional third-party integrations, designed around the principle that secrets should never appear in the chat context.

Core design

  1. Secret input via dedicated UI, not chat. When Claude needs a secret (or the user wants to store one), a secure input form appears in the terminal/UI. The value goes directly into the secrets store and never into the conversation transcript.

  2. Project-level secret references. A .claude/secrets.json (or similar) file in the project directory maps logical names to secret IDs:

    {
  "DATABASE_URL": {
    "source": "built-in",
    "id": "db-url-prod"
  },
  "OPENAI_API_KEY": {
    "source": "doppler",
    "id": "OPENAI_API_KEY",
    "metadata": {
      "project": "my-app",
      "config": "dev"
    }
  },
  "STRIPE_SK": {
    "source": "1password",
    "id": "op://Vault/Stripe/secret-key",
    "metadata": {
      "account": "my-team.1password.com"
    }
  }
}

    The metadata object carries provider-specific configuration (Doppler project/config, 1Password account, AWS region, etc.) so the integration knows how to resolve the secret. This file is safe to commit since it contains references and routing info, not values.

  3. Runtime injection via shell wrapper, not context. When Claude executes a command that needs secrets, they're injected at the process level (like doppler run -- or op run --), never read into the chat context. Claude sees the name of the secret, never the value.

  4. Pluggable backends. Ship with a simple built-in encrypted store for getting started, plus integrations for:

    • Doppler
    • 1Password CLI
    • AWS Secrets Manager
    • GCP Secret Manager
    • .env files (read-only, for existing projects)

Example workflow

User: "Connect to our Postgres database and show me the schema"
Claude: "I need a DATABASE_URL. Please enter it securely."
→ [Secure input form appears, user pastes the connection string]
→ [Stored as secret ref "db-url-prod"]
Claude: runs `claude-secrets run -- psql $DATABASE_URL -c '\dt'`
→ [Secret injected at process level, never in transcript]

On subsequent sessions, Claude reads .claude/secrets.json, sees the secret exists, and uses it. No re-entry, no chat exposure.

Why this matters now

Claude Code is becoming a platform for non-engineers to build software. That's an incredible unlock, but it means security can't depend on users knowing best practices. The tool itself needs to make the safe path the easy path. This feature would:

  • Eliminate the most common secret exposure vector in Claude Code today
  • Unblock non-engineers from safely connecting to APIs and services
  • Enable teams to share secret references (not values) via version control
  • Align with the existing permission model. If Claude Code already gates file writes and shell commands, secrets deserve at least the same care.

To be clear: this is just one component of a secure coding environment. It's still up to each organization to grant access to secrets responsibly, deciding who gets access to what, rotating credentials, scoping permissions appropriately. That responsibility doesn't change. But right now, even when a company does everything right on their end, the last mile is a non-engineer staring at a Claude Code prompt, API key on their clipboard, making a judgment call about how to provide it. The tooling should make that moment safe by default.

Happy to help spec this further. This is the single highest-leverage security improvement I can think of for the Claude Code ecosystem.

Alternative Solutions

Several issues have raised adjacent concerns, but none propose a complete secrets management workflow with third-party integration and a non-engineer-friendly input path:

This proposal aims to unify these concerns under a single, coherent secrets management system, particularly one that works for non-engineers who don't have Doppler, 1Password, or .env workflows already set up.

Priority

High - Significant impact on productivity

Feature Category

Interactive mode (TUI)

Use Case Example

A non-engineer on our team is building an internal tool with Claude Code that needs to pull data from our CRM's API. They've been given an API key by their manager. Here's what happens today vs. what this feature would enable:

Today (unsafe):

User: "Here's my API key for the CRM: sk-live-abc123xyz. Can you use it to pull our contact list?"
Claude: "Sure, I'll use that key to..."

The key is now in the conversation transcript. It's in Claude's context. If the user later exports or shares this conversation, the key goes with it. If they hit an auth error and paste the key again in a different session, now it's in two transcripts. The user has no idea this is a problem.

With this feature (safe):

User: "I need to connect to our CRM API. I have an API key."
Claude: "I'll need that key stored securely. Please enter it here."
→ [Secure input prompt appears. User pastes sk-live-abc123xyz. Value stored as "crm-api-key", never enters chat.]
→ [.claude/secrets.json updated: { "CRM_API_KEY": { "source": "built-in", "id": "crm-api-key" } }]
Claude: runs `claude-secrets run -- node fetch-contacts.js`
→ [CRM_API_KEY injected as env var at the process level. Claude sees the variable name, never the value.]

Next week, the user opens a new session to add a feature. Claude reads .claude/secrets.json, sees CRM_API_KEY is already stored, and uses it without asking. No re-entry, no exposure. If the key gets rotated, the user updates it through the same secure input prompt.

The user never had to learn about .env files, Doppler, or environment variables. They just answered a prompt.

Additional Context

No response