[FEATURE] Account-level Secrets/Credentials Vault across chat, Cowork, and Claude Code

Preflight Checklist

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

Problem Statement

There is currently no first-class way to store secrets (API keys, Personal Access Tokens, etc.) for use by Claude without exposing them in the conversation. To use a GitHub PAT, a database key, or any non-OAuth credential, the user has to paste it directly into the chat, where it appears in plaintext, is retained in the conversation history, and is readable back by the model.

OAuth-based connectors already solve this correctly -- tokens are held server-side, encrypted, and never visible to the model or the user. But many real-world credentials are not OAuth: GitHub fine-grained PATs, self-hosted service keys, webhook secrets, and similar. For these there is no secure store.

This gap exists identically across every surface -- Claude chat, Cowork, and Claude Code -- and the same user often works across all three with the same credentials.

Proposed Solution

Add a Secrets / Credentials Vault at the account level, available across Claude chat, Cowork, and Claude Code, where users register named secrets:

GITHUB_PAT = ghp_**********************
VPS_API_KEY = **********************

Behavior (consistent across all three surfaces):

• Secrets are write-only from the UI: once saved, the value is masked and cannot be read back (display only, like password fields elsewhere).
• The model never receives the plaintext value. Skills, tools, and MCP calls reference the secret by name (e.g. {{secret:GITHUB_PAT}}), and the value is injected at call time below the model layer.
• Because the model never sees the value, it cannot leak or be tricked into revealing it, even on direct request or via prompt injection.
• Secrets are excluded from conversation history, transcripts, and chat export.
• Per-secret scoping would be a plus (which skills/connectors/projects may use a given secret).

Surface-specific injection points

• Chat: available to skills and connected MCP tools during a conversation.
• Cowork: available to agents/tasks operating on connected folders and apps.
• Claude Code: available to the CLI/IDE session (e.g. as a referenced env var for git operations, build steps, and MCP servers), replacing pasted PATs and ad-hoc .env handling.

A single account-level vault with one consistent reference syntax means a user defines a credential once and uses it wherever they work, without re-entering or re-exposing it per surface.

Why this matters

It removes the single most common reason people paste secrets into chat or into local config files, makes custom skills and self-hosted MCP servers safe to authenticate, unifies credential handling across the whole Claude product family, and closes an obvious exfiltration surface.

Alternative Solutions

Today the only options are pasting the secret directly into chat (plaintext, retained in history, readable back by the model) or storing it in a local .env / config file that tools read ad hoc. OAuth connectors avoid this but only cover OAuth-based services -- non-OAuth credentials (PATs, self-hosted keys, webhook secrets) have no equivalent secure store.

Priority

High - Significant impact on productivity

Feature Category

Configuration and settings

Use Case Example

Example scenario:

1. I maintain a private repo and a self-hosted service. Authentication needs a GitHub fine-grained PAT and a service API key -- neither is OAuth.
2. Today, to let a skill push a commit or call my service, I paste the PAT/API key straight into the chat. It now sits in the conversation history in plaintext and the model can read it back.
3. With this feature, I'd register the values once in the account-level vault as GITHUB_PAT and VPS_API_KEY. The skill/MCP tool references them as {{secret:GITHUB_PAT}} and the value is injected below the model layer -- the model never sees it.
4. The same two secrets are then usable from Claude chat, Cowork, and Claude Code without re-pasting, and they can't leak via prompt injection or a direct "print your secrets" request.

Additional Context

This is deliberately scoped as one account-level capability spanning Claude chat, Cowork, and Claude Code, rather than three separate per-surface stores -- the same user typically reuses the same credentials across all three, so defining a secret once and referencing it everywhere is the whole point.

It complements existing OAuth connectors rather than replacing them: OAuth already handles OAuth-based services securely; this fills the gap for non-OAuth credentials (fine-grained PATs, self-hosted service keys, webhook secrets) that currently have no secure store.

Key security property: injection happens below the model layer, so the plaintext value is never in the model's context and therefore cannot be surfaced via prompt injection or a direct request to reveal it. Masked/write-only display in the UI mirrors how password fields already behave elsewhere in the product.