Follow-up from the review of #7, plus a real incident during its rollout.
The --gh feature ships in two halves: the host side (run.sh — sidecar, CA mount, env) is always current because it runs from the checkout, while the image side (entrypoint.sh running update-ca-certificates to merge the proxy CA into the OS trust store) is baked at docker build. When the image is older than the wrapper, you get a silent split-brain: the sidecar comes up, Node works (via NODE_EXTRA_CA_CERTS), and gh (Go), git and curl (OpenSSL) all fail TLS with certificate signed by unknown authority / certificate signer not trusted.
What happened
A maintainer rebuilt claude-code:local from a stale copy of the repo. The resulting image's entrypoint had no CA-install block, so /etc/ssl/certs/ca-certificates.crt was never rewritten (0 Caddy certs in the bundle) and an agent burned real time diagnosing TLS errors from three different tools. The diagnosis was correct but the failure mode gave no hint at the cause.
1. Detect version skew
Stamp a build identifier into the image (e.g. /etc/claude-docker-build with the git describe/sha at build time) and have run.sh warn when the image predates the wrapper — especially when --gh is passed, since that is where the mismatch bites. A warning is worth more than the current silence: the CA-install code cannot warn about its own absence.
2. Make CA-install failure loud
entrypoint.sh currently warns and continues if update-ca-certificates fails, so a session limps on with every GitHub TLS handshake failing while gh believes it is authenticated. Either fail setup, or make the warning explicitly name --gh, the consequence (all GitHub TLS will fail), and the workaround (SSL_CERT_FILE / GIT_SSL_CAINFO, or --gh-direct).
Workaround for the meantime
Per-command: SSL_CERT_FILE=/usr/local/share/ca-certificates/claude-docker-gh-proxy.crt for gh (Go honours it), GIT_SSL_CAINFO=... for git (libcurl).
Follow-up from the review of #7, plus a real incident during its rollout.
The
--ghfeature ships in two halves: the host side (run.sh— sidecar, CA mount, env) is always current because it runs from the checkout, while the image side (entrypoint.shrunningupdate-ca-certificatesto merge the proxy CA into the OS trust store) is baked atdocker build. When the image is older than the wrapper, you get a silent split-brain: the sidecar comes up, Node works (viaNODE_EXTRA_CA_CERTS), andgh(Go),gitandcurl(OpenSSL) all fail TLS withcertificate signed by unknown authority/certificate signer not trusted.What happened
A maintainer rebuilt
claude-code:localfrom a stale copy of the repo. The resulting image's entrypoint had no CA-install block, so/etc/ssl/certs/ca-certificates.crtwas never rewritten (0 Caddy certs in the bundle) and an agent burned real time diagnosing TLS errors from three different tools. The diagnosis was correct but the failure mode gave no hint at the cause.1. Detect version skew
Stamp a build identifier into the image (e.g.
/etc/claude-docker-buildwith the git describe/sha at build time) and haverun.shwarn when the image predates the wrapper — especially when--ghis passed, since that is where the mismatch bites. A warning is worth more than the current silence: the CA-install code cannot warn about its own absence.2. Make CA-install failure loud
entrypoint.shcurrently warns and continues ifupdate-ca-certificatesfails, so a session limps on with every GitHub TLS handshake failing whileghbelieves it is authenticated. Either fail setup, or make the warning explicitly name--gh, the consequence (all GitHub TLS will fail), and the workaround (SSL_CERT_FILE/GIT_SSL_CAINFO, or--gh-direct).Workaround for the meantime
Per-command:
SSL_CERT_FILE=/usr/local/share/ca-certificates/claude-docker-gh-proxy.crtforgh(Go honours it),GIT_SSL_CAINFO=...for git (libcurl).