[FEATURE] Pass a token into apiKeyHelper to authenticate an API key request

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

I run Claude Code in my own sandbox (a firejail profile). I would like to make my API key unreadable by CC or any processes it spawns, yet still allow CC to get access to it by invoking the apiKeyHelper.

I want a full grep of the filesystem exposed to CC to not contain the key. I also don't want to expose something (eg a socket) that could be accessed via prompt injection to access the key.

Proposed Solution

I'm assuming Linux here.

• claude accepts a command-line option eg --api-key-fd=<N>
• on startup, it reads a token out of that file descriptor and stores it in memory
• after forking for apiKeyHelper, it creates a pipe, writes the token into it, and lets the exec'ed process inherit the read end.

The idea is that the apiKeyHelper script (still running inside the external sandbox) would read the secret and write it to a unix domain socket inside the sandbox, connected to an auth helper script running outside the sandbox. The auth helper script would verify the secret and send the API key through the socket. The apiKeyHelper script would then send that to its stdout as usual. claude itself would just need to arrange for the helper script to inherit the fd containing the token, though.

Alternative Solutions

permissions.deny doesn't always work, and isn't guaranteed by an external sandbox.

sandbox.credentials.files: deny works but requires using the internal sandbox, which interferes with some things and is a larger trust boundary.

CLAUDE_CODE_SUBPROCESS_ENV_SCRUB defends against certain env var communication mechanisms, but env vars are still readable from /proc. Our clever prompt-injector could set up a daemon to grab the environment of the apiKeyHelper when it runs.

A --token=<XYZ> command-line parameter would be readable from /proc/*/cmdline. Same problem as env vars. Maybe there's a way to scrub this, or an env var, on startup before any compromised actions happen? It seems shaky to me.

Arguably, an fd or the process's memory could be snooped by a rogue Bash script, but those require PTRACE_MODE_ATTACH and so are easily preventable (and firejail does so by default).

I think https://github.com/anthropics/claude-code/issues/77084 is a similar but bigger request, but I can't understand exactly what it's saying and it's a bit too AI-written for me to get into my brain.

Priority

Medium - Would be very helpful

Feature Category

Other

Use Case Example

I'm using claude. This is a security feature. I don't want to leak my API key, and I'm using an external sandbox to wall off everything I can. I do allow some (well, most) network access.

Additional Context

_No response_