Add containerized Claude Code script with host credential proxy

[ElleNajt]

Status: This appears to work -- no credentials enter the container, but the containerized Claude starts up and works as if they were there because of the proxy on the host that adds them. However I'm still learning about software engineering, so please scrutinize it before use! I would also love feedback before I start using it too much. :)

Claude and I worked out how to adjust the packets by writing this transparent proxy first: https://gist.github.com/ElleNajt/04db039b7721b82b2a8224e1a2ccc81d

Description:

This runs Claude Code in a Docker container with dummy OAuth tokens. Host proxy intercepts API calls and replaces dummy tokens with real credentials.

This addresses this issue that I opened.

Components:

• claudebox: Starts proxy and container, mounts working directory as /workspace
• claude-auth-proxy.py: HTTP proxy that swaps dummy tokens for real ones
• get-claude-credentials.sh: Retrieves credentials from macOS keychain
• Container config: .claude.json only hasCompletedOnboarding flag, ~/.claude/.credentials.json only has dummy tokens, CLAUDE.md only optionally passed through

Currently tested on macOS only (using security command for keychain access).

🤖 Generated with Claude Code

[ant-kurt]

Hi @ElleNajt - this is a really interesting approach, thank you for sharing. I've been thinking about porting the devcontainer over to docker-compose and offering a squid proxy, wonder if we can incorporate this dynamic credential replacement into it.

If we don't go that route, I'll circle back with the team to see how we want to start to separate out our devcontainer configs (probably offering a few different flavors).

[ElleNajt]

over to docker-compose and offering a squid proxy, wonder if we can incorporate this dynamic credential replacement into it.

Offering a single proxy instead of spawning a proxy for each sandboxed Claude process (like the claudebox script in this PR is doing) would make sense.

As would dropping the requirement that the python script runs on the host machine - running it in a container too makes sense to me, just to avoid managing environments. (Although it is very lightweight, just uses stdlib, and doesn't really need it's own container, so at least for my personal computing use cases I'd prefer to keep it running on the host machine.)