Waiting for desktop despite Codex App being authorized

I see exactly the same Issue on Android.

I managed to connect, had to update my CLI using latest install.ps1 script from Releases, then I still couldn't use the Codex app, had to open command prompt and use 'codex remote-control' command.

Only then it finally paired, but now I have another issue, where I just can't send the prompts in chat.

No errors are shown, I just type a prompt, then press send and it erases the prompt without sending it

I was able to authenticate by using the CLI, but then it won't reconnect unless I manually run the 'codex remote-control' command.

Same issue on Android.

Adding a related datapoint: I hit the same visible Waiting for desktop symptom on macOS + Android/iOS, but in this case the local remote-control daemon was running and the real blocker was network/proxy propagation. The daemon was trying to connect directly to the backend and stayed in SYN_SENT; starting codex remote-control with explicit HTTP_PROXY / HTTPS_PROXY / ALL_PROXY made the backend immediately show the Mac as online: true.

I opened the focused report with diagnostics/workaround here: #22851

Same issue on iOS despite reinstalling both iOS and Mac apps several times and logging in and out.

Same behavior for me. After investigating, I see "Support for connecting your phone to the Codex app on Windows is coming soon." -- https://openai.com/index/work-with-codex-from-anywhere/

codex remote-control needed to be run from my CLI for my ChatGPT app to authorize my phone.

I have the same issue, it just gets stuck, nothing appears on Desktop app. Using Windwos version and android phone app.

I have same issue and I’m not able to resolve it. Restarted desktop app

The same issue. Same case - IPhone app and Windows app.

Same issue on windows and iOS. Anyone know the cli command to force it?

I was able to get a Windows Desktop -> Codex Mobile connection working locally after patching the public app-server feature gating path.

Branch with the patch:
https://github.com/cobycloud/codex/tree/eeedx-windows-remote-control-desktop-config

What I changed:

• Added remote_connections to the public feature registry in codex-rs/features.
• Added remote_connections to app-server runtime feature enablement support.
• Updated the config schema so [features].remote_connections = true is a recognized config key.
• Added tests proving config/read exposes both:
• features.remote_connections = true
• features.remote_control = true

Why this matters for the Waiting for desktop issue:

• The mobile/desktop pairing UI is not only controlled by whether the codex://settings/connections route exists.
• The renderer needs app-server/Desktop state showing that remote connections and remote control are actually available.
• Before this patch, remote_control was known to app-server, but remote_connections was not accepted as a supported runtime feature enablement in the public app-server path.
• That means a Windows Desktop session could have local config intending to enable the mobile/remote connection path, but app-server would not consistently report the feature state needed by the Connections/mobile surface.
• After the patch, enabling both flags allows config/read to publish the expected feature state, and in my local Windows setup this was enough to get the Windows desktop visible/connectable from Codex Mobile.

Validation run locally:

• cargo fmt -p codex-app-server -p codex-features
• cargo test -p codex-features
• cargo test -p codex-app-server experimental_feature_enablement_set
• git diff --check upstream/codex/linux-desktop-launch..HEAD

Important scope note:
This patch fixes the public app-server/config feature enablement gap. There may still be Desktop/Electron-specific work needed upstream for the fully supported Windows path, especially around:

• Desktop startup feature propagation,
• any Desktop logic that suppresses remote_control,
• remote_control_connections_state,
• refresh/authorize IPC wiring,
• and Windows remote-control device/client identity handling.

Given the repository contribution policy says external PRs are by invitation only, I am not opening an unsolicited upstream PR. If a maintainer wants it, I can open this branch as a focused PR for the public app-server prerequisite.

