-
Notifications
You must be signed in to change notification settings - Fork 354
Description
[BUG] codex and opencode providers fail through OpenShell while claude succeeds
Agent Diagnostic
Investigated before filing. Reproduced with a teammate. Verified the same CLIs succeed locally outside OpenShell, then fail only when launched through OpenShell sandboxes. Also verified claude is a working control case in the same environment.
Description
We are seeing a selective provider brokering/injection failure in OpenShell:
claude: local works, OpenShell workscodex: local works, OpenShell failsopencode: local works, OpenShell fails
This does not look like a general sandbox/runtime/network issue. It appears limited to the codex and opencode provider paths.
Expected
- If the local CLI is already authenticated and can run successfully outside OpenShell, the equivalent
openshell sandbox create ... --provider ... -- <cli>invocation should also work. - Provider credential brokering should behave consistently across
claude,codex, andopencode.
Actual
claudeworks locally and through OpenShell.codexworks locally, but through OpenShell it repeatedly reconnects and ultimately fails againsthttps://api.openai.com/v1/responses.opencodeworks locally, but through OpenShell it hangs after its one-time database migration step.
Minimal Reproduction
Control case (claude, works):
claude --dangerously-skip-permissions -p "say hello"
openshell sandbox create --name claude-probe \
--provider claude \
--auto-providers \
--policy configs/policies/default-deny.yaml \
--no-keep --no-tty -- \
claude --dangerously-skip-permissions -p "say hello"Failing case 1 (codex, local works, OpenShell fails):
codex exec --dangerously-bypass-approvals-and-sandbox "say hello"
openshell sandbox create --name codex-probe \
--provider codex \
--auto-providers \
--policy configs/policies/default-deny.yaml \
--no-keep --no-tty -- \
codex exec --dangerously-bypass-approvals-and-sandbox "say hello"Failing case 2 (opencode, local works, OpenShell fails):
opencode auth login
opencode run --model anthropic/claude-sonnet-4-20250514 "say hello"
openshell sandbox create --name opencode-probe \
--provider opencode \
--auto-providers \
--policy configs/policies/default-deny.yaml \
--no-keep --no-tty -- \
opencode run --model anthropic/claude-sonnet-4-20250514 "say hello"Observed Failure Modes
codex through OpenShell:
Reconnecting... 1/5 (unexpected status 401 Unauthorized: Missing bearer or basic authentication in header, url: https://api.openai.com/v1/responses, ...)
and in a later repro:
Reconnecting... 1/5 (stream disconnected before completion: error sending request for url (https://api.openai.com/v1/responses))
opencode through OpenShell:
Created sandbox: opencode-probe
Performing one time database migration, may take a few minutes...
sqlite-migration:done
Database migration complete.
and then it hangs indefinitely.
Additional Diagnostics
openshell provider get codexshowsCredential keys: <none>, but that field alone is probably not diagnostic becauseclaudecan still work while also showing<none>.- In a direct env probe inside a sandbox launched with
--provider codex, the sandbox had:- proxy vars set (for example
HTTP_PROXY=http://10.200.0.1:3128) OPENAI_API_KEY=openshell:resolve:env:OPENAI_API_KEY
- proxy vars set (for example
- In a direct Anthropic-backed
opencoderepro inside the sandbox, the environment still appeared OpenAI-shaped:OPENAI_API_KEY=openshell:resolve:env:OPENAI_API_KEYANTHROPIC_API_KEYwas absent
That suggests the opencode provider path may not be switching credential injection based on model family, and the codex provider path may not be brokering OpenAI auth correctly.
Impact
OpenShell currently works for claude in this setup, but not for codex or opencode, even when both CLIs are already known-good locally. That blocks multi-agent/runtime integrations that rely on OpenShell to launch different coding agents interchangeably.
Environment
- OS: macOS 26.3.1 (build 25D771280a), Apple Silicon
- Kernel: Darwin 25.3.0 arm64
- OpenShell: 0.0.11
Notes
- We separately fixed a local policy issue requiring the internal proxy endpoint
10.200.0.1:3128to be allowed in our bundled policies. That was necessary for sandbox egress, but it does not resolve this provider-specific behavior. - After that proxy fix,
clauderemains healthy, whilecodexandopencodestill fail only through OpenShell.
Agent-First Checklist
- I pointed my agent at the repo and had it investigate this issue
- I loaded relevant local context and repro logs before filing
- My agent could not resolve this — the diagnostic above explains why