docs: why no Centaur tool can run in an Atrium sandbox#557
Merged
Conversation
Writes up the investigation from wiring atrium-preview (#547, #548) — the first tool meant to actually execute in an Atrium sandbox, and so the first to hit this. Two correct designs disagree. Upstream's iron-proxy is a credential injector whose default posture is domains:["*"]; tools resolve deps from PyPI at run time via `uvx --from`, and that IS the intended design. Atrium sets console.enabled for per-user BYO credentials, which flips the proxy to managed mode where the allowlist is per-principal and deny-by-default. PyPI was never re-permitted, so every tool starves. Hence TOOL_ALLOWLIST: "none". The load-bearing finding, read from the running console (app/models/proxy.rb, merge_proxy_policy): allowlist_domains += domains_from_rules(config) allowlist = allowlist_domains.uniq.sort The effective allowlist is the UNION of baseline domains and hosts from granted credentials — additive, not replacing. So adding pypi.org to the baseline cannot remove chatgpt.com. That was the one thing worth verifying before touching prod, and the fear was unfounded. There is already a precedent for a credential-less allowlist entry: CODEX_ACCESS_TOKEN_PER_USER_FRAGMENT allowlists chatgpt.com and injects nothing. Confirmed live: the prod baseline is ["chatgpt.com"], the sync payload carries secrets:[] — so chatgpt.com reaches sandboxes via the baseline, and a prod sandbox's entire egress surface is chatgpt.com. Also records that a zero-dep tool does NOT dodge this (uvx needs hatchling from PyPI — probed in a live sandbox), that the depcache uv tier is 252K and empty, and three claims made during the build that were wrong, including the retired iron-proxy.md's assertion that top-level [tool.centaur] hosts widens egress (it is only a default for secrets' hosts). The remaining decision is policy, not mechanism: should an Atrium sandbox be able to reach PyPI at all?
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Design note from wiring
atrium-preview(#547, #548). No code — a written-up investigation plus a decision to make.The finding: two correct designs disagree. Upstream's iron-proxy is a credential injector whose default posture is
domains: ["*"]; tools resolve deps from PyPI at run time viauvx --from, and that is the intended upstream design. Atrium setsconsole.enabled: truefor per-user BYO credentials, which flips the proxy to managed mode where the allowlist is per-principal and deny-by-default. PyPI was never re-permitted — so every tool starves. That's whatTOOL_ALLOWLIST: "none"has been quietly encoding.The allowlist semantics (the thing worth verifying before touching prod), read from the running console —
app/models/proxy.rb,merge_proxy_policy:Effective allowlist = union(baseline domains, hosts from granted credentials). Additive, not replacing — so adding
pypi.orgto the baseline cannot removechatgpt.com. My earlier fear that this could denyapi.openai.comand take down every agent turn was unfounded.There's already a precedent for a credential-less allowlist entry —
CODEX_ACCESS_TOKEN_PER_USER_FRAGMENTallowlistschatgpt.comand injects nothing. Confirmed live: the prod baseline is["chatgpt.com"]and the sync payload carriessecrets: [], so chatgpt.com reaches sandboxes via the baseline. A prod sandbox's entire egress surface ischatgpt.com.Also recorded, so nobody re-derives them:
uvxneedshatchlingfrom PyPI (probed in a live prod sandbox).httpx/richinto system python;uvxbuilds an isolated venv and can't see them.iron-proxy.md's assertion that top-level[tool.centaur] hostswidens egress. It's only a default for secrets' hosts.The decision is policy, not mechanism: should an Atrium sandbox be able to reach PyPI at all? If yes, option A is a small, non-destructive, in-architecture change. If no, the honest conclusion is that the uvx-based tool mechanism can't work here and
TOOL_ALLOWLIST: "none"should stay — with the 78 upstream tools dead by choice rather than by accident.The note separates verified (source + live prod) from assumed at the bottom. Nothing here is deployed or changed.