What are you trying to accomplish?
Use OpenCodex as a quota supplement while retaining Codex App capabilities such as creating, listing, and updating scheduled automations.
What prevents this today?
In a Codex Desktop task, native OpenAI turns can use the Codex App automation workflow. After switching the task to an OpenCodex-routed non-OpenAI provider/model, the same automation workflow becomes unavailable or the model reports that the automation command/tool is not available. This was observed on macOS Apple Silicon with OpenCodex 2.15.1; please retest on current 2.25.0.
This report is about Codex App automation capability, not a provider API key or account problem. The exact user-facing symptom can vary by routed provider: the automation tool may be absent from the model-visible tool surface, or a request may fail after the tool is discovered.
What should OpenCodex do?
OpenCodex should make this boundary explicit and safe:
- If a routed model can execute Codex App automation tools, preserve and route the capability correctly.
- If it cannot, expose a capability flag in the generated catalog and prevent the UI/model from silently attempting the operation.
- Never report an automation as created or updated unless the native Codex App automation runtime confirms the write.
- Prefer a clear fallback to a native task/model for automation operations.
Example usage or interface
Native Codex task/model:
Ask: create a daily automation
Expected: the Codex App automation flow is callable
OpenCodex-routed task/model:
Ask: create the same daily automation
Observed: automation management is unavailable or the tool is not callable
Alternatives or workarounds
Use a native OpenAI model in a separate task for automation management, and use OpenCodex-routed models only for ordinary coding/research turns. This workaround is safe but makes it easy to lose the boundary unless the UI communicates it.
Additional context
Related compatibility work:
The report contains no keys, tokens, OAuth data, task IDs, local paths, or personal data. A sanitized event trace can be provided if maintainers need a minimal reproduction.
Checks
What are you trying to accomplish?
Use OpenCodex as a quota supplement while retaining Codex App capabilities such as creating, listing, and updating scheduled automations.
What prevents this today?
In a Codex Desktop task, native OpenAI turns can use the Codex App automation workflow. After switching the task to an OpenCodex-routed non-OpenAI provider/model, the same automation workflow becomes unavailable or the model reports that the automation command/tool is not available. This was observed on macOS Apple Silicon with OpenCodex 2.15.1; please retest on current 2.25.0.
This report is about Codex App automation capability, not a provider API key or account problem. The exact user-facing symptom can vary by routed provider: the automation tool may be absent from the model-visible tool surface, or a request may fail after the tool is discovered.
What should OpenCodex do?
OpenCodex should make this boundary explicit and safe:
Example usage or interface
Alternatives or workarounds
Use a native OpenAI model in a separate task for automation management, and use OpenCodex-routed models only for ordinary coding/research turns. This workaround is safe but makes it easy to lose the boundary unless the UI communicates it.
Additional context
Related compatibility work:
automation_updateschema can break some third-party adapters after tool discoveryThe report contains no keys, tokens, OAuth data, task IDs, local paths, or personal data. A sanitized event trace can be provided if maintainers need a minimal reproduction.
Checks