Codex App: remotely started tasks ignore model_provider and fail for custom-provider models (400 "not supported when using Codex with a ChatGPT account")

What version of the Codex App are you using (From "About Codex" dialog)?

26.908.4834.0 (bundled runtime codex-cli 0.154.0)

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Tasks started remotely (from ChatGPT web or the ChatGPT mobile app, targeting this computer through remote control) ignore the configured model_provider and are sent through the ChatGPT-account provider instead. Models from the custom provider are shown and selectable in the remote model picker, but the first turn fails with:

error 400 invalid_request_error The claude-fable-5-1 model is not supported when using Codex with a ChatGPT account.

The same configuration works everywhere else: tasks started in the desktop app and in the CLI use the custom provider and the same model without any issue. Only remotely started tasks fail, and they fail for every model that belongs to the custom provider (the built-in OpenAI models work remotely as before).

Configuration (redacted):

model = "claude-fable-5-1"
model_provider = "local"
model_catalog_json = "C:/Users/<user>/.codex/models-curated.json"

[model_providers.local]
name = "Local gateway"
base_url = "http://127.0.0.1:8317/v1"
wire_api = "responses"

[model_providers.local.http_headers]
X-Api-Key = "<redacted>"

models-curated.json lists the custom models (claude-fable-5-1, claude-sonnet-5, claude-opus-5) alongside the OpenAI ones, which is why they appear in the picker.

What steps can reproduce the bug?

1. Configure a custom OpenAI-compatible provider in ~/.codex/config.toml as above, add its models to model_catalog_json, and set model_provider to it.
2. Sign in to the desktop app with a ChatGPT account and enable remote control.
3. Start a new task in the desktop app with one of the custom models: works.
4. From ChatGPT web or the mobile app, start a new task on this computer and choose the same custom model in the picker.
5. The first turn fails with the 400 above. Sending a follow-up message to the same task fails the same way.

What is the expected behavior?

A remotely started task should honor the local config.toml the same way a locally started task does: model_provider (and profile) selection should apply to the runtime that executes the task, regardless of which surface created it. Bring-your-own-model is supported for local sessions, so the remote entry point should not force the ChatGPT-account provider for models that are not OpenAI models.

If remote tasks are intentionally restricted to the ChatGPT-account provider, the remote model picker should only list models that provider can serve, instead of offering custom-provider models that are guaranteed to fail.

Additional information

Provider selection appears to be decided by the surface that creates the thread rather than by the local configuration: the runtime on the computer has the provider configured and uses it for local threads, so the remote path seems to construct the thread with the built-in provider pinned. Happy to provide logs from ~/.codex/log or a session id on request.

Start by comparing the local task path with the remotely started task path, using the model_provider and profile settings in config.toml as the reference. Check how models-curated.json feeds the remote model picker and use the available ~/.codex/log files or session ID to trace provider selection. Done means remote tasks either honor the configured custom provider or exclude unsupported custom-provider models from the picker.