Codex remote shows Auto review as permissions (matching the Windows app) then switches to Custom (config.toml) after hitting send on the chat

[kendonB]

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

26.527.30818

What subscription do you have?

Pro

What platform is your computer?

Win 11 x64

What issue are you seeing?

Codex remote shows Auto review as permissions (matching the Windows app) then switches to Custom (config.toml) after hitting send on the chat

What steps can reproduce the bug?

New project in the Windows App (WSL mode), new chat in the Windows App with Auto Review. Open the Android app, new chat (shows auto review), hit send, shows Custom (config.toml).

What is the expected behavior?

Stays on Auto review

Additional information

No response

[github-actions]

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

• iOS Codex remote: Full access selected but new threads start with workspace-write/on-request; Custom config.toml works #24270

Powered by Codex Action

[Divine-Shadow]

Codex Mobile Remote Config Bug Report

Upstream target: #25186

Date: 2026-06-01

Summary

On Windows Codex Desktop, mobile remote-control thread creation can ignore the user's resolved config.toml defaults and instead appear to use default Codex settings. The Desktop app itself does read config.toml on the ordinary composer path, so this looks specific to the mobile/remote-control or delegated thread creation path.

Observed user-facing symptoms:

• Mobile-created Codex threads do not reliably inherit config.toml model/reasoning/permission settings.
• The UI can appear locked to default Codex settings.
• A remote-control status indicator in the Desktop settings UI looks button-like, but pressing it does not perform an action.

Environment

• Host OS: Windows 11 x64.
• Codex install: Microsoft Store package OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0.
• Extracted Electron app package metadata: openai-codex-electron version 26.527.31326, build number 3390.
• App-server process observed as codex.exe app-server --analytics-default-enabled.
• User config includes non-default model, reasoning effort, approval policy, and sandbox mode values.

Code-Level Evidence

The normal Desktop composer path reads resolved config before starting a thread:

• webview/assets/composer-Beu4UAMC.js calls read-config-for-host, normalizes the result, and passes it into start-conversation.
• webview/assets/use-model-settings-DhE-8qP1.js reads model settings via read-config-for-host.
• webview/assets/use-permissions-mode-DHT7uJLN.js reads config and host requirements before deriving permissions.

The mobile setup flow does not use those hooks:

• webview/assets/codex-mobile-setup-flow-BJylBH5W.js handles remote-control enrollment and toggles local_remote_control_enabled.
• It talks to remote-control/account endpoints and does not read config.toml or use the normal composer model/permissions path.

The delegated/mobile-adjacent thread creation helper contains an explicit fallback that can override config-derived values:

function w(e,t){
  return e==null&&t==null
    ? null
    : {
        mode: `default`,
        settings: {
          model: e ?? `gpt-5.5`,
          reasoning_effort: t ?? `medium`,
          developer_instructions: null
        }
      }
}

This appears in webview/assets/app-server-dynamic-tools-ChwcT_7g.js. If the mobile/remote-control path sends a partial model/reasoning selection, or if this helper is used for mobile-created work, it can synthesize an explicit collaborationMode with hardcoded defaults instead of letting the resolved config.toml values win.

Expected Behavior

For mobile-created remote-control threads, Desktop should use the same effective start parameters as the normal Desktop composer:

1. Read resolved config with read-config-for-host.
2. Normalize config and derive permissions from the same code path as Desktop.
3. Only send explicit model/reasoning/collaboration overrides when the mobile user actually selected an override.
4. Otherwise leave collaborationMode unset or populate it from resolved config, not hardcoded defaults.

Actual Behavior

Mobile-created threads appear to use default model/reasoning/permission behavior even when the host config.toml has non-default values. The installed app bundle contains a likely source of this behavior: hardcoded fallback values of gpt-5.5 and medium in the thread creation helper.

UI Note

The remote-control settings/status area also has a discoverability issue: a status indicator looks like a button, but pressing it does not perform an action. Either the indicator should be styled as passive status, or it should navigate to the relevant remote-control connection/settings surface.

Suggested Fix

Change the mobile/remote-control thread creation path to share the Desktop composer start-params builder, or at minimum avoid synthesizing hardcoded default collaborationMode values. Missing mobile model/reasoning selections should mean "inherit resolved host config", not "force defaults".