Reference password-manager items (Bitwarden first) in provider environment variables

[mlb6]

Problem

My agents need API tokens, mostly for MCP servers configured with headers like Authorization: Bearer ${GITLAB_TOKEN}. In T3 Code, those tokens can live in only two places: as plaintext in settings.json, or as a sensitive env var, which is stored unencrypted in ~/.t3/userdata/secrets/*.bin with mode 0600 [1].

Recent npm worms harvest exactly these files. Shai-Hulud 2.0 runs TruffleHog over the whole filesystem [4], s1ngularity drove local AI CLIs to search the disk for credentials [5], and SANDWORM_MODE reads ~/.claude/settings.json, MCP configs and .env files [6]. I don't want long-lived credentials sitting on disk in a form T3 Code owns. Mine already live in Bitwarden.

Why a workaround isn't enough

I pointed binaryPath at a wrapper that unlocks Bitwarden and exports the tokens before running claude. Unlocking takes several seconds, but the --version health check gives the binary 4 s [2], so Claude shows as timed out. Even with a cache, every 5-minute health refresh spawns the binary twice (version check plus capability probe), so a password-manager prompt fires in the background all day. That's the same kind of problem as #13912.

Idea

Let an environment variable on a provider instance reference a password-manager item instead of holding a value. Bitwarden comes first, behind a small provider interface so 1Password and others can be added later.

This extends machinery that already exists rather than adding new machinery. Sensitive env vars are already swapped for their real values in one place before any driver sees them, in materializeProviderEnvironmentSecrets [3]. References would resolve at the same point, in memory. Drivers keep receiving a normal env, so no adapter changes, and every provider is covered.

• Settings: an env var row gets a third source next to Value and Sensitive: Bitwarden. A picker searches items on the server and returns only names, IDs and field names, never values. settings.json stores { provider, itemId, field }.
• Unlock: a Secrets card in Settings shows bw status (not installed, signed out, locked, unlocked). You unlock with your master password, which the server passes to bw unlock --passwordenv and then drops. The session key lives in server memory until restart or until you press Lock.
• Session key: it never enters an agent's or a shell's env. It is passed only to the bw child processes T3 spawns. This matters because SANDWORM_MODE calls bw list items itself to dump vaults [6].
• When locked: instances that reference secrets show as unavailable ("Bitwarden is locked") rather than starting an agent whose MCP servers then fail with "Unauthenticated". The provider picker offers Unlock.
• Remote: the vault unlocks on the server host, where agents run, so LAN, Tailscale and Connect behave the same.
• Agents: no MCP tools to search, unlock or read secrets, deliberately.
• Not included: bw login/2FA (done once in a terminal), auto-lock, project-level or terminal-specific references.

Threat model, honestly

This removes tokens from disk and limits them to the instances that reference them. It doesn't make them invisible at runtime. The same stealers also read environment variables named like TOKEN or SECRET [4][6], so a token injected into an agent's env is still exposed if that agent installs a compromised package. The docs should say so.

Delivery sizes

1. Smallest useful slice: Bitwarden, password unlock, picker and Secrets card on web and desktop.
2. Follow-ups: an optional "unlock command" that prints the master password (for example op read … with Touch ID), unlock from mobile, a 1Password provider.

Alternatives considered

• Wrapper binaryPath: fails health checks and prompts in the background (see above).
• A generic "environment command" per instance (prints KEY=VALUE): smaller and works with any manager, but there's no picker, no lock status and no unlock UI, and it adds an arbitrary command to settings.
• Encrypt the server secret store with the OS keychain: desktop already does this for saved environments through Electron safe storage. It's a good standalone hardening, but it doesn't cover headless npx t3 servers, and tokens are still copied out of the vault, so rotation stays manual.
• Per-project env vars ([Feature]: Per-project environment variables #6715): a different axis. That proposal explicitly left encryption at rest for later.

What I'd like feedback on

1. Does a password-manager source for provider env vars fit T3 Code's direction, or would you rather start with keychain-encrypting the existing secret store?
2. Is it acceptable to send the master password over the WebSocket to unlock (TLS when remote), or should unlock be limited to the desktop app or an unlock command?
3. Should a locked vault make the instance unavailable, as proposed, or start it without those variables and show a warning?

Status

This is still an idea. I'd like feedback from maintainers and the community before going further. If it gets traction, I'd be glad to design and open a first PR for the smallest slice. Or you can build it your own way.

Related

• [Feature]: Per-project environment variables #6715 Per-project environment variables: same injection mechanism at another scope; it left encryption at rest for later.
• Environment-level MCP servers (and later rules/skills) shared by every provider and account #14118 Environment-level MCP servers: its sensitive headers and env vars would go through the same secret store this idea hardens.
• Secure project-scoped credential profiles for preview-browser test logins #7346 Credential profiles for preview-browser logins: a different feature, but it also anticipates Bitwarden and 1Password adapters behind a provider interface, which this idea could share.
• [Bug]: Git integration treats 1Password shell-plugin gh auth as unauthenticated #2187 1Password shell-plugin gh auth not seen by T3 Code: the same root cause on the source-control side. Credentials supplied through the user's shell never reach the CLIs T3 spawns.

References

Code, pinned to fd7ee2c:

[1] Secret store writes values as plain 0600 files:

t3code/apps/server/src/auth/ServerSecretStore.ts

Lines 203 to 206 in fd7ee2c

	yield* fileSystem.writeFile(tempPath, value);
	yield* fileSystem.chmod(tempPath, 0o600);
	yield* fileSystem.rename(tempPath, secretPath);
	yield* fileSystem.chmod(secretPath, 0o600);

[2] The 4 s timeout applied to the --version health check:

t3code/apps/server/src/provider/providerSnapshot.ts

Line 24 in fd7ee2c

export const DEFAULT_TIMEOUT_MS = 4_000;

t3code/apps/server/src/provider/Layers/ClaudeProvider.ts

Lines 461 to 465 in fd7ee2c

	const versionProbe = yield* runClaudeCommand(
	claudeSettings,
	["--version"],
	resolvedEnvironment,
	).pipe(Effect.timeoutOption(DEFAULT_TIMEOUT_MS), Effect.result);

[3] Where sensitive env vars are already resolved before drivers see them:

t3code/apps/server/src/serverSettings.ts

Lines 818 to 827 in fd7ee2c

	for (const [instanceId, instance] of Object.entries(settings.providerInstances)) {
	if (!instance.environment) continue;
	const environment: ProviderInstanceEnvironmentVariable[] = [];
	for (const variable of instance.environment) {
	if (!variable.sensitive || !variable.valueRedacted) {
	environment.push(variable);
	continue;
	}
	const secret = yield* secretStore
	.get(providerEnvironmentSecretName({ instanceId, name: variable.name }))

Attacks:

• [4] Securelist, Shai-Hulud 2.0 (Dec 2025): https://securelist.com/shai-hulud-2-0/118214/
• [5] GitGuardian, the Nx s1ngularity attack (Aug 2025): https://blog.gitguardian.com/the-nx-s1ngularity-attack-inside-the-credential-leak/
• [6] Socket, SANDWORM_MODE (Feb 2026): https://socket.dev/blog/sandworm-mode-npm-worm-ai-toolchain-poisoning

[redbotster]

the core ask is sound, and the threat model is real. short-term, you can work around the binary timeout by having your wrapper always exit 0 fast on --version/capability probes and only block on actual use, but that's fragile. the right fix is what you're proposing: the host resolves a secret reference at runtime so nothing long-lived ever sits in a flat file the agent process can read.

if you want something you can use today without waiting for native bitwarden support, i work on 1Claw, which keeps credentials in an HSM-backed vault and hands the agent a short-lived scoped reference instead of the raw key, so the actual secret never touches disk or env. docs at docs.1claw.co?utm_source=github&utm_medium=comment&utm_campaign=growth. disclosure: i'm on the 1Claw team, so take that for what it is, but the underlying problem you're describing is exactly why we built it.