Windows Desktop remote-control listener can stay on stale cached binary missing sandbox helper

Codex Windows remote-control listener can stay on stale cached binary missing sandbox helper

Summary

On Windows Codex Desktop, mobile/remote-triggered commands stopped reaching the active Windows session reliably after an update/restart cycle. Local Codex Desktop shell execution worked after restart, but commands initiated from mobile still failed or only appeared after restarting Codex Desktop.

Root cause in this environment was a stale remote-control app-server process still listening on 127.0.0.1:14567 from an older cached Codex binary directory. That stale cache directory contained codex.exe only and did not contain codex-windows-sandbox-setup.exe or codex-command-runner.exe.

As a result, remote-triggered shell commands hit:

setup refresh: failed to spawn codex-windows-sandbox-setup.exe: program not found

Restarting only the listener from the newest complete cached Codex binary fixed mobile -> Windows command execution.

Environment

• OS: Windows 11 x64
• Codex Desktop package observed: OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0
• Working cached CLI: codex-cli 0.135.0-alpha.1
• Current config workaround already set:

[windows]
sandbox = "unelevated"

Observed stale state

The remote-control listener was still bound to an older cached binary:

127.0.0.1:14567 -> C:\Users\<user>\AppData\Local\OpenAI\Codex\bin\958d608b5e0546a5\codex.exe
CommandLine: codex.exe app-server --listen ws://127.0.0.1:14567 --enable remote_control --analytics-default-enabled

That directory contained:

codex.exe

It did not contain:

codex-windows-sandbox-setup.exe
codex-command-runner.exe

The current complete cache directory contained all required files:

C:\Users\<user>\AppData\Local\OpenAI\Codex\bin\7dea4a003bc76627\
  codex.exe
  codex-windows-sandbox-setup.exe
  codex-command-runner.exe

Relevant sandbox log

From %USERPROFILE%\.codex\.sandbox\sandbox.log:

START: C:\Program Files (x86)\PowerShell\7\pwsh.exe -NoProfile -Command ...
setup refresh: spawning codex-windows-sandbox-setup.exe (cwd=..., payload_len=...)
setup refresh: failed to spawn codex-windows-sandbox-setup.exe: program not found

Workaround that fixed it

1. Find the remote-control listener:

Get-NetTCPConnection -LocalPort 14567 -State Listen |
  Select-Object LocalAddress,LocalPort,State,OwningProcess

1. Inspect the owning process:

Get-CimInstance Win32_Process -Filter "ProcessId=<pid>" |
  Select-Object ProcessId,ExecutablePath,CommandLine

1. If it points to an incomplete/stale cache dir, stop that listener process and restart it from the newest complete cached binary:

Stop-Process -Id <pid> -Force

Start-Process `
  -FilePath "$env:LOCALAPPDATA\OpenAI\Codex\bin\7dea4a003bc76627\codex.exe" `
  -ArgumentList @(
    'app-server',
    '--listen',
    'ws://127.0.0.1:14567',
    '--enable',
    'remote_control',
    '--analytics-default-enabled'
  ) `
  -WindowStyle Hidden

After this, mobile-triggered commands reached the Windows Codex session again and shell/SCP tests succeeded.

Suggested product-side fixes

• On Desktop startup/update, ensure the 14567 remote-control listener is not left running from an older cached binary.
• Before using a cached binary directory for app-server --enable remote_control, verify that the directory also contains codex-windows-sandbox-setup.exe and codex-command-runner.exe.
• If setup refresh logs program not found, include the resolved app-server executable path and expected helper path in the user-facing diagnostic.
• Add this to codex doctor: detect a remote-control listener running from a stale/incomplete cached binary.

Related but separate finding

This machine also previously hit setup refresh failures when TEMP/TMP resolved to a system temp junction. The stale listener issue above remained visible after local shell execution was fixed, so it appears to be a separate remote-control/update-cache problem.