notes on my AI sandbox containers

overview

claude-code and gemini-cli are very handy, but i don’t want them running roughshod over my system. sticking these things in containers that can just do their thing and stay put in the local directory seems like the move. then git can save my ass.

my setup notes as follows.

claude-code

claude-code sandbox dockerfile

claude authentication notes

claude-code is pretty slick about allowing you to use your claude account to authenticate vs. using the environment variables so there’s a little bit of chicanery involved in snarfing the credentials. to help this out in the future i just mount the necessary elements when i invoke the claude via the sandbox.

relevant zsh wrapper function

# this uses the claude subscription auth mounted at the following mountpoints to
# let me run claude-code in a docker container while not having to re-auth every
# time. these may need to be periodically refreshed.  also, this is quite
# dependent on the path structure of my container.
function claude-sandbox() {
  docker run -it --rm \
    -v $(pwd):/app:rw \
    -v ${HOME}/.credentials/claude:/home/claude/.claude:rw \
    -v ${HOME}/.claude.json:/home/claude/.claude.json:rw \
    --net=host claude-sandbox
}

gemini-cli

gemini-cli sandbox dockerfile

google seems to have some issues with the use of the standard google auth process. additionally, if you attempt to cache the auth, you run into different issues with them wanting you to point at a google cloud project. which, is a bit of a hassle.

relevant zsh wrapper function

# google seems to want all of my standard google auth biz to be coupled to a
# google cloud project. f*ck that.  i guess i'll just leak the environment
# variable.
function gemini-sandbox() {
  docker run -it --rm \
    -e GEMINI_API_KEY="${GEMINI_API_KEY}" \
    -v $(pwd):/app:rw \
    --net=host  gemini-sandbox
}