Symphony Elixir on Codex Cloud: hex.pm 403 + mise can't fetch the pinned toolchain through the proxy

[e-fu]

Trying to run Symphony's Elixir side from a Codex Cloud dispatch hits two proxy walls. The runtime story is more nuanced than "no Elixir in the image" — there's a mise install present, but the network constraints make it unusable for Symphony's current pin. Sharing the transcript in case the Symphony team has guidance, and in case anyone from OpenAI watching this can route the hex.pm allowlist ask to the Codex Cloud env team.

What's in the Codex Cloud image (verified):

• mise is present with Erlang 27.1.2 and Elixir 1.18.3-otp-27 pre-installed at /root/.local/share/mise/installs/{erlang,elixir}/...
• Not on default PATH, so naive mix ... fails with command not found — but the binaries are there.

What fails:

1. Symphony's elixir/mise.toml pins Erlang 28 / Elixir 1.19.5-otp-28. After mise trust /workspace/symphony/elixir/mise.toml, mise install can't reach the toolchain assets through the configured proxy.

2. Fallback to the pre-installed 1.18.3-otp-27 also fails:

   PATH=/root/.local/share/mise/installs/erlang/27.1.2/bin:\
   /root/.local/share/mise/installs/elixir/1.18.3-otp-27/bin:$PATH \
   MIX_HOME=/root/.local/share/mise/installs/elixir/1.18.3-otp-27/.mix \
   mix deps.get --all
   # → Mix can't install Hex; hex.pm returns 403 Forbidden through the proxy.

So even with a working toolchain on disk, mix deps.get is blocked at the registry layer. No repo files change, no commit, no PR — the agent has nothing it can ship.

Per OpenAI's Codex Cloud network docs, the "Common dependencies" preset reaches crates.io / npmjs.com / pypi.org but hex.pm is not in the preset. That single allowlist gap is the load-bearing constraint for every Elixir delegation.

Questions:

1. Is Symphony's Elixir runner intended primarily for self-hosted Codex CLI dispatch (Podman, your own image with hex mirrored), with hosted Codex Cloud as a non-goal for Elixir today?
2. Is the Erlang 28 / Elixir 1.19.5 pin in elixir/mise.toml a hard floor, or would Symphony work against the image's pre-installed 1.18.3-otp-27 (assuming the hex.pm proxy issue were resolved)?
3. To OpenAI folks watching: can hex.pm be added to the Codex Cloud "Common dependencies" preset? That alone unblocks the entire Elixir delegation path, including Symphony's.

Happy to share the full agent transcript if useful.

[sylvesterkaczmarek]

Current Symphony main still pins Erlang 28 and Elixir 1.19.5-otp-28, so I wouldn't treat the preinstalled Erlang 27 / Elixir 1.18 environment as the supported target just because it happens to be available in the image.

The bigger blocker is hex.pm. If mix deps.get cannot reach Hex through the Codex Cloud network policy, there isn't really a Symphony-side configuration that can fix the full build. You either need that dependency endpoint allowed, pre-baked dependencies/artifacts, or an environment you control.

So for now I'd use a self-hosted Codex CLI/container with the pinned toolchain and Hex access for the Elixir runner. Adding hex.pm to the hosted dependency/network path is ultimately a Codex Cloud platform request rather than something Symphony can solve inside the repo.