Description
Follow-up from #23614. The get-claude-key.sh chroot fix (AWF 0.25.5) works — the script is copied and the config path is updated. But Claude Code still can't reach the Anthropic API because the squid proxy rejects all connections from inside the chroot.
Environment
- gh-aw CLI: v0.65.1
- AWF container: 0.25.5
- Claude Code CLI: 2.1.87
- Repo: private, GitHub Teams plan
- Runner: ubuntu-latest
Evidence from squid audit logs
The squid proxy receives two types of traffic:
API proxy container (172.30.0.20) — works:
{"client":"172.30.0.20","host":"api.anthropic.com:443","dest":"160.79.104.10:443","method":"CONNECT","status":200,"decision":"TCP_TUNNEL"}
4 successful CONNECT 200 requests.
Claude Code inside chroot (::1 / localhost) — all fail:
{"client":"::1","host":"-","dest":"-:-","method":"-","status":0,"decision":"NONE_NONE","url":"error:transaction-end-before-headers"}
49 failed requests over ~4 minutes (matching Claude Code's 10 retries with exponential backoff, plus background connection attempts).
The connection drops before any HTTP headers are sent. Squid sees a bare TCP connection with no HTTP protocol.
Timeline within the run
get-claude-key.sh copied to chroot ✅
apiKeyHelper path updated in both .claude.json and .claude/settings.json ✅
apiKeySource: "apiKeyHelper" at init ✅
- Claude Code starts making API calls → all hit squid at
::1 → all fail with transaction-end-before-headers
- 10 retries exhausted →
EHOSTUNREACH → exit 1
Possible causes
- IPv6
::1 vs IPv4 127.0.0.1 mismatch — squid might listen on one, Claude Code connects on the other
HTTP_PROXY/HTTPS_PROXY env vars inside chroot might point to wrong address/port after chroot activation
LD_PRELOAD one-shot-token mechanism might interfere with the proxy TLS handshake
- Squid port not accessible from inside the chroot's network namespace
Failed run
https://github.com/usepepper/salsa/actions/runs/23814978435
Download firewall-audit-logs artifact → logs/audit.jsonl for the full squid log.
What works
- API proxy container (
172.30.0.20) successfully reaches api.anthropic.com through squid
get-claude-key.sh exists in chroot at correct path
- Config files updated correctly
- MCP servers (github, safeoutputs) both connect successfully
raw.githubusercontent.com request from API proxy succeeds
Description
Follow-up from #23614. The
get-claude-key.shchroot fix (AWF 0.25.5) works — the script is copied and the config path is updated. But Claude Code still can't reach the Anthropic API because the squid proxy rejects all connections from inside the chroot.Environment
Evidence from squid audit logs
The squid proxy receives two types of traffic:
API proxy container (
172.30.0.20) — works:{"client":"172.30.0.20","host":"api.anthropic.com:443","dest":"160.79.104.10:443","method":"CONNECT","status":200,"decision":"TCP_TUNNEL"}4 successful CONNECT 200 requests.
Claude Code inside chroot (
::1/ localhost) — all fail:{"client":"::1","host":"-","dest":"-:-","method":"-","status":0,"decision":"NONE_NONE","url":"error:transaction-end-before-headers"}49 failed requests over ~4 minutes (matching Claude Code's 10 retries with exponential backoff, plus background connection attempts).
The connection drops before any HTTP headers are sent. Squid sees a bare TCP connection with no HTTP protocol.
Timeline within the run
get-claude-key.shcopied to chroot ✅apiKeyHelperpath updated in both.claude.jsonand.claude/settings.json✅apiKeySource: "apiKeyHelper"at init ✅::1→ all fail withtransaction-end-before-headersEHOSTUNREACH→ exit 1Possible causes
::1vs IPv4127.0.0.1mismatch — squid might listen on one, Claude Code connects on the otherHTTP_PROXY/HTTPS_PROXYenv vars inside chroot might point to wrong address/port after chroot activationLD_PRELOADone-shot-token mechanism might interfere with the proxy TLS handshakeFailed run
https://github.com/usepepper/salsa/actions/runs/23814978435
Download
firewall-audit-logsartifact →logs/audit.jsonlfor the full squid log.What works
172.30.0.20) successfully reachesapi.anthropic.comthrough squidget-claude-key.shexists in chroot at correct pathraw.githubusercontent.comrequest from API proxy succeeds