[Windows ARM64][Remote Control] “Couldn’t update remote control availability” while same account works on x64

What version of the Codex App are you using?

Latest Microsoft Store Codex/ChatGPT Windows build available as of 2026-09-12. The problem has persisted across multiple app updates.

What subscription do you have?

Paid ChatGPT account.

What platform is your computer?

Affected host:

• Windows 11 ARM64
• Microsoft Surface Laptop 7
• Snapdragon X Elite

Control host:

• Windows x64
• Same ChatGPT account/workspace
• Remote Control works normally there

What issue are you seeing?

Remote Control cannot be enabled on Windows ARM64.

In:

Settings → Connections → Control this PC → Allow

the toggle fails and shows:

Couldn’t update remote control availability

On earlier attempts/builds the same ARM64 machine also showed:

Could not enable remote control. Please ensure only one instance of Codex is running.

Only one Codex instance is actually running.

The important control case is that the same Remote Control workflow works on Windows x64 with the same account/workspace. The failure appears specific to native Windows ARM64.

This has persisted across multiple Codex updates.

Historical observation / possible clue

On a previous occurrence on this ARM64 machine, the problem was recovered after manually starting the app-server/socket path. I no longer have the exact command from that session, but the behavior strongly suggested that the Desktop app had failed to bring up its local app-server IPC/socket automatically.

This may be relevant because there are already Windows/ARM64 and native-Windows app-server IPC reports involving socket failures:

• #36362 — Windows ARM64 local app-server IPC can break with EPIPE
• #24090 — native Windows codex app-server --listen unix:// can create a regular zero-byte .sock file instead of a working socket
• #35900 — Windows ARM64 Desktop instability while Remote Control is involved

There are also current generic Windows Remote Control reports with the same UI error, but those are x64 and do not capture the ARM64-vs-x64 contrast:

• #44384
• #44406
• #44402

Steps to reproduce

1. Install/update Codex Desktop from the Microsoft Store on a Windows 11 ARM64 machine (Surface Laptop 7 / Snapdragon X Elite).
2. Sign in to the same ChatGPT account/workspace that successfully uses Remote Control on a Windows x64 machine.
3. Open Settings → Connections → Control this PC.
4. Enable Allow / Remote Control availability.
5. Observe that the toggle rolls back and the UI shows:
   Couldn’t update remote control availability.
6. Repeat the same workflow on Windows x64 with the same account/workspace.
7. Observe that Remote Control works on x64.

Expected behavior

Windows ARM64 should start the local app-server/IPC transport required by Remote Control and successfully register the host, just like Windows x64.

Actual behavior

The ARM64 host cannot update Remote Control availability and never reaches the normal pairing/QR flow.

Suspected area

This is only a hypothesis, not a confirmed root cause.

The ARM64-specific failure plus the previous recovery after manually bringing up the app-server/socket suggests a possible failure in the local app-server lifecycle or IPC transport initialization on native Windows ARM64.

Useful areas to compare between x64 and ARM64 may include:

• app-server child-process architecture and packaged binary selection;
• creation/opening of $CODEX_HOME/app-server-control/app-server-control.sock;
• IPC transport selection on Windows ARM64;
• packaged native dependencies used by the Remote Control app-server path;
• whether the Desktop process successfully spawns and connects to the app-server before attempting Remote Control enrollment;
• whether a failed/stale IPC endpoint is incorrectly surfaced as the generic “only one instance” / “Couldn’t update remote control availability” error.

Additional information

The issue is reproducible specifically on Windows ARM64 while x64 works for the same user/account/workspace. Reinstalling/updating Codex and ensuring only one application instance is running does not resolve it.

I can provide ARM64 logs / process list / package architecture details if maintainers specify the preferred diagnostics.

Start by reproducing the failure on Windows ARM64 and comparing it with the working x64 workflow. Inspect the app-server lifecycle and the $CODEX_HOME/app-server-control/app-server-control.sock path, using related reports #36362, #24090, and #35900 as context. Done means Remote Control enables successfully on ARM64 and reaches the normal pairing/QR flow.