›_ Codex Issues
Codex Issues / #25322

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

Open 💬 5 comments Opened May 30, 2026 by int48
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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.

View original on GitHub ↗

5 Comments

int48 · 2 months ago

Follow-up after more validation on the same machine:

After restarting the remote-control listener from the complete 7dea4a003bc76627 cache directory, a command initiated from mobile reached the Windows Codex session immediately and successfully executed a PowerShell directory listing.

I also validated the previously failing SCP path from a mobile-initiated Codex command. One detail that may be relevant for diagnostics: inside the sandboxed PATH, where scp / where ssh first returned .sbx-denybin\scp.bat and .sbx-denybin\ssh.bat, then the real bundled OpenSSH binaries. Calling the real binaries explicitly worked:

C:\Users\<user>\.codex\tools\openssh\scp.exe
C:\Users\<user>\.codex\tools\openssh\ssh.exe

The real transfer test copied a small file from Windows to a Linux host via SCP, verified it via SSH, and removed it again successfully.

So in this environment the remote/mobile failure was fixed by replacing the stale 14567 listener process; the SCP issue was then only a PATH/sandbox-wrapper confusion during testing, not a remaining network or auth problem.

For local prevention I added a small diagnostic helper that checks:

  • which process owns 127.0.0.1:14567
  • whether that process comes from the newest complete cached Codex binary directory
  • whether candidate cache directories contain codex.exe, codex-windows-sandbox-setup.exe, and codex-command-runner.exe

This reinforces the suggested product-side fix: Desktop startup/update should validate the remote-control listener's executable path and helper-file completeness, and restart the listener if it points to a stale/incomplete cache directory.

github-actions[bot] contributor · 2 months ago

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

  • #24034
  • #24755
  • #25012
  • #25317

Powered by Codex Action

Snailflyer · 2 months ago

This is a good example of "remote control connected" not being strong enough as a health signal.

For diagnostics I would make the remote-control listener identity first-class, ideally in codex doctor and in any mobile/desktop route health panel:

  • listener pid
  • listener executable path
  • cache directory id
  • cache completeness: codex.exe, codex-windows-sandbox-setup.exe, codex-command-runner.exe
  • desktop package version
  • CLI version reported by that listener
  • app-server generation
  • bound port
  • last mobile command id received
  • last command runner spawn result

Then mobile can distinguish:

  • connected to a current complete listener
  • connected to a stale listener
  • connected to a listener that cannot spawn helpers
  • connected to no listener

The important product invariant is that a control surface should report the route that will actually execute the next command, not just that some websocket is listening. That is the same invariant Faryo uses for its browser/mobile workbench over a tmux-backed live session:
https://github.com/Snailflyer/faryo

int48 · 2 months ago

Thanks, this framing matches what we saw locally: "remote control connected" was true in the weak sense that some websocket listener existed, but it was not the route that could successfully execute the next command.

I reviewed the duplicate suggestions:

  • #24034 looks conceptually closest: stale remote-control app-server versus the active/current CLI.
  • #25012 shares the windows sandbox failed: spawn setup refresh family.
  • #25317 is also related in the broader "live app-server holds stale helper path" class.
  • #24755 seems less directly related to this specific remote-control listener/cache issue.

The reason I think this issue is still useful as a separate Windows-specific report is the concrete failure mode: the listener on 127.0.0.1:14567 was running from a cached directory that had codex.exe but did not have the Windows sandbox helper files next to it. The mobile route was therefore connected to a listener that could not spawn codex-windows-sandbox-setup.exe.

A minimal product-side invariant might be:

If Desktop exposes a remote-control listener, the listener process must come from a complete runtime bundle, and the helper paths it will use for the next command must be resolvable before mobile reports the route as healthy.

For codex doctor, the most useful single-line diagnostic would be something like:

remote-control: listening on 127.0.0.1:14567, pid=<pid>, exe=<path>, bundle_complete=true|false, sandbox_helper=<path|missing>

That would have made this immediately obvious without burning a long debugging session.

zemeng5208 · 16 days ago

I maintain WinBridge Recovery for Windows Codex Desktop local runtime/state recovery: https://github.com/zemeng5208/winbridge-recovery

This is adjacent to the project's current scope in a useful way: the failure is not that the latest runtime bundle is missing, but that a live process is still bound to an older incomplete hashed Codex bin directory containing codex.exe without the helper set it later expects. That is the same class of version/provenance split WinBridge already checks for Browser/Computer Use runtime paths after Desktop updates.

v3.1.1 validates the current installed package plus the official CLI/helper set (codex.exe, codex-windows-sandbox-setup.exe, codex-command-runner.exe, etc.) and detects stale hash/version references before using them. A similar diagnostic for a remote-control listener should compare the listener executable path against the current complete runtime rather than treating “port is listening” as healthy.

I want to keep the boundary clear: WinBridge currently focuses on Browser/Chrome/Computer Use recovery and does not yet manage the Remote Control listener lifecycle or restart port 14567 automatically. So I would treat this issue as a strong candidate for extending its diagnostics, not claim that v3.1.1 already repairs every remote-control case.

The useful invariant is the same: never switch or keep a runtime active unless the exact referenced version/hash directory is complete and validated.