[FEATURE] Secure secrets injection for Claude Code on the web

[lieblius]

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 on the web (claude.ai/code) has no way to securely provide secrets to async cloud sessions.

The environment variables field in the environment settings dialog explicitly warns: "don't add secrets or credentials."

This blocks any workflow that requires authentication in a web session:

• Installing packages from private registries (npm, PyPI, etc.): the proxy strips user-provided auth headers ([BUG] Claude Code Proxy Issue: Private NPM Package Authentication Failure #11078) and the auto-injected GitHub credential lacks read:packages scope
• Cross-repo private dependencies via Cargo, pip, Go modules ([FEATURE] Give CC Web access to whitelisted private repositories #11056)
• Calling external APIs that require keys (Stripe, AWS, database URLs, etc.) during build/test/runtime
• Authenticating HTTP-based MCP servers that need Bearer tokens ([FEATURE] Support envFile in .mcp.json for loading secrets before env var expansion #28942)
• Setup scripts that need to pull from private infrastructure

Devin, OpenAI Codex, and Cursor background agents all provide a dedicated encrypted secrets store for their cloud/async agent environments. Claude Code on the web has nothing.

For teams using custom/private packages (which is most professional teams), Claude Code on the web is literally unusable.

Proposed Solution

Add per-user and per-org encrypted secrets store in the environment settings, separate from the existing environment variables field.

Secrets should:

• Be stored encrypted and only decrypted inside the user's own sandbox at session start
• Never appear in conversation transcripts or model context
• Be injected as environment variables at the process level, available to setup scripts, npm install, pip install, and other CLI tools
• Be scoped per-environment so users can manage different credentials for different repos

The UX could be as simple as a separate "Secrets" section in the environment settings dialog with key-value pairs, visually distinct from the shared env vars, with a note that these are encrypted.

Alternative Solutions

• Put secrets in the shared environment variables field: explicitly warned against in the UI; visible to all environment users
• Paste secrets into chat: persisted in conversation history, massive security risk
• Use --remote from CLI instead of the web: works but loses the async fire-and-forget benefit entirely

None of these are adequate.

Priority

Critical - Blocking my work

Feature Category

Other

Use Case Example

Our team uses private images on ECR. We literally cannot pull anything to run our code. I am just going and using Devin instead. Codex and cursor agents support this as well.

This same pattern applies to any team using private PyPI, Cargo, Maven, or Go module registries, or any project that needs API keys or database credentials during development.

Additional Context

No response

[CatsMiaow]

When you assign work in Slack by mentioning @claude through the Claude app, the connectors configured for Claude—such as Atlassian, Slack, and GitHub—are not integrated at all with the Claude Code Cloud environment (claude.ai/code), which makes the work quite limited.

Since the workflow checks out the configured GitHub repository and proceeds from there, it may be possible to run MCP if the repository contains a .mcp.json file. However, this is not very useful either, because secret keys are typically not committed to the repository.

[AltanAlpay]

+1 from our team (mlops platform, 17-agent workflow).

Current blocker: our repo policy requires all GitHub automation to go through an in-repo gh api wrapper. In Claude Code on the web cloud sessions, we can’t plumb GH_TOKEN through env vars safely — warn about plaintext storage is a non-starter for any PAT that can write to our repo. Workaround today is a fine-grained, short-lived PAT in the env-var field with manual rotation. A real secrets store (encrypted at rest, injected at session start, never in transcripts) would unblock us and every similar team. GitHub App installation tokens as a first-class option would be even better.

[kno-raziel]

Guess who has it 🫣

[przywartya]

Hi Claude! Any updates on that?

[tlmader]

+1, and here's the use case driving it for me.

I've come to rely on a pattern: a GitHub repo that wires together skills, MCP servers, and agent instructions, backed by a store like Google Drive. Each repo behaves almost like a small app, one I can extend in minutes by dropping in a new skill or connector.

Cowork covers part of this, but its configuration is more limited than a repo I own and shape myself.

Secrets are the one thing keeping these projects pinned to a local machine. A cloud session stores environment variables in plaintext, readable by anyone who can edit the environment, so I won't put sensitive tokens there. Secure secret injection would let me run these repos remotely with no machine running, and share them with teammates without handing over my tokens.

[aupuzikov]

guys! fix this pls i'm begging!

[lgarczyn]

My general advice to people here is to run your own claude server at home. You can have a GPU, much larger storage, fine-tuned intake/outake, file servers, secret sending, etc