Repository navigation
Mobile-created Codex threads may bypass local opencodex proxy for routed models #17
Description
Summary
When opencodex is running on a Windows laptop, routed models work if the Codex thread is created from the local desktop Codex session. However, creating a new Codex chat from mobile with the same routed model appears to fail before the request reaches the local opencodex proxy.
This may be a Codex mobile / remote-thread limitation rather than a proxy crash, but it is a sharp compatibility trap because the routed model can appear selectable and then fail on the first turn.
Environment
- OS: Windows 11
- opencodex proxy: running locally on
http://localhost:10100 - opencodex version reported by
/healthz:2.1.3 - Example routed model:
umans/umans-kimi-k2.7 - Account mode: Codex with a ChatGPT account
- Mobile-created thread host shown in UI: remote host / laptop target
What works
- Start the opencodex proxy on the laptop.
- Create a new Codex thread locally from the desktop app using
umans/umans-kimi-k2.7. - The first turn completes successfully.
- Continue that existing thread from mobile.
- Follow-up prompts from mobile work.
I verified this by creating a local thread with umans/umans-kimi-k2.7; it completed a simple greeting turn successfully.
What fails
- Start the opencodex proxy on the laptop.
- From mobile Codex, create a new chat targeting the laptop/remote host.
- Select
umans/umans-kimi-k2.7. - Send the first message.
- The turn fails with a 400 error.
Observed error:
{
"type": "error",
"status": 400,
"error": {
"type": "invalid_request_error",
"message": "The 'umans/umans-kimi-k2.7' model is not supported when using Codex with a ChatGPT account."
}
}Interpretation
The error looks like it is coming from Codex / ChatGPT account model validation before the local opencodex provider/proxy is used. If the request reached the local opencodex proxy, I would expect provider/proxy behavior instead of a ChatGPT-account model support error.
Expected behavior
One of these would be helpful:
- Mobile-created threads targeting a local host should use the same local provider configuration as desktop-created threads.
- Or opencodex should document this as a known limitation: routed-model threads should be created from the local desktop session first, then continued from mobile.
Current workaround
Create the routed-model thread from the local desktop Codex app first, then continue that existing thread from mobile.
Activity
0disoft commentedon Jun 22, 2026
Additional 4-case matrix after updating the local proxy to the new
devUmans preset (healthz2.1.6, Umans provider usingadapter: anthropic, modelumans/umans-glm-5.2).The key pattern is not simply that
umans/umans-glm-5.2fails. It depends on which surface creates the thread first.019eee97-de03-7fa0-851a-885a4fea7a1bumans/umans-glm-5.2read_threadshows completed turns.019eee98-c6b8-7322-8144-16250a9a6af0umans/umans-glm-5.2read_threadshows completed turns.019eee9c-3359-7ef0-86e5-8386e4414b64umans/umans-glm-5.2invalid_request_error:The 'umans/umans-glm-5.2' model is not supported when using Codex with a ChatGPT account.Localread_threadcould not find this thread id.019eee9d-5344-7380-a71f-b4b64207592aumans/umans-glm-5.2umans/umans-glm-5.2on laptop fails with the same ChatGPT-account model support error. Localread_threadcould not find this thread id.So the routed model is usable when the local laptop/Codex App creates the thread first, even if mobile later participates or switches models. But when the mobile app creates the thread first, the thread appears to be validated/owned by a ChatGPT-account model policy path, and later routed-model use is rejected with:
This looks separate from the provider-side streaming issue in #18, which is now closed. The local proxy and Umans Anthropic Messages path can complete direct and local Codex App routed turns; the failure is specifically tied to mobile-created thread/session routing or account validation.
lidge-jun commentedon Jun 25, 2026
Thanks for reporting this. I haven't been able to reproduce this behavior in my current setup — mobile-created threads with routed models are reaching the local proxy as expected.
A few things that have changed since this was filed:
ocx codex-shim install) ensures the proxy is running before Codex launchesCould you provide more details to help reproduce?
anthropic/claude-sonnet-4-6)ocx status)Keeping this open for now. If there are additional reproduction details or if this is still happening on a recent version, please share them here.
docs(devlog): review open PRs and issues (#17,#41-45)
lidge-jun commentedon Jul 2, 2026
Partial improvement shipping in the next release: explicit
defaultModelnow outranks known-model pattern routing (66550cb) and bound threads re-evaluate quota, which shrinks the misrouting window described here. The core case — a thread created on mobile that never passes through the local proxy — is an architectural gap we're tracking separately, so leaving this open.0disoft commentedon Jul 10, 2026
This is working now in the current setup with opencodex 2.7.1. I can create and use mobile Codex chats with externally routed models such as GLM through the opencodex proxy, and the previous ChatGPT-account model validation error no longer occurs.
I can no longer reproduce the original issue, so I am closing this as resolved. Thanks!
docs(codex): another process can retarget the home symlink, so adjace…
docs(devlog): review open PRs and issues (lidge-jun#17,lidge-jun#41-45)
docs(codex): another process can retarget the home symlink, so adjace…
fix(devin): system prompt in #2, tool-error flag, Gemini schemas, his…
fix(devin): system prompt in #2, tool-error flag, Gemini schemas, his…
fix(devin): compact on oversized history, accept Gemini type arrays, …