Codex Desktop cannot execute heterogeneous Sol → Terra → Luna routing: OpenAI models are classified as unverified third-party services
What version of the Codex App are you using (From “About Codex” dialog)?
About Codex
What subscription do you have?
Codex Desktop cannot execute heterogeneous Sol → Terra → Luna routing: OpenAI models are classified as unverified third-party services
What platform is your computer?
_No response_
What issue are you seeing?
Summary
I am building a repository-level engineering harness that routes work by capability:
- GPT-5.6 Sol / xhigh: architecture and adversarial verification
- GPT-5.6 Terra / medium: implementation
- GPT-5.6 Luna / medium: bounded mechanical work
The architecture phase using Sol succeeded, but Codex Desktop refused every attempt to hand the approved implementation package to Terra.
The approval layer classified OpenAI Codex Terra as an “unverified external/third-party service”, even after I explicitly authorized access to the private repository and restricted modifications to an exact file allowlist.
A read-only Terra invocation was rejected for the same reason.
Environment
- OS: Windows 11 x64
- Codex Desktop package: 26.707.3748.0
- Bundled Codex CLI: 0.144.0-alpha.4
- Root model: gpt-5.6-sol / xhigh
- Target implementation model: gpt-5.6-terra / medium
- Target batch model: gpt-5.6-luna / medium
- Parent Codex thread ID:
019f2c5a-1885-7341-83df-da08105c29bd
- Time reproduced:
2026-07-11, approximately 17:36–18:00, Asia/Shanghai
Reproduction
- Configure a repository custom agent:
model = "gpt-5.6-terra"
model_reasoning_effort = "medium"
sandbox_mode = "workspace-write"
- From a Sol/xhigh root thread, dispatch a bounded implementation package using:
codex exec
--ignore-user-config
--strict-config
-m gpt-5.6-terra
-c model_reasoning_effort="medium"
-s workspace-write
- Restrict the task to an explicit repository file allowlist.
- Explicitly authorize sending the project code to OpenAI Codex Terra and permit modifications only within that allowlist.
- The execution is rejected before the Terra thread starts.
- Retry with
sandbox=read-only.
- It is rejected again as an unverified external service.
Actual errors
First rejection:
“This would launch an external Codex model in workspace-write mode and send private repository/task contents to an unverified third-party service.”
After explicit user approval:
“This would send private repository contents and task data to an unverified external Codex model service in workspace-write mode; policy explicitly denies private data export to untrusted external destinations even with explicit user approval.”
Read-only retry:
“This read-only Terra thread would still transmit private repository and task contents to an unverified external Codex service.”
Additional limitation
The native subagent/spawn interface does not expose model or reasoning-effort selection. Native child agents inherit the root Sol/xhigh model.
Therefore there is currently no usable route:
- explicit exec is rejected by the approval layer;
- native spawn cannot select Terra or Luna.
The system falls back to same-model Sol subagents, defeating heterogeneous model routing.
Expected behavior
One of the following:
- OpenAI-hosted Codex models such as Terra and Luna should be recognized as trusted OpenAI destinations; or
- explicit user authorization plus an exact repository allowlist should permit the invocation; or
- native custom-agent spawning should expose model, effort, sandbox and role selection.
At minimum, the product should clearly state that heterogeneous model routing is unsupported instead of presenting contradictory approval instructions.
Separate Windows packaging issue
The bundled CLI under:
C:\Program Files\WindowsApps\OpenAI.Codex_...\app\resources\codex.exe
also failed to launch from the tool shell with “Access is denied”.
Copying codex.exe and its matching helper executables to a user-writable temporary directory allowed the Sol read-only architecture invocation to run.
Please treat this as a separate Windows packaged-helper execution issue if necessary.
What steps can reproduce the bug?
Summary
I am building a repository-level engineering harness that routes work by capability:
- GPT-5.6 Sol / xhigh: architecture and adversarial verification
- GPT-5.6 Terra / medium: implementation
- GPT-5.6 Luna / medium: bounded mechanical work
The architecture phase using Sol succeeded, but Codex Desktop refused every attempt to hand the approved implementation package to Terra.
The approval layer classified OpenAI Codex Terra as an “unverified external/third-party service”, even after I explicitly authorized access to the private repository and restricted modifications to an exact file allowlist.
A read-only Terra invocation was rejected for the same reason.
Environment
- OS: Windows 11 x64
- Codex Desktop package: 26.707.3748.0
- Bundled Codex CLI: 0.144.0-alpha.4
- Root model: gpt-5.6-sol / xhigh
- Target implementation model: gpt-5.6-terra / medium
- Target batch model: gpt-5.6-luna / medium
- Parent Codex thread ID:
019f2c5a-1885-7341-83df-da08105c29bd
- Time reproduced:
2026-07-11, approximately 17:36–18:00, Asia/Shanghai
Reproduction
- Configure a repository custom agent:
model = "gpt-5.6-terra"
model_reasoning_effort = "medium"
sandbox_mode = "workspace-write"
- From a Sol/xhigh root thread, dispatch a bounded implementation package using:
codex exec
--ignore-user-config
--strict-config
-m gpt-5.6-terra
-c model_reasoning_effort="medium"
-s workspace-write
- Restrict the task to an explicit repository file allowlist.
- Explicitly authorize sending the project code to OpenAI Codex Terra and permit modifications only within that allowlist.
- The execution is rejected before the Terra thread starts.
- Retry with
sandbox=read-only.
- It is rejected again as an unverified external service.
Actual errors
First rejection:
“This would launch an external Codex model in workspace-write mode and send private repository/task contents to an unverified third-party service.”
After explicit user approval:
“This would send private repository contents and task data to an unverified external Codex model service in workspace-write mode; policy explicitly denies private data export to untrusted external destinations even with explicit user approval.”
Read-only retry:
“This read-only Terra thread would still transmit private repository and task contents to an unverified external Codex service.”
Additional limitation
The native subagent/spawn interface does not expose model or reasoning-effort selection. Native child agents inherit the root Sol/xhigh model.
Therefore there is currently no usable route:
- explicit exec is rejected by the approval layer;
- native spawn cannot select Terra or Luna.
The system falls back to same-model Sol subagents, defeating heterogeneous model routing.
Expected behavior
One of the following:
- OpenAI-hosted Codex models such as Terra and Luna should be recognized as trusted OpenAI destinations; or
- explicit user authorization plus an exact repository allowlist should permit the invocation; or
- native custom-agent spawning should expose model, effort, sandbox and role selection.
At minimum, the product should clearly state that heterogeneous model routing is unsupported instead of presenting contradictory approval instructions.
Separate Windows packaging issue
The bundled CLI under:
C:\Program Files\WindowsApps\OpenAI.Codex_...\app\resources\codex.exe
also failed to launch from the tool shell with “Access is denied”.
Copying codex.exe and its matching helper executables to a user-writable temporary directory allowed the Sol read-only architecture invocation to run.
Please treat this as a separate Windows packaged-helper execution issue if necessary.
What is the expected behavior?
_No response_
Additional information
_No response_
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