Feature request: server-injected per-installation secret for key wrapping (software "TPM")

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

On headless VPS deployments without a TPM, TEE, or attachable hardware token, there is no way to give Claude Code access to a secret (API tokens, Vault credentials, SOPS/age keys) without leaving that secret readable on the filesystem. The current OAuth token in ~/.claude/.credentials.json is a plaintext bearer, which makes Claude Code itself part of the problem rather than part of the solution.

The practical consequence: any at-rest exposure — stolen disk image, leaked backup, misconfigured snapshot, a container layer pushed by accident — hands over the credentials directly.

What this does and does not solve

Worth stating plainly, because the limitation is real: this does not defend against a live root attacker on the same host. Once plaintext is in the process address space, ptrace and /proc/pid/mem win, and no software-only design changes that.

What it does solve is the offline case — disk theft, backups, snapshots, images, accidental commits — which is the dominant real-world failure mode for self-hosted deployments. That is the same threat model a TPM addresses, for machines that cannot have one.

Alternatives already considered

Prior art

AWS KMS, GCP KMS, Azure Key Vault all expose exactly this envelope-encryption pattern. Anthropic already performs client attestation for other reasons — the authenticated session is the trust anchor, and the primitive would sit on top of it.

Context

Self-hosted MSP infrastructure, no hyperscaler dependencies by design, Claude Code running as a service account on a VPS. Happy to expand on the deployment shape if useful.

Proposed Solution

Expose a per-installation, server-held secret that Claude Code can request over its already-authenticated session, and that is never written to disk. Something on the order of:

• a wrap / unwrap pair scoped to the authenticated account and installation ID
• the wrapping key held server-side, never transmitted
• ciphertext stored locally by the user; plaintext exists only in process memory for the lifetime of the session

Effectively a KMS primitive rather than a key delivery mechanism. Users would encrypt their own secrets against it and store the ciphertext wherever they like.

Alternative Solutions

• TPM: unavailable on most VPS instances
• YubiKey / FIDO2: requires physical attachment, impossible on remote hosts
• SGX / TEE: not exposed by common providers; the enclave would still need the same secrets to do useful work
• Remote TPM over a restricted SSH command to a machine that has one: workable, but the existence of the channel is visible in logs and the trust anchor just moves elsewhere
• IMA / binary attestation: root can disable the policy

Priority

High - Significant impact on productivity

Feature Category

CLI commands and flags

Use Case Example

_No response_

Additional Context

_No response_