git credentials

[yoobi]

Hello, and great work on this project! I'm exploring it and set up a docker case.

How are git credentials meant to be handled inside a docker case? Cloning a private repo or pushing needs a token or SSH key, but from docker inspect the credential seeds only cover Claude and OpenCode — ~/.gitconfig, ~/.git-credentials and ~/.ssh aren't mounted or seeded, and the container's home isn't persisted, so anything I configure inside is lost on the next recreate.

Is there a supported way to inject git credentials per case that I've missed? If not, would extending the cred-seed list to cover git be something you'd consider? Happy to open a PR if it's welcome.

Thanks!

[Ark0N]

Hey, thanks, and good catch: you read the code right. The cred-seed list (CRED_STORES in src/docker-hosts.ts) covers the agent CLIs but nothing for git, so there's currently no supported way to get git credentials into a docker case. A PR would be very welcome.

What you can do today

Two stopgaps:

1. The docker host record has an escape hatch: extraCreateArgs (not in the UI yet, set it via the API or by editing ~/.codeman/docker-hosts.json) passes extra args to docker create, so you can bind-mount what you need read-only:

   "extraCreateArgs": ["-v", "/home/you/.gitconfig:/home/agent/.gitconfig:ro",
                       "-v", "/home/you/.ssh:/home/agent/.ssh:ro"]
   

   Container HOME is /home/agent and the container runs as your host uid, so permissions line up. For SSH you can also forward the agent instead of mounting keys: -v <literal SSH_AUTH_SOCK path>:/ssh-agent plus -e SSH_AUTH_SOCK=/ssh-agent (no env expansion there, use the literal socket path). Changing these makes the next launch detect config drift and offer to recreate the container, so it applies cleanly.

2. The workspace is a plain host directory bind-mounted at the same absolute path, so you can always run git push / git pull from a host shell in that directory with your normal host credentials, and let the in-container agent do everything else.

How I'd shape the PR

The extension point is exactly the one you found: new entries in CRED_STORES, flowing through resolveDockerCredentialArtifacts(). Everything there is existsSync-gated, and the sealed profile (mountCredentials: false) must keep excluding git creds too.

• ~/.gitconfig: seed-copy (RO mount + cp), same shape as the other stores, so in-container edits never write back to the host. Note the current entries are all directories; a HOME-root file may need a small tweak in the copy step.
• ~/.ssh: please don't copy private keys into the container filesystem. Full-image export uses docker commit, and anything cp'd into the container home ends up in the exported image. My preference: seed only known_hosts and config, and handle keys via SSH agent forwarding (bind-mount the host's auth socket, export SSH_AUTH_SOCK into the in-container session). Keys never touch the container layer and revocation is instant. The socket path isn't a secret, so it's fine as a create-time env (actual secrets never are: docker inspect shows them, which is why the existing rule is no -e for secrets).
• ~/.git-credentials: seed-copy works mechanically, but it's plaintext tokens, so it has the same export concern as SSH keys. If it goes in, it should be scrubbed on full-image export or flip the bundle's secret-free flag.
• Worth adding in the same pass: ~/.config/gh (the gh CLI token). Agents use gh constantly and it fits the existing store shape.

If you open the PR: docs/docker-cases.md is where the user-facing credential story is documented, and the existing docker-hosts tests show the pattern to extend. Happy to review!