[Bug]: Provider-table form hides openai-tagged threads from the ChatGPT mobile remote thread list (follow-up to #11)

[practical-tools-lab]

Client or integration

Codex App

Area

Proxy and routing

Summary

Follow-up to #11 (the maintainer asked for a new issue if history/sidebar visibility problems remain). With the provider-table routing form, the ChatGPT mobile app's Codex remote thread list hides every thread tagged model_provider = "openai", even though the same threads are listed in Codex Desktop and are served by the same local proxy.

Cause, measured against the local remote-control daemon (codex app-server --remote-control, Codex 0.157.0) over its control socket:

thread/list call	Result
no modelProviders (what the mobile remote sends)	47 threads, all opencodex
modelProviders: []	100 threads = 47 opencodex + 53 openai

So with no filter, app-server returns only the config.toml root model_provider, which ocx sets to opencodex in the provider-table form (codexClientCompaction=true here).

The openai tags are not legacy-only. Ephemeral thread/start calls without modelProvider against the same daemon were tagged opencodex for 5 different models, but threads created by clients keep getting openai: in this state DB, Desktop-created user threads are 85 openai / 33 opencodex, and mobile-created ones are 8 openai / 2 opencodex. From the user's side, sessions opened by hand "randomly" disappear from the phone while being visible on Desktop.

Both tags reach the same proxy here (the [model_providers.opencodex] table and the root openai_base_url both point at http://127.0.0.1:10100/v1, requires_openai_auth = true), so the difference is list visibility only.

Reproduction

1. Provider-table form: root model_provider = "opencodex" in ~/.codex/config.toml (here via codexClientCompaction=true, codexDesktopAuthless=false, syncResumeHistory=false).
2. Pair the ChatGPT mobile app with the Mac's Codex remote control.
3. Create threads from Codex Desktop and from the mobile app; some are stored with model_provider = "openai".
4. Open the thread list in the mobile app: the openai-tagged threads are missing; Desktop still shows them.
5. Confirm with thread/list over the daemon socket: no filter -> only opencodex; modelProviders: [] -> both.

Version

opencodex 2.61.0 running (the 2.65.0 tarball has byte-identical src/codex/inject/routing-target.ts); Codex CLI/app-server 0.157.0; Codex Desktop 26.915.31945; ChatGPT Android app (remote client codex_chatgpt_android_remote).

Operating system

macOS 26.5.2 (arm64) host; Android phone as remote client

Provider and model

Any; observed with openai/gpt-6-luna, opencode-go/deepseek-v4.1-flash, anthropic/claude-haiku-4-5 threads

Logs or error output

No error. The threads are silently absent from the mobile list.

Screenshots and supporting files

No response

Redacted configuration

model_provider = "opencodex"
openai_base_url = "http://127.0.0.1:10100/v1"

[model_providers.opencodex]
name = "OpenCodex Proxy"
base_url = "http://127.0.0.1:10100/v1"
wire_api = "responses"
requires_openai_auth = true

What would help

Any one of these would remove the trap:

• In the provider-table form, keep user-facing threads (source vscode/cli) tagged with the active proxy provider id, e.g. as an opt-in part of history sync, since clients keep creating openai-tagged threads after injection.
• Document this as a known limitation of the provider-table form next to the Desktop label note, with the modelProviders: [] evidence.
• If it belongs upstream (app-server's default thread/list provider filter, or the mobile client not sending modelProviders), say so and I will file it with openai/codex.

Local workaround in use: a periodic retag of openai -> opencodex for recent vscode/cli threads. Upsert writes the in-memory provider back while a thread is loaded, so the retag has to repeat.

Checks

• I searched existing issues and documentation.
• I removed secrets, tokens, account details, request credentials, and personal data.

[Ingwannu]

Additional confirmed reproduction from duplicate #5906: enabling codexClientCompaction intentionally skips history retagging while setting root model_provider = "opencodex". On a home with roughly 5,200 pre-existing openai-tagged threads, a mobile thread/list request that omitted modelProviders returned only the single new opencodex thread; disabling compaction restored full visibility. This is the same provider-table/default-filter boundary reported here, not a separate compaction bug. Keeping this issue as the canonical tracker; any fix must preserve existing-thread routing and avoid unsafe broad history rewrites.

[codingbooo]

I have documented this limitation and verified the root cause on branch feat/issue-5848-mobile-openai-threads in fork codingbooo/opencodex.

Findings

• Confirmed that thread/list RPC is handled directly by Codex's native app-server rather than OpenCodex's HTTP proxy. When model_provider = "opencodex", an omitted modelProviders filter returns only opencodex threads, whereas modelProviders: [] returns both openai and opencodex.
• Because paginated history ownership belongs to Codex native SQLite writers and periodic retagging causes divergence with runtime rollouts, this has been clearly documented under Codex integration docs with reproduction tables and client guidance.

[Ingwannu]

Maintainer update: #6007 now carries the safe in-repository mitigation.

• ocx sync / ocx start warn whenever the effective target uses provider-table routing.
• The Dashboard warns before enabling authless Desktop or client-side compaction.
• The docs explain that the row/rollout remains intact and that compatible clients can request modelProviders: [].
• Regression tests pin both sides of the boundary: the existing openai tag/rollout stays byte-for-byte unchanged, while a default-provider-only predicate excludes that row.

This deliberately does not relabel paginated history: native Codex owns the SQLite/rollout writer, and the mobile client talks directly to native app-server for thread/list, outside the OpenCodex inference proxy.

Leaving #5848 open for the upstream app-server/mobile default-filter correction. Thanks @codingbooo for the version-specific reproduction and direct-RPC confirmation.

[lidge-jun]

#6007, carried in #6070 (merge 29cef45a86), adds a warning in the dashboard (under the switch that turns on provider-table routing) and in ocx start/sync output: some mobile remote thread lists hide existing openai-tagged history when that routing is on. It is a mitigation and does not change the history. The fix itself needs the remote client to list all providers, so this issue stays open for that.

[luvs01]

Upstream follow-up: openai/codex#48358 now has a code-level analysis that confirms the behavior seen here.

The important clarification is that the omitted modelProviders case is currently intentional app-server policy, not a recent regression:

• omitted modelProviders → defaults to config.model_provider_id
• modelProviders: [] → no provider filter / all providers
• this behavior traces back to the provider-filtering work in feat: annotate conversations with model_provider for filtering openai/codex#5658, intended to avoid cross-provider resume/decryption failures

The upstream analysis also points out that this omission behavior is not documented in the protocol comment, which is why clients can reasonably assume omission and [] are equivalent.

That narrows the preferred end-state for this issue: changing app-server omission semantics globally may have compatibility/safety consequences; for the mobile remote thread list, explicitly requesting modelProviders: [] appears to be the supported way to request the full history. This is consistent with the mitigation already taken here (#6007/#6070) of avoiding history relabeling.

Upstream reference: openai/codex#48358

[Ingwannu]

Thanks for the upstream confirmation. That establishes that omitted modelProviders intentionally defaults to config.model_provider_id, while an explicit empty array means all providers. Changing the upstream default globally would be risky; the preferred long-term fix is for the mobile client to request modelProviders: [] when it wants cross-provider history. Our server-side mitigation from #6007 is already carried in the release train and avoids relabeling stored history. Keeping this issue open to track the client-side correction and upstream release availability.