Feature request: Built-in secret/key vault for plugins and hooks

Problem

Plugins and hooks that need API keys (e.g., for LLM calls, external services) have no sanctioned way to access secrets. Every plugin ends up independently reimplementing "find the API key" by:

1. Checking custom env vars (MY_PLUGIN_API_KEY)
2. Falling back to well-known env vars (ANTHROPIC_API_KEY) without explicit user consent
3. Asking users to write keys into plaintext config files

This is both a poor UX (users must manually configure each plugin) and a security concern (plugins silently read env vars that weren't explicitly granted to them, keys stored in plaintext TOML/JSON).

Proposed solution

A built-in key vault that lets plugins declare secret requirements and access them through a proper channel:

• Plugin manifest declares needed secrets — e.g., "secrets": ["ANTHROPIC_API_KEY"] in the plugin config
• User consent prompt — Claude Code prompts the user once to grant a plugin access to a specific secret, similar to how tool permissions work today
• Scoped access API — Secrets are provided to hooks/MCP servers via a dedicated mechanism (e.g., a field in the hook stdin JSON, or an MCP resource) rather than relying on env var inheritance
• Encrypted at rest — Secrets stored by Claude Code are encrypted, not plaintext JSON/TOML
• Zero-config for common cases — If the user already has ANTHROPIC_API_KEY set and a plugin requests it, the consent prompt can just say "Plugin X wants to use your Anthropic API key — allow?"

Current workaround

In claude-rlm, we check ANTHROPIC_API_KEY as a fallback and provide a claude-rlm config set api-key <key> command that writes to a plaintext TOML file. It works, but it means every plugin reinvents this wheel and users get no visibility into which plugins are reading which secrets.

Why this matters

As the plugin/hook ecosystem grows, the current approach of "every plugin reads whatever env vars it wants" doesn't scale. A vault with explicit consent would:

• Give users visibility and control over what secrets plugins access
• Eliminate redundant per-plugin key configuration
• Keep secrets encrypted rather than scattered across plaintext config files
• Establish a standard pattern so plugin authors don't each invent their own