Summary
Codex Desktop will let a local CLI workflow push unpublished workspace audit content through a third-party proxy/aggregator model route and complete the call, while hard-blocking the exact same class of workflow the instant the destination is a direct provider endpoint. Same machine, same content, same user, same explicit approval. The only variable that changed was the model endpoint.
So whatever policy is actually running here is demonstrably not "user approval required" and not "network allowed or denied." It's a third, undocumented thing that silently discriminates by external model route — and the UI exposes none of it. You ship a sandbox toggle and an approval prompt, the user satisfies both, and the action still dies on a rule nobody can see, configure, or override.
Observed behavior
- Third-party proxy route: request goes through to the model and the call completes. Allowed.
- Direct route to a provider model (Model A): blocked by Codex before command execution.
- Direct route to a model bundled in a separate agent-plan service (Model B): blocked by Codex before command execution.
The standout fact: routing the identical content through a third-party aggregator is allowed, but talking straight to the provider is forbidden. Adding an intermediary makes the request more acceptable to Codex, not less.
Current UI / settings
- Network access: enabled
- Approval policy: on-request
- User explicitly approved sending the workspace audit packet to the selected external model.
Actual behavior
Codex rejects both direct provider routes before execution, citing a message about unpublished workspace content not being sendable to an "untrusted external model service" — after the owner of that content already said yes. There is no surfaced setting, allowlist, or override that lets the user act on their own machine, with their own content, against their own API endpoint. The approval prompt is, in this case, decorative.
Why this matters — the hypocrisy is the whole problem
Codex enables the sandbox by default and wears that as a safety badge: look how careful we are, we sandbox everything. That's the pitch. Then, in this obscure corner, the product does the precise opposite of careful. It takes the supported, sandboxed, explicitly-approved path and breaks it — for no benefit, because the same content sails through a third-party proxy untouched. And when that approved path dies, what's the only way left to get a routine local model-review workflow to run? Turn the sandbox off. danger-full-access. --dangerously-bypass-approvals-and-sandbox. Drop the guardrail entirely.
So the net behavior is: a product that brags about sandboxing-by-default is, in practice, actively herding users into disabling the entire sandbox — trading a single approved outbound call for total, unscoped exposure. It is afraid of the baby toddling one step outside the room, so it picks the baby up and throws it onto the highway. The "safety" feature manufactures a far larger hole than the one it pretends to plug, and it does so in a way the UI never discloses.
That leaves two interpretations, and neither is defensible:
- Codex is privileging proxy/aggregator routes. The third-party proxy is allowed; the direct providers are not. The policy literally nudges users to push private workspace content through more intermediaries to get work done — the opposite of reducing exposure.
- Codex is using the block to push users out of the sandbox. The safe, explicit, approved path doesn't work, so the only remaining option is to bypass the sandbox wholesale. The policy's net effect is to talk users into turning the guardrail off — which is the single worst outcome a "security" feature could possibly produce.
Either way it's security theater that inconveniences the legitimate owner of the content and protects nothing. It doesn't stop a determined user; it punishes the one who tried to do the right thing through the supported path, while blessing the middleman hop and quietly steering everyone toward danger-full-access. A guardrail whose only practical outcomes are "route through more middlemen" or "tear the guardrail down" is not security. It's friction cosplaying as safety, and it leaves users more exposed than having no sandbox messaging at all.
Expected behavior
Pick one and commit to it:
- Enforce a single, documented outbound-content policy consistently across every model route — no silent special cases for proxies vs. direct providers.
- Or expose a visible, per-destination approval / allowlist mechanism for user-owned workspace content, so "yes, send my content to this endpoint" is a real, honorable setting that doesn't force a choice between "give up" and "disable the whole sandbox."
At an absolute minimum: stop letting the UI imply that "network enabled + on-request approval + explicit user yes" is sufficient, when a separate, invisible, non-overridable outbound-model policy is going to veto some destinations anyway — and stop shipping a block whose only escape hatch is danger-full-access. If there's a hidden policy, surface it. If approval can be overruled, say so in the prompt. Don't market sandbox-by-default as safety while engineering the one workflow that makes users tear it down.
Environment
- Codex Desktop: 26.623.12021
- Codex CLI: 0.128.0
- OS: Windows 11
Summary
Codex Desktop will let a local CLI workflow push unpublished workspace audit content through a third-party proxy/aggregator model route and complete the call, while hard-blocking the exact same class of workflow the instant the destination is a direct provider endpoint. Same machine, same content, same user, same explicit approval. The only variable that changed was the model endpoint.
So whatever policy is actually running here is demonstrably not "user approval required" and not "network allowed or denied." It's a third, undocumented thing that silently discriminates by external model route — and the UI exposes none of it. You ship a sandbox toggle and an approval prompt, the user satisfies both, and the action still dies on a rule nobody can see, configure, or override.
Observed behavior
The standout fact: routing the identical content through a third-party aggregator is allowed, but talking straight to the provider is forbidden. Adding an intermediary makes the request more acceptable to Codex, not less.
Current UI / settings
Actual behavior
Codex rejects both direct provider routes before execution, citing a message about unpublished workspace content not being sendable to an "untrusted external model service" — after the owner of that content already said yes. There is no surfaced setting, allowlist, or override that lets the user act on their own machine, with their own content, against their own API endpoint. The approval prompt is, in this case, decorative.
Why this matters — the hypocrisy is the whole problem
Codex enables the sandbox by default and wears that as a safety badge: look how careful we are, we sandbox everything. That's the pitch. Then, in this obscure corner, the product does the precise opposite of careful. It takes the supported, sandboxed, explicitly-approved path and breaks it — for no benefit, because the same content sails through a third-party proxy untouched. And when that approved path dies, what's the only way left to get a routine local model-review workflow to run? Turn the sandbox off.
danger-full-access.--dangerously-bypass-approvals-and-sandbox. Drop the guardrail entirely.So the net behavior is: a product that brags about sandboxing-by-default is, in practice, actively herding users into disabling the entire sandbox — trading a single approved outbound call for total, unscoped exposure. It is afraid of the baby toddling one step outside the room, so it picks the baby up and throws it onto the highway. The "safety" feature manufactures a far larger hole than the one it pretends to plug, and it does so in a way the UI never discloses.
That leaves two interpretations, and neither is defensible:
Either way it's security theater that inconveniences the legitimate owner of the content and protects nothing. It doesn't stop a determined user; it punishes the one who tried to do the right thing through the supported path, while blessing the middleman hop and quietly steering everyone toward
danger-full-access. A guardrail whose only practical outcomes are "route through more middlemen" or "tear the guardrail down" is not security. It's friction cosplaying as safety, and it leaves users more exposed than having no sandbox messaging at all.Expected behavior
Pick one and commit to it:
At an absolute minimum: stop letting the UI imply that "network enabled + on-request approval + explicit user yes" is sufficient, when a separate, invisible, non-overridable outbound-model policy is going to veto some destinations anyway — and stop shipping a block whose only escape hatch is
danger-full-access. If there's a hidden policy, surface it. If approval can be overruled, say so in the prompt. Don't market sandbox-by-default as safety while engineering the one workflow that makes users tear it down.Environment