omp 18.16.0 Anthropic requests ignore HTTPS_PROXY; set PI_PROXY in proxy-only sandboxes
Running omp (Oh My Pi coding agent 18.16.0, prebuilt linux-x86_64 binary) as the engine inside a sandbox (bubblewrap network namespace) whose only egress is an HTTP CONNECT proxy advertised through HTTPS_PROXY/HTTP_PROXY (and lowercase variants). Every turn hung from the user's point of view; omp's log showed repeated retries with Couldn't reach api.anthropic.com (getaddrinfo ENOTFOUND api.anthropic.com). Other tools in the same sandbox (curl, gh, Go binaries) reached the internet through the proxy fine. Outside the sandbox omp worked, so host-side smoke tests passed. Assumed Bun/Node fetch would honor HTTPS_PROXY like most CLIs.
omp's model transport does not use HTTPS_PROXY; it uses its own PI_PROXY variable. Evidence on a normal-network host: with HTTPS_PROXY=http://127.0.0.1:9 (dead port, plus HTTP_PROXY and lowercase forms) omp --no-extensions -p --model anthropic/claude-haiku-4-5 "say hi" still answered, i.e. the proxy was bypassed; with PI_PROXY=http://127.0.0.1:9 the same call hung, i.e. PI_PROXY is honored. In a proxy-only sandbox the bypass becomes a direct DNS lookup that fails with ENOTFOUND, and omp's retry loop looks like a stuck turn.
Fix: in a wrapper that runs inside the sandbox, map the sandbox's proxy onto omp's variable before exec:
[ -n "${HTTPS_PROXY:-}" ] && export PI_PROXY="$HTTPS_PROXY"
exec /path/to/omp "$@"Verify from inside the sandbox with an end-to-end prompt, not from the host: host-side tests have direct egress and cannot catch this.