claude-code - 💡(How to fix) Fix Improve sandbox support for erlang / elixir [1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#55000Fetched 2026-05-01 05:48:52
View on GitHub
Comments
1
Participants
2
Timeline
4
Reactions
0
Author
Timeline (top)
labeled ×3commented ×1

Claude Code's web sandbox is a great experience for Node, Python, Go, and Ruby projects (toolchains preinstalled, package managers reach the network). For Erlang/Elixir projects it is currently unworkable without session-by-session re-derivation. Two problems compound:

Error Message

~5–10 minutes of trial-and-error every fresh session: source build needs `upstream connect error or disconnect/reset before headers. retried and

→ 502 Bad Gateway "upstream connect error..."

Root Cause

Claude Code's web sandbox is a great experience for Node, Python, Go, and Ruby projects (toolchains preinstalled, package managers reach the network). For Erlang/Elixir projects it is currently unworkable without session-by-session re-derivation. Two problems compound:

Fix Action

Fix / Workaround

openai/codex#10502 reports the identical class of failure on a different sandbox vendor, with the same recommended-but-unworkable "use a different mirror" workaround, so this is a general property of MITM-egress sandboxes and not specific to Claude Code's infrastructure.

What would help In rough priority order: Preinstall Erlang/OTP and Elixir at recent versions in the web sandbox image (matching whatever versioning policy other languages get). Even one current otp-27 / 1.18 pair would cover most projects. Make the egress proxy accept Erlang's TLS fingerprint, or expose a documented TLS-fingerprint-stable HTTP egress that :httpc can use. Failing the above, document the limitation prominently in the web-sandbox docs — including the fact that "use a Hex mirror" is not a workaround on this proxy. As-is, agents waste a lot of tokens trying every Mix flag before discovering the proxy is the issue. Optionally, ship a mix-via-curl shim or a sandbox-aware setup-beam that pre-fetches deps via curl into the on-disk Hex cache before falling back to :httpc. Environment Claude Code web sandbox, Ubuntu 24.04 LTS x86_64 BEAM not preinstalled; verified after manual install of OTP 27.2 + Elixir 1.18.1. curl 8.5.0 works for all probed HTTPS hosts. :httpc returns 502/503 for all probed HTTPS hosts.

RAW_BUFFERClick to expand / collapse

Preflight Checklist

  • I have searched existing requests and this feature hasn't been requested yet
  • This is a single feature request (not multiple features)

Problem Statement

Summary

Claude Code's web sandbox is a great experience for Node, Python, Go, and Ruby projects (toolchains preinstalled, package managers reach the network). For Erlang/Elixir projects it is currently unworkable without session-by-session re-derivation. Two problems compound:

1. Toolchain is not preinstalled

erl, elixir, and mix are not on PATH. The Ubuntu 24.04 base ships an elixir package at 1.14, which is too old for any project pinning a recent .tool-versions (1.17+). Installing a current BEAM costs an agent ~5–10 minutes of trial-and-error every fresh session: source build needs -dev headers (apt is the only path); precompiled OTP from builds.hex.pm works but isn't well-known.

2. Erlang's TLS is silently blocked by the egress proxy

This is the bigger one. The sandbox's MITM egress (O=Anthropic; CN=sandbox-egress-production TLS Inspection CA) accepts curl's TLS handshake — every https://... curl request returns 200 — but returns 502 Bad Gateway / 503 Service Unavailable on every HTTPS host when the client is Erlang's :httpc. Verified against:

  • https://repo.hex.pm/...
  • https://hex.pm/api/...
  • https://cdn.jsdelivr.net/hex/... (Hex's official jsDelivr mirror)
  • https://api.github.com/...
  • https://www.google.com/

The proxy returns the Envoy-style body upstream connect error or disconnect/reset before headers. retried and the latest reset reason: connection termination. It is not host-specific and not fixable from Mix configuration — HEX_MIRROR, HEX_CACERTS_PATH, HEX_UNSAFE_HTTPS=1, HEX_HTTP_TIMEOUT/HEX_HTTP_RETRIES, forcing TLS 1.2 vs 1.3, custom User-Agent and Connection: close headers, and max_keep_alive_length: 0 all yield the same 5xx. The proxy distinguishes Erlang's TLS hello (likely JA3/JA4 fingerprint) from curl's and refuses to relay it upstream.

This breaks every Mix command that touches the network: mix local.hex --force, mix local.rebar --force, mix deps.get, mix hex.search, mix hex.info, mix archive.install hex …. The documented Hex mirror list (https://hex.pm/docs/mirrors) doesn't help — all three endorsed mirrors are blocked the same way.

openai/codex#10502 reports the identical class of failure on a different sandbox vendor, with the same recommended-but-unworkable "use a different mirror" workaround, so this is a general property of MITM-egress sandboxes and not specific to Claude Code's infrastructure.

Repro

# In a fresh Claude Code web session, on Linux:
curl -fsSL -o /tmp/otp.tgz \
  https://builds.hex.pm/builds/otp/ubuntu-24.04/OTP-27.2.tar.gz
mkdir -p /opt/erlang && tar -xzf /tmp/otp.tgz -C /opt/erlang
( cd /opt/erlang/OTP-27.2 && ./Install -minimal /opt/erlang/OTP-27.2 )

curl -fsSL -o /tmp/elixir.zip \
  https://github.com/elixir-lang/elixir/releases/download/v1.18.1/elixir-otp-27.zip
mkdir -p /opt/elixir && unzip -q /tmp/elixir.zip -d /opt/elixir
export PATH=/opt/erlang/OTP-27.2/bin:/opt/elixir/bin:$PATH

# This is what fails:
mix local.hex --force
# → ** (Mix) httpc request failed with: ... TLS client ... key_usage_mismatch ...

# Even bypassing TLS verification:
HEX_UNSAFE_HTTPS=1 mix local.hex --force
# → 502 Bad Gateway "upstream connect error..."

# But curl to the same URL works:
curl -fsSI https://builds.hex.pm/installs/1.18.0/hex.ez | head -1
# → HTTP/2 200

### Proposed Solution

What would help
In rough priority order:
Preinstall Erlang/OTP and Elixir at recent versions in the web
sandbox image (matching whatever versioning policy other languages
get). Even one current otp-27 / 1.18 pair would cover most projects.
Make the egress proxy accept Erlang's TLS fingerprint, or expose
a documented TLS-fingerprint-stable HTTP egress that :httpc can use.
Failing the above, document the limitation prominently in the
web-sandbox docs — including the fact that "use a Hex mirror" is not
a workaround on this proxy. As-is, agents waste a lot of tokens
trying every Mix flag before discovering the proxy is the issue.
Optionally, ship a mix-via-curl shim or a sandbox-aware
setup-beam that pre-fetches deps via curl into the on-disk Hex
cache before falling back to :httpc.
Environment
Claude Code web sandbox, Ubuntu 24.04 LTS x86_64
BEAM not preinstalled; verified after manual install of OTP 27.2 +
Elixir 1.18.1.
curl 8.5.0 works for all probed HTTPS hosts.
:httpc returns 502/503 for all probed HTTPS hosts.

### Alternative Solutions

_No response_

### Priority

High - Significant impact on productivity

### Feature Category

Other

### Use Case Example

_No response_

### Additional Context

_No response_

extent analysis

TL;DR

The most likely fix is to update the egress proxy to accept Erlang's TLS fingerprint or provide a documented TLS-fingerprint-stable HTTP egress.

Guidance

  • Investigate updating the egress proxy to accept Erlang's TLS fingerprint, potentially by whitelisting the JA3/JA4 fingerprint of Erlang's :httpc client.
  • Consider providing a separate, documented HTTP egress that is compatible with Erlang's TLS implementation, allowing :httpc to bypass the problematic proxy.
  • As a temporary workaround, explore using a mix-via-curl shim or a sandbox-aware setup-beam script that pre-fetches dependencies via curl into the on-disk Hex cache before falling back to :httpc.
  • Document the current limitation prominently in the web-sandbox documentation to avoid wasting agent tokens on futile attempts to use Mix with the current proxy setup.

Example

No code example is provided, as the issue is related to infrastructure and proxy configuration rather than code.

Notes

The solution may require coordination with the Claude Code infrastructure team to update the egress proxy or provide an alternative egress path. Additionally, the workaround using curl may have performance implications and should be carefully evaluated.

Recommendation

Apply a workaround, such as using a mix-via-curl shim or a sandbox-aware setup-beam script, until a more permanent solution can be implemented, as updating the egress proxy may require significant infrastructure changes.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

claude-code - 💡(How to fix) Fix Improve sandbox support for erlang / elixir [1 comments, 2 participants]