I was able to get a Windows Desktop -> Codex Mobile connection working locally after patching the public app-server feature gating path. Branch with the patch: https://github.com/cobycloud/codex/tree/eeedx-windows-remote-control-desktop-config What I changed: Added remote_connections to the public feature registry in codex-rs/features. Added remote_connections to app-server runtime feature enablement support. Updated the config schema so [features].remote_connections = true is a recognized config key. Added tests proving config/read exposes both: features.remote_connections = true features.remote_control = true Why this matters for the Waiting for desktop issue: The mobile/desktop pairing UI is not only controlled by whether the codex://settings/connections route exists. The renderer needs app-server/Desktop state showing that remote connections and remote control are actually available. Before this patch, remote_control was known to app-server, but remote_connections was not accepted as a supported runtime feature enablement in the public app-server path. That means a Windows Desktop session could have local config intending to enable the mobile/remote connection path, but app-server would not consistently report the feature state needed by the Connections/mobile surface. After the patch, enabling both flags allows config/read to publish the expected feature state, and in my local Windows setup this was enough to get the Windows desktop visible/connectable from Codex Mobile. Validation run locally: cargo fmt -p codex-app-server -p codex-features cargo test -p codex-features cargo test -p codex-app-server experimental_feature_enablement_set git diff --check upstream/codex/linux-desktop-launch..HEAD Important scope note: This patch fixes the public app-server/config feature enablement gap. There may still be Desktop/Electron-specific work needed upstream for the fully supported Windows path, especially around: Desktop startup feature propagation, any Desktop logic that suppresses remote_control, remote_control_connections_state, refresh/authorize IPC wiring, and Windows remote-control device/client identity handling. Given the repository contribution policy says external PRs are by invitation only, I am not opening an unsolicited upstream PR. If a maintainer wants it, I can open this branch as a focused PR for the public app-server prerequisite.

<img width="1080" height="2460" alt="Image" src="https://github.com/user-attachments/assets/c206d194-940e-4821-9ff1-0353e73f167f" />

This is excellent, thanks a lot for this! I've successfully managed to get Codex to fix itself by linking it your repo and it compiled a brand new codex.exe and autonomously replaced it and after a quick app restart mobile remote control was working flawlessly! That was one of the most meta sessions I've had with Codex so far, so it was quite fun to try.

@VykosX

This is excellent, thanks a lot for this! I've successfully managed to get Codex to fix itself by linking it your repo and it compiled a brand new codex.exe and autonomously replaced it and after a quick app restart mobile remote control was working flawlessly! That was one of the most meta sessions I've had with Codex so far, so it was quite fun to try.

How long did your codex work on it? Mine is running over an hour now and has some timeout issues while building. Could you generate a prompt from your session/chat so others can compile this patch too? I really appreciate any help you can provide.

+1

Lenamm12 > This is excellent, thanks a lot for this! I've successfully managed to get Codex to fix itself by linking it your repo and it compiled a brand new codex.exe and autonomously replaced it and after a quick app restart mobile remote control was working flawlessly! That was one of the most meta sessions I've had with Codex so far, so it was quite fun to try. How long did your codex work on it? Mine is running over an hour now and has some timeout issues while building. Could you generate a prompt from your session/chat so others can compile this patch too? I really appreciate any help you can provide.

51m 55s, but what took a long time (about 40 of those minutes) was recompiling codex from the source, which will vary based on your hardware.

Here's the full exchange:

Today you'll be fixing... Surprise! Yourself! Specifically the Codex for Windows app. There's a new feature that allows you to connect to the desktop Codex client via the Mobile ChatGPT app but it's currently broken as described in this github issue: https://github.com/openai/codex/issues/23289 As you can see from the screenshot it's expecting a connection from the desktop app but there are no instructions in the desktop app, the feature seems to be currently bugged. An adanced user has figured out a solution and managed to fix the bug here: https://github.com/openai/codex/issues/22715#issuecomment-4475273064 I'd like you to implement it and fix my local Codex for Windows app so I can use it from my mobile phone the same way this user has managed to do it!

I’m going to inspect the local workspace and the linked GitHub issues so I can understand the exact workaround, then I’ll wire that fix into your local Windows Codex app and verify what changed.

Searched web 4 times

I’ve confirmed the public issue matches your symptom. Next I’m pulling the exact workaround comment and locating your Windows Codex install plus its local state so I can apply the same fix cleanly.

The workaround comment is clear: Windows pairing starts working once the desktop app-server exposes features.remote_connections = true alongside remote_control. I’m now checking whether your installed app can be fixed by config alone or whether we need to patch the packaged app files directly.

Your current install is OpenAI.Codex 26.506.3741.0, which matches the timeframe of the bug reports. I also confirmed your user config currently has no remote feature flags, so I’m checking the packaged app and runtime to see the least invasive way to enable the missing remote_connections path.

I’ve found the packaged app bundle and the embedded Rust runtime. Now I’m probing both for remote_connections support so we can tell whether a config-only fix is possible or whether the binary itself needs patching.

