Codex Remote mobile-created tasks ignore the host model provider and offer no provider selection
What issue are you seeing?
When creating a new Codex task from the official mobile Remote interface connected to Codex Desktop, there is no way to choose the model provider.
The host is configured with a non-default provider in ~/.codex/config.toml, and tasks created directly on the host use that provider correctly. Existing host-created tasks also continue to work when controlled from mobile.
However, a task created directly from mobile Remote is recorded with model_provider=openai instead of the host's configured provider. The request then uses the built-in ChatGPT/OpenAI route. If the selected model is only available through the configured provider, the task fails before producing an assistant response.
Environment
- Host OS: Windows x64
- Codex Desktop:
26.707.9981.0 - Codex CLI:
0.144.2 - Mobile client: official ChatGPT mobile app / Codex Remote
- Authentication: ChatGPT login
- Host config: non-default OpenAI-compatible Responses provider
Steps to reproduce
- Configure Codex Desktop with a non-default
model_providerin~/.codex/config.toml. - Confirm that a task created on the desktop uses the configured provider.
- Connect the official mobile app to the desktop using Codex Remote.
- From mobile, open an existing desktop-created task and send a message. It continues using the configured provider.
- From mobile, create a new task and send a message.
- Inspect the new task metadata and request route.
Expected behavior
A task created through mobile Remote should either:
- inherit the connected host's effective
model_provider; or - allow the user to select a provider before creating the task.
Actual behavior
The new mobile-created task uses model_provider=openai regardless of the host's configured provider. The mobile UI does not offer a provider selector.
This can make the task fail when the chosen model is not available through the built-in ChatGPT route, even though the same model and provider work for tasks created on the host.
Additional context
This appears related to #31370, which also reports mobile-created tasks being recorded with model_provider=openai. This report focuses specifically on provider selection/inheritance and the resulting request failure.
2 Comments
Additional confirmed reproduction on macOS with an API-only model. This matches the provider overwrite described in this issue.
Environment
requires_openai_auth=falsegpt-5.6-solmodel_catalog_jsonexposes that model withsupported_in_api=trueConfirmed metadata difference
A thread created directly on the host persists:
A new thread created from mobile Remote persists:
The first turn of the mobile-created thread then fails with:
The Remote model picker still displays
GPT-5.6 Sol. This suggests the client is reading the host's custom model catalog, but the remote thread-start path is overriding the host provider withopenai.The failure appears limited to creating a new thread from Remote. Host-created threads retain the configured custom provider when subsequently accessed remotely.
This does not appear to be a subscription/quota failure: local diagnostics report that OpenAI auth is not required for the active provider, and host-created threads work through that provider.
Expected behavior: a Remote-created thread should inherit the host's effective
model_providerwhen the mobile client has no explicit provider selector. Alternatively, the Remote model picker should filter out models that cannot run through the provider it will actually select.Seeing the same thing on iOS Remote with a custom provider (DeepSeek in my case).
Local Codex is already configured to use the custom provider, but when I create a new task from Remote on my phone there’s no way to choose that provider. The Remote UI only gives me the OpenAI model/provider path instead of using the host config.
Would be great if Remote-created tasks just inherited the host’s effective
model_providerby default. A provider picker on mobile would also solve it, but inheriting the host config feels like the least surprising behavior.