›_ Codex Issues
Codex Issues / #23659

Mobile Remote: Android Remote should preserve host provider config

Open 💬 3 comments Opened May 20, 2026 by HanCheg0812
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

Mobile Remote sessions created from Android Remote can ignore the host's local provider configuration because the phone request sends modelProvider=openai as an explicit default. That value can override the host-side config/thread-config result, so a phone-created session may use ChatGPT/OpenAI auth and quota even when the host is configured to use a custom/local provider.

I tried to open this as a PR, but openai/codex currently only allows collaborators to create pull requests against the upstream repository from my fork. I am filing the issue with the patch branch details instead.

Observed behavior

A phone-created session from codex_chatgpt_android_remote persisted with:

  • model_provider=openai
  • ChatGPT websocket auth path

This happened even though the host-side local config/thread-config provider was returning the intended custom provider for new sessions.

Expected behavior

When Android Remote sends the default provider value openai, app-server should treat that as "no explicit provider override" so the host's configured provider/thread-config can win.

If Android Remote sends a non-default provider value, that explicit override should still be preserved.

Patch branch

The change is limited to:

  • codex-rs/app-server/src/request_processors/thread_processor.rs
  • codex-rs/app-server/src/request_processors/thread_processor_tests.rs

Validation

On the patch branch I ran:

cargo test -p codex-app-server normalize_thread_start_model_provider_drops_android_remote_openai_default
cargo build -p codex-app-server

Both passed locally.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 3 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #22411
  • #23482

Powered by Codex Action

Snailflyer · 3 months ago

This is a good place to preserve host authority explicitly. If the Android Remote value is only the client default, treating modelProvider=openai as an explicit override changes who owns execution policy: the phone ends up forcing provider/auth/quota semantics instead of the host config deciding them.

I would expect the thread-start path to distinguish three cases:

  1. No client provider override: resolve provider from host/thread config.
  2. Client sent the default OpenAI value implicitly: same as no override.
  3. Client deliberately selected a non-default provider: preserve that explicit override.

It would also help to emit the resolved provider in a thread-start receipt, so mobile users can see whether a session is using host config or a phone-side override before work starts consuming the wrong quota.

HanCheg0812 · 3 months ago

That matches the behavior I observed locally. Android Remote was sending modelProvider=openai as part of the thread-start payload, and the app-server treated that as an explicit override. The result was that a host configured for a custom provider still created phone-started threads with model_provider=openai, so execution went through the ChatGPT/OpenAI provider path and quota instead of the host's configured provider.

The fix I was testing is aligned with your three-case split: normalize the Android Remote default OpenAI value as “no client provider override”, then let the host/thread config resolve the provider; still preserve a deliberate non-default client-side provider choice.

I also agree that returning the resolved provider in a thread-start receipt would be useful. It would make the ownership boundary visible before work starts, especially for mobile sessions where the user may not realize whether execution is using host config or a phone-side override.