The embedded Rust binary confirms the root cause: remote_control exists, but remote_connections is absent from the supported feature list in your shipped build. That means a plain config edit won’t be enough on 26.506.3741.0; I’m now finding the safest way to swap in a patched runtime without breaking the Store install.

Steered conversation

The user has linked a full repo with the finalized patch, just download it and apply it on my machine, no need to reinvent the wheel today: https://github.com/cobycloud/codex/tree/eeedx-windows-remote-control-desktop-config

That helps. I already confirmed the shipped Windows binary is missing remote_connections, and your linked branch is the exact source patch for that gap. I’m pulling that branch now so I can build the patched runtime and hook your desktop app to it.

I’ve got the patched branch locally and verified it adds exactly what your installed build is missing: remote_connections in the feature registry, config schema, and app-server config/read path. Next I’m identifying the precise crate/binary to compile so we only replace the runtime piece that matters.

I found the clean insertion point: the desktop app copies resources/codex.exe into your writable per-user path C:\Users\Victor\AppData\Local\OpenAI\Codex\bin\codex.exe, and the hashes currently match. That means we don’t need to fight WindowsApps; if we build a patched codex.exe, we can swap just that user-local runtime and restart Codex.

Build tools are present, just not on your current PATH, so we’re in good shape. I’m installing a minimal Rust toolchain next, then I’ll compile the patched Windows codex.exe in a proper MSVC environment and replace the per-user runtime copy the app actually uses.

The first build attempt tripped over PowerShell quoting, not the code or toolchain. I’m rerunning it with a cleaner cmd invocation so the Visual Studio environment gets loaded correctly before Cargo starts.

---
This is the part that took 40+ minutes on my laptop, rebuilding Codex from source.
---

The patched codex.exe finished building successfully. I’m checking one subtle but important detail now: the desktop app only refreshes its user-local runtime copy when the file size differs from the Store bundle, so if needed I’ll make the replacement size-stable before swapping it in.

Searched web 1 time
The patched runtime compressed beautifully, which gives us room to make it “look” like the stock file to the desktop app’s size-based refresh check. I’m padding it to the exact original byte length, backing up your current per-user runtime, then I’ll write the remote feature flags into your Codex config so the new binary actually exposes the mobile pairing path.

I’ve validated the padded patched binary still runs. I’m making the two final local changes now: swapping your per-user codex.exe with a backup, and enabling both remote_connections and remote_control in your Codex config so the app-server reports the pairing capability the mobile app expects.

