codex - 💡(How to fix) Fix Windows Desktop remote-control listener can stay on stale cached binary missing sandbox helper

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

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.

Root Cause

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.

Fix Action

Fix / Workaround

  • 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:

Workaround that fixed it

Code Example

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

---

[windows]
sandbox = "unelevated"

---

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

---

codex.exe

---

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

---

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

---

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

---

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

---

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

---

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
RAW_BUFFERClick to expand / collapse

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.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING