[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 works
codex: local works, OpenShell fails
opencode: 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, and opencode.
Actual
claude works locally and through OpenShell.
codex works locally, but through OpenShell it repeatedly reconnects and ultimately fails against https://api.openai.com/v1/responses.
opencode works 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 codex shows Credential keys: <none>, but that field alone is probably not diagnostic because claude can 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
- In a direct Anthropic-backed
opencode repro inside the sandbox, the environment still appeared OpenAI-shaped:
OPENAI_API_KEY=openshell:resolve:env:OPENAI_API_KEY
ANTHROPIC_API_KEY was 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:3128 to 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,
claude remains healthy, while codex and opencode still fail only through OpenShell.
Agent-First Checklist
[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
claudeis 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 failsThis does not look like a general sandbox/runtime/network issue. It appears limited to the
codexandopencodeprovider paths.Expected
openshell sandbox create ... --provider ... -- <cli>invocation should also work.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):Failing case 1 (
codex, local works, OpenShell fails):Failing case 2 (
opencode, local works, OpenShell fails):Observed Failure Modes
codexthrough OpenShell:and in a later repro:
opencodethrough OpenShell: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>.--provider codex, the sandbox had:HTTP_PROXY=http://10.200.0.1:3128)OPENAI_API_KEY=openshell:resolve:env:OPENAI_API_KEYopencoderepro inside the sandbox, the environment still appeared OpenAI-shaped:OPENAI_API_KEY=openshell:resolve:env:OPENAI_API_KEYANTHROPIC_API_KEYwas absentThat suggests the
opencodeprovider path may not be switching credential injection based on model family, and thecodexprovider path may not be brokering OpenAI auth correctly.Impact
OpenShell currently works for
claudein this setup, but not forcodexoropencode, 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
Notes
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.clauderemains healthy, whilecodexandopencodestill fail only through OpenShell.Agent-First Checklist