Edited 1 file
Your local Windows Codex install is patched for the mobile pairing bug on OpenAI.Codex 26.506.3741.0. I used the workaround from [issue comment #4475273064](https://github.com/openai/codex/issues/22715#issuecomment-4475273064) and the linked branch [ eeedx-windows-remote-control-desktop-config ](https://github.com/cobycloud/codex/tree/eeedx-windows-remote-control-desktop-config), built a patched codex.exe, then replaced the per-user runtime copy the desktop app actually uses at codex.exe. I also enabled features.remote_connections = true and features.remote_control = true in config.toml.

One important step remains: fully quit Codex Desktop and reopen it, because I didn’t kill the running app-server out from under our current session. After restart, try the mobile connection flow again. Your original runtime is backed up at codex.exe.pre-remote-connections-backup if you want to revert. I couldn’t do an end-to-end pairing test from here without interrupting the active desktop session, but the binary and config changes are in place.

I looked into extracting an xdelta for you from the patched codex executable but Codex had to pack it with UPX and pad about 50mb of it with zeros to keep it the exact same file as size as the original so it wouldn't be overwritten which made extracting a simple delta very awkward. You're better off recompiling from source as I did or waiting for the official fix.

From iPhone ChatGPT codex menu it used to do prompts for codex Web/Cloud without need for connection to desktop codex app. How can this behavior be re-enabled?

+1

This thread has multiple different failures that collapse into the same mobile message: "Waiting for desktop".

That state should probably be split into more actionable cases:

• platform unsupported or not yet enabled for this desktop build
• desktop app installed but remote capability not advertised by app-server
• remote-control daemon not running
• daemon running but relay/backend unreachable
• mobile has a stale host binding and is waiting for the wrong host

Right now users are trying CLI commands, desktop updates, app reinstalls, proxy fixes, and source patches because the UI does not say which layer is missing. Even a read-only diagnostic panel showing host id, platform support, daemon status, relay registration, and last backend heartbeat would make this much less opaque.

Receiving this for WIndows + iOS. Commenting to follow

> I was able to get a Windows Desktop -> Codex Mobile connection working locally after patching the public app-server feature gating path. > > Branch with the patch: https://github.com/cobycloud/codex/tree/eeedx-windows-remote-control-desktop-config > > What I changed: > > Added remote_connections to the public feature registry in codex-rs/features. > Added remote_connections to app-server runtime feature enablement support. > Updated the config schema so [features].remote_connections = true is a recognized config key. > Added tests proving config/read exposes both: > > features.remote_connections = true > features.remote_control = true > > Why this matters for the Waiting for desktop issue: > > The mobile/desktop pairing UI is not only controlled by whether the codex://settings/connections route exists. > The renderer needs app-server/Desktop state showing that remote connections and remote control are actually available. > Before this patch, remote_control was known to app-server, but remote_connections was not accepted as a supported runtime feature enablement in the public app-server path. > That means a Windows Desktop session could have local config intending to enable the mobile/remote connection path, but app-server would not consistently report the feature state needed by the Connections/mobile surface. > After the patch, enabling both flags allows config/read to publish the expected feature state, and in my local Windows setup this was enough to get the Windows desktop visible/connectable from Codex Mobile. > > Validation run locally: > > cargo fmt -p codex-app-server -p codex-features > cargo test -p codex-features > cargo test -p codex-app-server experimental_feature_enablement_set > git diff --check upstream/codex/linux-desktop-launch..HEAD > > Important scope note: This patch fixes the public app-server/config feature enablement gap. There may still be Desktop/Electron-specific work needed upstream for the fully supported Windows path, especially around: > > Desktop startup feature propagation, > any Desktop logic that suppresses remote_control, > remote_control_connections_state, > refresh/authorize IPC wiring, > and Windows remote-control device/client identity handling. > > Given the repository contribution policy says external PRs are by invitation only, I am not opening an unsolicited upstream PR. If a maintainer wants it, I can open this branch as a focused PR for the public app-server prerequisite. <img width="1080" height="2460" alt="Image" src="https://github.com/user-attachments/assets/c206d194-940e-4821-9ff1-0353e73f167f" /> This is excellent, thanks a lot for this! I've successfully managed to get Codex to fix itself by linking it your repo and it compiled a brand new codex.exe and autonomously replaced it and after a quick app restart mobile remote control was working flawlessly! That was one of the most meta sessions I've had with Codex so far, so it was quite fun to try.

I know right! The meta! Glad it worked for you too.

This thread has multiple different failures that collapse into the same mobile message: "Waiting for desktop". That state should probably be split into more actionable cases: - platform unsupported or not yet enabled for this desktop build - desktop app installed but remote capability not advertised by app-server - remote-control daemon not running - daemon running but relay/backend unreachable - mobile has a stale host binding and is waiting for the wrong host Right now users are trying CLI commands, desktop updates, app reinstalls, proxy fixes, and source patches because the UI does not say which layer is missing. Even a read-only diagnostic panel showing host id, platform support, daemon status, relay registration, and last backend heartbeat would make this much less opaque.

I tried to keep my patch thin enough to expose my windows desktop to my mobile. I saw a sidebar item appearing on macos users screenshot, but never saw that here, despite achieving the remote control.

There's definitely intermitterent connectivity issues, weird parsing errors, room for improvement, but i believe they want external contribs to come in piecemeal anyways.

Adding one more concrete root cause for the same visible Waiting for desktop... symptom.

In my case this was macOS Codex Desktop + iOS ChatGPT, and the phone kept waiting even after scanning the QR code and tapping Connect. The desktop setup screen looked normal.

The useful diagnostic was the remote-control daemon stderr log:

~/.codex/app-server-daemon/app-server.stderr.log

The daemon was running and could reach the backend, but enrollment was being rejected:

failed to connect to app-server remote control websocket: wss://chatgpt.com/backend-api/wham/remote/control/server
remote control server enrollment failed at `https://chatgpt.com/backend-api/wham/remote/control/server/enroll`:
HTTP 403 Forbidden
body: {"detail":"Multi-factor authentication required"}

So the mobile app was not the actual blocker. The desktop host was never fully enrolled with the remote-control backend because the ChatGPT account needed MFA.

What fixed it:

1. Enable Multi-Factor Authentication for the ChatGPT/OpenAI account.
2. Sign out of Codex Desktop and sign back in, completing the MFA flow.
3. Make sure the mobile ChatGPT app is using the same account/workspace.
4. Reopen Codex Desktop -> Codex mobile, generate a fresh QR code.
5. Exit the old Waiting for desktop screen on mobile and scan/connect again.

After that, the flow advanced to the expected connected/settings screen.

For anyone debugging this locally, codex remote-control start --json can also help distinguish cases. Before the MFA fix I saw the desktop daemon stuck in a connecting / timed-out state even though the process existed. The key clue was the daemon log's explicit Multi-factor authentication required backend response.

This is probably worth surfacing directly in the UI because Waiting for desktop currently hides several different failure modes: unsupported platform, daemon not running, proxy/backend reachability, stale enrollment, and MFA-required enrollment rejection.

Adding another confirmed Windows + iPhone repro.

Environment:

• Phone: iPhone with ChatGPT mobile app
• Desktop: Windows
• Codex desktop package: OpenAI.Codex 26.519.11010.0
• Bundled CLI: codex-cli 0.133.0
• GitHub/user-facing symptom: iPhone Codex shows Waiting for desktop / tells me to log in on desktop

Local diagnostics:

• codex login status reports: Logged in using ChatGPT
• codex doctor reports auth/network healthy with 0 failures
• Desktop Codex is signed in and usable locally
• Windows app shows no Set up Codex mobile option, no QR code, and no approval prompt
• codex remote-control start --json returns:

Error: codex app-server daemon lifecycle is only supported on Unix platforms

• winget upgrade --name Codex reports no available upgrade from configured sources

Expected:
The iPhone app should detect the signed-in Windows Codex host, or the Windows desktop app / mobile app should clearly state that this build cannot currently act as a mobile remote-control host.

This is not a login issue from the desktop side; local ChatGPT auth is already configured and healthy.

Adding a related Windows + iOS datapoint. In my case mobile remote control had worked before, but got stuck after the desktop-side paired phone entry was accidentally removed.

Current state:

• Codex Desktop on Windows shows no devices under Connections -> Control this computer.
• Discovery/control is enabled on the desktop.
• ChatGPT iOS still keeps the previous Codex Desktop host record and shows it as disconnected/offline.
• A fresh QR code from the desktop does not establish a new clean pairing.
• The iOS setup flow eventually fails with Setup failed / Couldn't finish secure setup. Try again.

So this may be another path into the same "Waiting for desktop" / no recoverable mobile pairing state: the desktop no longer recognizes the phone, but the mobile/account side still has a stale old host and there is no obvious way to forget it from iOS.

I put a focused patch for one Windows-side part of this here:

• Branch: https://github.com/alphastack1/codex/tree/codex/windows-remote-connections-config
• Draft PR in my fork: https://github.com/alphastack1/codex/pull/1
• Upstream compare: https://github.com/openai/codex/compare/main...alphastack1:codex/windows-remote-connections-config?expand=1

What it fixes:

The Windows desktop/mobile path depends on the app-server reporting that remote connections are available. remote_control was already known, but remote_connections was not accepted through the public feature/config enablement path. That means a Windows install could be signed in and locally configured, but the desktop app still would not expose the expected Connections/mobile state.

This patch adds remote_connections to:

• the Codex feature registry
• app-server experimental feature enablement
• the config schema as [features].remote_connections = true
• tests proving config/read exposes the flag

In my Windows + Android test, exposing that feature path was enough to make the missing Connections/mobile setup path appear, and then the phone could pair with the desktop.

What it does not fix:

This is not the whole Windows remote-control story. codex remote-control start can still fail on Windows with codex app-server daemon lifecycle is only supported on Unix platforms, so there is likely a separate follow-up needed for the Windows daemon/startup path. It also does not cover other causes of the same Waiting for desktop message, like MFA-required enrollment, proxy/backend reachability, or stale mobile host state.

So the patch is best viewed as a small prerequisite fix: make the app-server/config layer able to advertise remote_connections correctly, then fix the remaining Windows lifecycle/UI pieces on top of that.