Skip to content

Mobile-created Codex threads may bypass local opencodex proxy for routed models #17

Closed
Closed
Mobile-created Codex threads may bypass local opencodex proxy for routed models#17

Description

@0disoft
0disoft
opened on Jun 22, 2026

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

  1. Start the opencodex proxy on the laptop.
  2. Create a new Codex thread locally from the desktop app using umans/umans-kimi-k2.7.
  3. The first turn completes successfully.
  4. Continue that existing thread from mobile.
  5. 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

  1. Start the opencodex proxy on the laptop.
  2. From mobile Codex, create a new chat targeting the laptop/remote host.
  3. Select umans/umans-kimi-k2.7.
  4. Send the first message.
  5. 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

  1. 0disoft commented on Jun 22, 2026

    @0disoft
    0disoft
    on Jun 22, 2026
    ContributorAuthor

    Additional 4-case matrix after updating the local proxy to the new dev Umans preset (healthz 2.1.6, Umans provider using adapter: anthropic, model umans/umans-glm-5.2).

    The key pattern is not simply that umans/umans-glm-5.2 fails. It depends on which surface creates the thread first.

    Case Thread id First surface/model Later surface/model Result
    1 019eee97-de03-7fa0-851a-885a4fea7a1b Laptop / umans/umans-glm-5.2 Mobile / GPT Works. Local read_thread shows completed turns.
    2 019eee98-c6b8-7322-8144-16250a9a6af0 Laptop / GPT Mobile / umans/umans-glm-5.2 Works. Local read_thread shows completed turns.
    3 019eee9c-3359-7ef0-86e5-8386e4414b64 Mobile / umans/umans-glm-5.2 Laptop / GPT Fails immediately on mobile with invalid_request_error: The 'umans/umans-glm-5.2' model is not supported when using Codex with a ChatGPT account. Local read_thread could not find this thread id.
    4 019eee9d-5344-7380-a71f-b4b64207592a Mobile / GPT Laptop / umans/umans-glm-5.2 GPT turn works, but switching to umans/umans-glm-5.2 on laptop fails with the same ChatGPT-account model support error. Local read_thread could 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:

    The 'umans/umans-glm-5.2' model is not supported when using Codex with a ChatGPT account.

    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.

  2. lidge-jun commented on Jun 25, 2026

    @lidge-jun
    lidge-jun
    on Jun 25, 2026
    Owner

    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:

    • Thread affinity is now explicit: once a thread starts on a specific account, it stays pinned regardless of where the next turn originates (CLI, App, or mobile)
    • The auto-start shim (ocx codex-shim install) ensures the proxy is running before Codex launches

    Could you provide more details to help reproduce?

    1. Which routed model were you selecting on mobile? (e.g. anthropic/claude-sonnet-4-6)
    2. Was the opencodex proxy confirmed running when the mobile thread was created? (ocx status)
    3. What error did you see on mobile — did the model appear in the picker but fail on first turn, or was it absent entirely?
    4. Are you still seeing this on the latest version (v2.1.11+)?

    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.

  3. lidge-jun
    added a commit that references this issue on Jun 29, 2026

    docs(devlog): review open PRs and issues (#17,#41-45)

    c6679bd

  4. lidge-jun commented on Jul 2, 2026

    @lidge-jun
    lidge-jun
    on Jul 2, 2026
    Owner

    Partial improvement shipping in the next release: explicit defaultModel now 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.

  5. 0disoft commented on Jul 10, 2026

    @0disoft
    0disoft
    on Jul 10, 2026
    ContributorAuthor

    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!

  6. 0disoft
    closed this as completedon Jul 10, 2026
  7. lidge-jun
    added a commit that references this issue on Aug 4, 2026

    docs(codex): another process can retarget the home symlink, so adjace…

    d7f1a8e
  8. agentHits
    added 2 commits that reference this issue on Sep 17, 2026

    docs(devlog): review open PRs and issues (lidge-jun#17,lidge-jun#41-45)

    067457b

    docs(codex): another process can retarget the home symlink, so adjace…

    f09229c
  9. lidge-jun
    added 3 commits that reference this issue on Sep 28, 2026

    fix(devin): system prompt in #2, tool-error flag, Gemini schemas, his…

    4e0c626

    fix(devin): system prompt in #2, tool-error flag, Gemini schemas, his…

    645bbd0

    fix(devin): compact on oversized history, accept Gemini type arrays, …

    da874dd
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions