ChatGPT Android Remote creates usable but hidden threads with `model_provider=openai` instead of host config provider

What issue are you seeing?

When I create a new Codex thread from the official ChatGPT Android app using Codex Remote against my connected Windows Codex Desktop host, the thread is created and can run normally, but it does not appear in the Codex thread/project lists on desktop or mobile.

The thread is not deleted or failed. It exists locally, can be addressed by id, and the model responds. The problem is visibility/indexing after creation through the Android remote flow.

This repro uses the official ChatGPT Android app / Codex Remote flow, not a third-party remote client.

Environment

• Host OS: Windows x64
• Codex Desktop package: OpenAI.Codex_26.623.13972.0_x64__2p2nqsd0c76g0
• Codex Desktop version: 26.623.13972.0
• Codex CLI: codex-cli 0.132.0
• Mobile client: official ChatGPT Android app
• Auth mode: ChatGPT auth
• User-level Codex config contains:

model = "gpt-5.5"
model_provider = "codex-lb"
model_reasoning_effort = "xhigh"

codex-lb is a custom OpenAI-compatible Responses provider configured in ~/.codex/config.toml on the host.

Steps to reproduce

1. Pair ChatGPT Android with a Windows Codex Desktop host using Codex Remote.
2. On the Android app, create a new Codex thread in a host project.
3. Send a simple prompt, for example: reply exactly ok.
4. Wait for the assistant response.
5. Check the Codex Desktop/mobile thread list for the new thread.
6. Inspect local Codex state for the thread id.

Example observed Android-created thread id:

019f37ee-0c2e-7632-b2e9-cf991cc81d73

Expected behavior

A thread created from ChatGPT Android Remote should be created/indexed the same way as a thread created directly on the connected host:

• it should appear in the Codex Desktop/mobile thread/project lists;
• it should use the connected host's effective config, including model_provider = "codex-lb";
• it should get the same local metadata/index/catalog entries as a host-created thread.

This matches the documented Remote behavior that remote access uses the connected host's projects, threads, credentials, permissions, plugins, browser setup, and local tools.

Actual behavior

The Android-created thread is usable by id and receives a response, but it is hidden from the normal Codex thread/project list.

Local inspection showed a metadata mismatch between host-created threads and Android-created threads:

• host-created threads use the configured provider, model_provider=codex-lb;
• Android-created remote threads are created/recorded as model_provider=openai;
• the Android-created thread also lacked the local thread visibility metadata/indexing expected by the desktop list path, such as the normal thread_source / session index/catalog state.

After locally normalizing the Android-created thread metadata to match the host defaults and adding the missing local visibility/index state, the same thread becomes visible in Codex Desktop. That suggests the underlying thread data is valid and the issue is in remote thread creation/indexing or provider/config resolution, not model execution.

Why this looks like a bug

The Android remote path appears to create a local thread through a different metadata/provider path than the host desktop path. It seems to fall back to the built-in openai provider instead of resolving the connected host's effective ~/.codex/config.toml provider.

This also makes the issue hard to diagnose from the UI: the task succeeds, but the resulting thread is hidden.

Related reports

This may be related to the broader class of Codex Remote / host-state visibility issues:

• #30165: stale remote-control host selection can hide projects/threads while local SQLite data still exists
• #31187: mobile Remote Control needs clearer multi-account/multi-machine host identity handling
• #30161: recent provider-detection behavior shows custom/OpenAI-compatible provider edge cases in Codex

Workaround

A local watchdog can detect new Android-created threads and normalize their local metadata/provider/index entries to the host default provider. This makes the hidden thread visible, but it is only a workaround. The official remote-create path should create/index the thread correctly from the start.