Codex Remote mobile-created tasks ignore the host model provider and offer no provider selection

Open 💬 2 comments Opened Jul 14, 2026 by Follen

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

  1. Configure Codex Desktop with a non-default model_provider in ~/.codex/config.toml.
  2. Confirm that a task created on the desktop uses the configured provider.
  3. Connect the official mobile app to the desktop using Codex Remote.
  4. From mobile, open an existing desktop-created task and send a message. It continues using the configured provider.
  5. From mobile, create a new task and send a message.
  6. 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.

View original on GitHub ↗

2 Comments

0x30 · 27 days ago

Additional confirmed reproduction on macOS with an API-only model. This matches the provider overwrite described in this issue.

Environment

  • Host: macOS 26.5.2, arm64
  • ChatGPT Desktop: 26.727.40816 (build 6067)
  • Bundled Codex CLI: 0.146.0-alpha.9.2
  • Client: official ChatGPT mobile Remote
  • Remote authentication: ChatGPT login
  • Host execution config: custom OpenAI-compatible Responses provider
  • The active custom provider has requires_openai_auth=false
  • Configured model: gpt-5.6-sol
  • A custom model_catalog_json exposes that model with supported_in_api=true

Confirmed metadata difference

A thread created directly on the host persists:

model_provider=<custom provider>

A new thread created from mobile Remote persists:

model_provider=openai

The first turn of the mobile-created thread then fails with:

400 invalid_request_error:
The 'gpt-5.6-sol' model is not supported when using Codex with a ChatGPT account.

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 with openai.

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_provider when 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.

manhhailua · 12 days ago

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_provider by default. A provider picker on mobile would also solve it, but inheriting the host config feels like the least surprising behavior.