Windows mobile remote control gets stuck while codex.ps1 app-server proxy processes accumulate

What version of the Codex App are you using (From "About Codex" dialog)?

Codex App package observed from Windows package metadata: 26.623.9142.0

Installed package: OpenAI.Codex_26.623.9142.0_x64__2p2nqsd0c76g0

Codex CLI on PATH used by the generated proxy script: codex-cli 0.142.4

What subscription do you have?

Not captured in local diagnostics.

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

After pairing ChatGPT mobile with Codex Desktop on Windows, the mobile connection indicator can turn green while the project/conversation list never finishes loading.

On the Windows host, each reconnect/list attempt appears to create another powershell.exe running codex.ps1 app-server proxy; the proxy processes accumulate instead of exiting or being reused. This makes the mobile/remote-control app-server data plane look unhealthy even though the connection UI reports connected.

Sanitized local process evidence captured at 2026-07-01 12:49:46 +09:00:

ActiveProxyCount: 137
Oldest proxy process: 2026-06-30 22:48:33 +09:00
Newest proxy process: 2026-07-01 12:48:40 +09:00
Proxy processes working set: 11202.7 MB

The app-server control directory stayed stale/empty for the actual control/log files while codex-path and codex-proxy.ps1 kept being refreshed:

~/.codex/app-server-control/app-server-control.sock   length=0   LastWriteTime=2026-06-30 22:48:33 +09:00
~/.codex/app-server-control/app-server.log            length=0   LastWriteTime=2026-06-30 22:48:32 +09:00
~/.codex/app-server-control/app-server-error.log      length=0   LastWriteTime=2026-06-30 22:48:32 +09:00
~/.codex/app-server-control/stdin                     length=0   LastWriteTime=2026-06-30 22:48:32 +09:00
~/.codex/app-server-control/codex-path                length=44  LastWriteTime=2026-07-01 12:48:39 +09:00
~/.codex/app-server-control/codex-proxy.ps1           length=1403 LastWriteTime=2026-07-01 12:48:39 +09:00

Other observations:

• Codex Desktop processes were still running.
• chatgpt.com:443 and api.openai.com:443 were reachable from the host.
• Renderer/web storage continued updating around the same time.
• The Desktop main log did not receive matching fresh entries for the mobile list-loading failure, suggesting the failure may happen in the mobile/app-server proxy path rather than the normal Desktop UI request path.

What steps can reproduce the bug?

I do not yet have a minimal deterministic reproducer, but the observed sequence was:

1. Pair ChatGPT mobile with Codex Desktop on Windows.
2. Use the mobile Codex surface to access the paired Windows Codex Desktop host.
3. Observe intermittent disconnects.
4. Restart the mobile ChatGPT/Codex app; the connection can recover temporarily.
5. Later, observe that the Desktop connection indicator is green, but the mobile project/conversation list remains stuck loading.
6. On the Windows host, inspect proxy processes:

``powershell
Get-CimInstance Win32_Process |
Where-Object {
$_.Name -ieq 'powershell.exe' -and
$_.CommandLine -match 'codex\.ps1 app-server proxy'
} |
Measure-Object
``

1. Repeated attempts/reconnects show many long-lived codex.ps1 app-server proxy PowerShell processes instead of a single bounded proxy lifecycle.

What is the expected behavior?

• Mobile should not report the Desktop host as healthy until the app-server data plane can successfully serve project/thread list data.
• Windows proxy startup should be singleton/deduplicated per control socket or host.
• A failed or timed-out proxy probe should clean up its process tree and write a useful diagnostic to app-server-error.log.
• Reconnect/list attempts should not accumulate unbounded codex.ps1 app-server proxy processes.

Additional information

The generated ~/.codex/app-server-control/codex-proxy.ps1 contains a probe function that starts:

codex.ps1 app-server proxy

It closes stdin, reads stdout/stderr to the end, waits for process exit, and discards the output. If app-server proxy keeps running after stdin is closed, that probe can hang and leave a long-lived child proxy process. Repeated mobile reconnect/list attempts then appear to pile up more proxy processes.

Possible fix direction, intended as analysis rather than an unsolicited PR:

• Make the proxy health check bounded with a timeout.
• If the probe starts a child process and does not get a ready/failure signal in time, terminate that exact child process tree.
• Treat stdin EOF as a shutdown signal for codex app-server proxy, or avoid using a long-running proxy command as a synchronous probe.
• Keep one proxy per control socket/host instead of spawning a new unmanaged proxy for each reconnect/list attempt.
• Surface a data-plane health error when thread/list or equivalent mobile project/session listing cannot be served.

Related issues:

• #24730: ChatGPT mobile does not show Codex App SSH remote projects/sessions, while Mac host can
• #24542: Codex Desktop remote proxy respawns unmanaged app-server and blocks daemon bootstrap
• #23317: Mobile device list exposes Desktop-managed SSH remotes as Codex Desktop devices and can break mobile remote connections

This issue may share the same mobile/remote-control surface as #24730, but the Windows-specific proxy process accumulation is a separate observable failure mode and likely needs its own lifecycle guard.