Windows remote-control daemon spawns visible console windows for tool and MCP child processes

Summary

On Windows, the managed remote-control app-server daemon launches tool-runtime and MCP child processes in visible console windows. Starting or opening a session through codex agents produces a cascade of black windows for node_repl.exe, node.exe, codex-code-mode-host.exe, and configured stdio MCP commands.

This defeats the purpose of the headless daemon, steals focus, covers the desktop, and leaves users unsure whether closing a window will terminate tooling in the active session.

Environment

Windows 10 Pro x64, build 19045
Codex CLI standalone: 0.155.1
Installation: official Windows PowerShell standalone installer
Managed daemon executable: %USERPROFILE%\.codex\packages\standalone\releases\0.155.1-x86_64-pc-windows-msvc\bin\codex.exe
Terminal client: codex agents
Remote Control paired with ChatGPT Android

Reproduction

Install the official standalone Windows build.
Run:
```
codex remote-control start
```
Pair the Android client.
Run:
```
codex agents
```
Start or open an agent session with tool/MCP support enabled.
Observe multiple visible console windows appearing on the Windows desktop.

One configured stdio MCP makes the problem especially obvious:

[mcp_servers.x64dbg]
command = "npx"
args = ["-y", "mcp-remote", "http://127.0.0.1:3000/sse"]

The foreground window visibly contains:

npx mcp-remote http://127.0.0.1:3000/sse

Other visible window titles expose the bundled runtime paths for node_repl.exe and node.exe.

Verified process relationship

The newly-created visible processes are children of the managed daemon's app-server process:

codex.exe app-server --remote-control --listen unix:// --managed-daemon
  ├─ node.exe ...\@oai\cua-repl\bin\cua-repl.mjs
  ├─ node_repl.exe
  └─ codex-code-mode-host.exe

Their creation timestamps coincide with opening the session through codex agents.

Expected

A managed background daemon must launch its non-interactive helper processes and stdio MCP servers without allocating or showing console windows.

Actual

Several cascading console windows appear and remain visible. Closing them risks terminating the session's tool runtimes or MCP connections.

Impact

The advertised headless/terminal-only Remote workflow is disruptive on Windows.
Windows desktop focus and layout are disturbed whenever helpers start.
Users cannot safely distinguish disposable windows from processes required by the active session.
Configured MCP servers amplify the number of visible windows.

A screenshot demonstrating four overlapping helper consoles is available if maintainers need it.

Follow-up: the surrounding installer/lock behavior made this worse — timeline of one morning

Two more findings from the same session, since they compound the remote-control workflow problems:

1. The desktop app reinstall removes competing CLI installs.
After the console-window cascade made the daemon workflow unusable, the Windows desktop app was reinstalled. That process deleted the separately installed npm package (@openai/codex removed from %APPDATA%\npm, wrapper and node_modules gone) and the user PATH now points only at %LOCALAPPDATA%\Programs\OpenAI\Codex\bin. Reinstalling one component should not uninstall another one the user installed deliberately.

2. Thread locks outlive every client that could hold them.
After the reinstall and a force-close of the desktop app, previously-open conversations report the equivalent of "open in another app" in the CLI and can no longer be opened there — with zero codex/app-server processes left running (verified via process listing). The lock state survived the death of the desktop app-server, the daemon, and every TUI.

3. For completeness: codex remote-control start cannot detach from a Job Object host ("host Job Object prevents daemon detachment; start from a host that allows breakaway") — reproducible from any CI/agent-style shell that runs children inside a Job Object. Works around it by creating the process via WMI (Win32_Process.Create), which escapes the job.

Net result of following the documented Remote workflow to the letter this morning: working npm CLI gone, desktop app reinstall destructive, daemon unusable on a real desktop because of the window cascade, and thread locks that survive the death of all clients. The Remote feature set is promising — the Windows packaging currently destroys the user's existing setup on the way to delivering it.

I can reproduce a similar issue with Codex CLI on Windows.

Environment

OS: Windows
Codex CLI: 0.157.0
Installation: global npm installation (@openai/codex)
Shell: Git Bash
MCP servers configured include Context7, Playwright, and Supabase

What happens

When I start Codex CLI from Git Bash, multiple visible cmd.exe windows open automatically.

Codex itself continues to work normally.

I initially observed this while using Codex from a Git Bash terminal inside VS Code. However, I was also able to reproduce the same behavior by closing VS Code completely, opening Git Bash directly, and starting Codex from there.

Because of this, the issue does not appear to depend on VS Code's integrated terminal.

Process observation

I inspected the running Windows processes while the issue was occurring.

Multiple cmd.exe processes were associated with startup of configured MCP servers using npx, including MCP servers for:

Context7
Playwright
Supabase

Some MCP startup processes also appeared to create additional cmd.exe child processes.

I have intentionally omitted full command lines, local paths, project identifiers, environment variables, tokens, and other configuration details from this report because they may contain sensitive information.

Expected behavior

MCP servers and other non-interactive Codex child processes should start in the background without creating visible console windows.

Actual behavior

Starting Codex causes multiple persistent visible cmd.exe windows to appear on the Windows desktop.

Codex remains usable, but the additional console windows are distracting and make it unclear whether they are required for the active session.

Additional information

I am currently using Codex CLI 0.157.0, which is the latest npm version available in my environment at the time of testing.

I can provide additional sanitized process information if it would help with debugging.

I have the same issue, please fix it.

Have the same issue, using CLI 0.157.0. Closing the %userprofile%.codex\packages\ etc. window immediately makes Codex open a new one.

I’m also seeing this on Windows while using Codex through VS Code. It started after a recent update; the previous version did not behave this way.

My managed app-server is running Codex 0.157.0. Tool/MCP startup opens unwanted Windows Terminal windows with titles including:

node_repl.exe
codex-code-mode-host.exe
My Substance Painter MCP’s .venv\Scripts\python.exe

The Node runtime is under %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node..., and the managed app-server is under %USERPROFILE%.codex\packages\app-server-daemon\releases\0.157.0-x86_64-pc-windows-msvc\bin.

This affects both bundled Codex helpers and a third-party MCP, and happens during normal tool use. These background processes should run without opening visible terminal windows.

fix here #48029

I can reproduce this on Windows 11 23H2 (build 22631.3880) with Codex CLI 0.157.0 installed through npm. After updating and opening a CLI session while the managed app-server is running, four blank Windows Terminal windows remain open. Their title paths identify two processes under AppData\Local\OpenAI\Codex\runtimes\cua_node, one C:\Windows\system32\cmd.exe, and one ~\.codex\packages\app-server-daemon\....

The process tree confirms that these are not extra CLI instances. The CLI has one node.exe -> codex.exe chain. Separately, the managed codex.exe app-server --listen unix:// --managed-daemon starts:

codex.exe app-server --listen unix:// --managed-daemon
|- node_repl.exe
|  `- conhost.exe
|- node.exe ...\@oai\cua-repl\bin\cua-repl.mjs
|  |- conhost.exe
|  `- node_repl.exe
|- cmd.exe /c "...\codegraph.cmd serve --mcp"
|  `- conhost.exe
`- codex-code-mode-host.exe
   `- conhost.exe

The helper processes appeared about one second after the CLI session started. The managed app-server had already been running for about a minute. The visible windows are empty and cover the desktop; closing them may terminate tool runtimes or MCP connections. I expected the managed daemon to launch these non-interactive children without visible terminal windows.

Configured stdio MCP servers: codegraph and node_repl. The screenshot and process command lines are available if useful. This also overlaps with #37599 for the Code Mode host window.

Additional observation from the same Windows 11 / Codex CLI 0.157.0 setup: the visible console windows are not limited to session startup. During an active session, each local tool invocation appears to open another command-line window. This makes the issue recurrent throughout a turn, rather than only a one-time burst when MCP servers initialize.

I have not yet captured the process ancestry of each transient per-tool window, so this is an observed symptom rather than a claim that every one has the same parent process. #48029 covers short-lived git.exe windows at turn start; the earlier screenshot and process capture here also included persistent windows for node_repl, the codegraph.cmd MCP launcher, and codex-code-mode-host.exe.

Confirmed workaround on the same Windows 11 machine with Codex CLI 0.157.0: starting the CLI normally reproduces visible command-line windows during local tool calls, while starting a new session with codex.cmd --no-daemon does not produce those windows. This A/B result points to the shared managed-daemon path rather than the CLI tool commands themselves.

Additional diagnostics: 0.157.0, Windows 10 build 19045, npm installation

The user reported that unwanted console windows appeared after upgrading Codex CLI and using it in VS Code's integrated terminal. Live inspection confirms the same helper-window pattern as this issue.

Environment verified locally

Windows 10 Pro for Workstations, version 10.0.19045, x64.
Global npm installation of @openai/codex.
codex --version: codex-cli 0.157.0.
codex app-server daemon version: status running; CLI, managed package and app-server versions all 0.157.0.
daemon_auto_start, code_mode_host, computer_use, browser_use and plugins are enabled.
A stdio node_repl MCP entry points to Codex's bundled cua_node runtime; browser/computer-use plugins are enabled.

Observed process and window evidence

Five persistent, non-empty MainWindowTitle entries were observed for helper processes:

Two node.exe windows.
Two node_repl.exe windows.
One codex-code-mode-host.exe window.

All five helpers had the same direct parent: the managed daemon's codex.exe under:

%USERPROFILE%\.codex\packages\app-server-daemon\releases\0.157.0-x86_64-pc-windows-msvc\bin\codex.exe
  |-- node.exe
  |-- node_repl.exe
  |-- codex-code-mode-host.exe
  |-- node.exe
  \-- node_repl.exe

The Node helper window titles point to %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\<runtime-id>\bin\. Each visible helper also has a conhost.exe child. The user's screenshot shows overlapping blank console windows obscuring VS Code.

Expected: Non-interactive internal runtimes and stdio MCP helpers run without visible console windows, while retaining their pipe communication and lifecycle behavior.

Impact: Persistent windows cover the editor and interrupt normal desktop work. Closing them is an unsuitable workaround because they are active tool-runtime processes.

Scope of verification: The version, enabled features, process ancestry, window titles and daemon state above were checked on this machine. The precise spawning-code defect has not been independently confirmed. A local A/B test with --no-daemon has not been performed; the successful test in the earlier comment is from another reporter.

Local usernames, project paths, full command lines, credentials and the project-bearing screenshot have been omitted.

Additional confirmation: official standalone installer, CLI 0.157.0, Windows 11

I can reproduce this after updating with the official PowerShell installer:

irm https://chatgpt.com/codex/install.ps1 | iex

Environment

Windows 11 x64, build 26200
Codex CLI: 0.157.0
Installation: official standalone installer
CLI path: %LOCALAPPDATA%\Programs\OpenAI\Codex\bin\codex.exe
Managed daemon: running; CLI, managed package, and app-server versions all report 0.157.0
Sandbox configuration: sandbox_mode = "workspace-write" and [windows] sandbox = "elevated"
Windows Terminal: 1.24.11911.0
Feature state: daemon_auto_start = true

Controlled delayed reproduction

A short two-second diagnostic initially missed the problem because the windows do not appear immediately. In a controlled run, the standalone codex.exe started as a child of pwsh.exe at 09:00:32.614. The helper processes and console windows appeared at 09:00:53.67–09:00:55.05, about 21 seconds later:

codex.exe 0.157.0
├─ node.exe        (%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\...\bin)
│  ├─ conhost.exe
│  └─ node_repl.exe
├─ node_repl.exe   (%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\...\bin)
│  └─ conhost.exe
└─ cmd.exe
   ├─ conhost.exe
   └─ node.exe
      └─ cmd.exe
         └─ node.exe

Three new OpenConsole.exe processes from the Windows Terminal package were created in the same 100 ms interval as the first node.exe, node_repl.exe, and cmd.exe children. This timing directly correlates the visible terminal windows with delayed CLI helper initialization.

A/B isolation: managed daemon vs. no daemon

A second controlled session was started with:

codex --no-daemon

After waiting 30 seconds, the same helper types were running (node.exe, node_repl.exe, and cmd.exe), but they did not receive separate conhost.exe children and no new OpenConsole.exe or Windows Terminal processes appeared. They remained attached to the CLI's existing console. The session was then exited normally.

This isolates the visible-window regression to the managed-daemon spawn path rather than the sandbox mode, individual MCP implementations, or helper executables themselves. Windows Terminal is the configured console host, but it is exposing console allocations made by the daemon path; it is not the initiating process.

The installed CLI exposes both a per-run workaround, codex --no-daemon, and a persistent feature switch, codex features disable daemon_auto_start.

This confirms the regression is not limited to npm installs or the explicit remote-control start flow. It occurs with the official standalone 0.157.0 CLI and the preferred elevated Windows sandbox.

Expected: Internal tool/MCP helpers run in the background without allocating or displaying console windows.

Full command lines, environment values, usernames, tokens, local project paths, task identifiers, and log contents were intentionally omitted.

Here is a polished version suitable for a GitHub issue or support ticket:

After upgrading Codex CLI to version 0.157.0 on Windows, visible console windows started appearing when Codex launches child processes.

Initially, I suspected lifecycle hooks, but that does not appear to be the cause. No hooks are currently installed or active.

I also tested the following:

Running Codex with --no-daemon does not prevent the windows from appearing.
Disabling code_mode_host does not prevent the issue either.
One of the visible windows was identified as:

C:\Users\<user\AppData\Local\Microsoft\WinGet\Packages\astral-sh.uv_...\uvx.exe

In my configuration, Serena is registered as a stdio MCP server:

[mcp_servers.serena]
command = "uvx"
args = [
    "--from",
    "git+https://github.com/oraios/serena",
    "serena",
    "start-mcp-server",
    "--context",
    "codex",
    "--project-from-cwd",
    "--open-web-dashboard",
    "false"
]
startup_timeout_sec = 30.0
tool_timeout_sec = 30.0

This strongly suggests that Codex is spawning stdio MCP child processes on Windows in a way that allows their console windows to become visible.

Before upgrading to Codex CLI 0.157.0, the same setup did not produce visible console windows.

Expected behavior:

Codex should launch background stdio MCP processes without creating visible console windows on Windows.

Actual behavior:

Console windows for child processes such as uvx.exe, and in some cases cmd.exe or PowerShell, briefly appear during normal Codex operation.

Environment:

OS: Windows
Codex CLI: 0.157.0
MCP transport: stdio
Example MCP server: Serena via uvx

This appears to be a regression or a change in process spawning behavior introduced or exposed by the recent Codex update.

Also reproducing on Windows 11 Pro with Codex CLI 0.157.0 after updating. Launching plain codex announces the background daemon and opens three helper/MCP console windows. During subsequent tool use, additional console windows appear briefly, steal keyboard focus, and disappear, making the CLI effectively unusable.

Process inspection shows node_repl.exe, node.exe, and wmcp.exe (my three configured mcp servers) under the managed 0.157.0 app-server daemon, with separate console hosts. Older still-running CLI sessions do not show that pattern.

I tested codex --no-daemon as a workaround and the issue doesn't happen anymore.

I can confirm the same issue on Windows with Codex CLI 0.157.0.
Starting Codex normally opens several additional visible console/Windows Terminal windows. When I start Codex with codex --no-daemon, the problem completely disappears.
So in my case the issue is clearly related to the background daemon/server path. --no-daemon is currently a working workaround.

Still reproducible for me on Codex CLI 0.157.1 on Windows.
In normal Codex CLI usage, PowerShell/console windows repeatedly pop up whenever Codex runs commands/tools.
I did not have this problem on 0.155.0. It started after upgrading to 0.157.1. Downgrading to 0.155.0 avoids the issue for me.

Same here, very annoying.

It keeps on spawning and closing CMD Windows all over the place. Also it keeps a CMD window open for my Chrome Devtools MCP...

Weird to see that the "--no-daemon" option has to be explicitely added from the user end if the Daemen-"version" is so buggy. Would be very welcomed to fix this issue.

This feature is so incredibly buggy. Will need to use a Powershell Alias to always run in "--no-daemon" mode as of now :(

Powershell command to add an Alias to avoid using the feature as of now:

$codexFunction = @'
# codex no-daemon wrapper
function codex {
    if ($args.Count -gt 0 -and $args[0] -eq 'resume') {
        $resumeArgs = @()

        if ($args.Count -gt 1) {
            $resumeArgs = $args[1..($args.Count - 1)]
        }

        & codex.cmd resume --no-daemon @resumeArgs
    }
    else {
        & codex.cmd --no-daemon @args
    }
}
'@

$documents = [Environment]::GetFolderPath('MyDocuments')

foreach ($shell in 'PowerShell', 'WindowsPowerShell') {
    $profileDirectory = Join-Path $documents $shell
    $profilePath = Join-Path $profileDirectory 'Microsoft.PowerShell_profile.ps1'

    New-Item -ItemType Directory -Path $profileDirectory -Force | Out-Null

    if (-not (Test-Path -LiteralPath $profilePath)) {
        New-Item -ItemType File -Path $profilePath | Out-Null
    }

    $alreadyInstalled = Select-String -LiteralPath $profilePath `
        -Pattern '# codex no-daemon wrapper' -SimpleMatch -Quiet

    if (-not $alreadyInstalled) {
        Add-Content -LiteralPath $profilePath `
            -Value ("`r`n" + $codexFunction) -Encoding UTF8
    }
}

Additional reproduction on Windows 11 (PowerShell, npm-installed Codex CLI):

With Codex CLI 0.157.1, using codex agents caused PowerShell/console windows to flash, and three extra terminal windows remained open.
I rolled the npm CLI back to 0.156.0. After exiting the CLI with Ctrl+C, codex doctor --json and Windows process inspection still showed a managed app-server daemon running from %USERPROFILE%\.codex\packages\app-server-daemon\releases\0.157.1-...\bin\codex.exe. The remaining processes included app-server --listen unix:// --managed-daemon and app-server daemon pid-update-loop.
The flashing continued with the 0.156.0 CLI until I closed all Codex processes and the three remaining terminal windows in Task Manager. On a clean 0.156.0 start, the flashing stopped.

I understand that a shared daemon may intentionally outlive Ctrl+C in one CLI client. The troublesome behavior here is the visible windows that remained open and the older 0.157.1 daemon continuing to run across a CLI rollback, with no clear indication that a full shutdown was needed.

I'm getting this - it's a right pain in the ****

Temp workaround, run the CLI with

codex --no-daemon

No popups, just like the good old days.

I'm getting this - it's a right pain in the ****

Temp workaround, run the CLI with
codex --no-daemon
No popups, just like the good old days.

the workaround works. Powershell command to close the processes: taskkill /F /IM codex.exe

I can reproduce a similar issue on Windows when using Codex through the VS Code extension.

Environment

Windows
VS Code Codex extension: openai.chatgpt-26.930.41038-win32-x64

What happens

While Codex is running in VS Code, a console/terminal window periodically flashes for a short time ( about 6 to 10 seconds).

The flash appears to steal or disturb keyboard focus. This is especially disruptive when using a Chinese IME:

IME composition can be interrupted.
Pinyin letters may be committed directly into the Codex input box before they are converted to Chinese characters.
The caret sometimes jumps to the end of the input.
In some cases, several characters near the end of the input are unexpectedly deleted.

This makes it difficult to type longer prompts while Codex is working.

The issue still occurs after updating the VS Code extension to 26.930.41038.

Process information

While the issue is occurring, I can see the following Codex process:

Name            : codex.exe
ExecutablePath  : C:\Users\DELL\.vscode\extensions\openai.chatgpt-26.930.41038-win32-x64\bin\windows-x86_64\codex.exe
CommandLine     : ...\codex.exe -c features.code_mode_host=true app-server --analytics-default-enabled

There is also a conhost.exe whose parent process is this Codex process:

Name            : conhost.exe
ParentProcessId : <PID of the VS Code extension's codex.exe>
ExecutablePath  : C:\Windows\system32\conhost.exe
CommandLine     : \??\C:\Windows\system32\conhost.exe 0x4

I also see WindowsTerminal.exe and OpenConsole.exe running.

There is no managed Codex runtime under %USERPROFILE%\.codex\packages on this machine, so in this case the relevant Codex executable appears to be the one bundled directly with the VS Code extension.

Expected behavior

Background Codex helper processes and non-interactive tool processes should start without creating or flashing visible console windows and without stealing or disturbing input focus.

In particular, background process creation should not interrupt IME composition in the VS Code Codex input box.

This may be related to #37599, but I am seeing it specifically with the current VS Code extension (26.930.41038) and the extension-bundled codex.exe.

This report was written with the assistance of AI for wording and organization, based on my own observations and diagnostic output.

Navigation Menu

Repository navigation

Windows remote-control daemon spawns visible console windows for tool and MCP child processes #46949

Summary

Environment

Reproduction

Verified process relationship

Expected

Actual

Impact

Follow-up: the surrounding installer/lock behavior made this worse — timeline of one morning

Environment

What happens

Process observation

Expected behavior

Actual behavior

Additional information

Additional diagnostics: 0.157.0, Windows 10 build 19045, npm installation

Additional confirmation: official standalone installer, CLI 0.157.0, Windows 11

Environment

What happens

Process information

Expected behavior

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Windows remote-control daemon spawns visible console windows for tool and MCP child processes #46949

Description

Summary

Environment

Reproduction

Verified process relationship

Expected

Actual

Impact

Activity

lincob commented on Sep 21, 2026

Follow-up: the surrounding installer/lock behavior made this worse — timeline of one morning

Tomoya1921 commented on Sep 25, 2026

Environment

What happens

Process observation

Expected behavior

Actual behavior

Additional information

theDiverDK commented on Sep 25, 2026

kgbayer commented on Sep 25, 2026

madeforaworld commented on Sep 25, 2026

JRBusiness commented on Sep 25, 2026

Sa3ura commented on Sep 25, 2026

Sa3ura commented on Sep 25, 2026

Sa3ura commented on Sep 25, 2026

hacong86 commented on Sep 25, 2026

Additional diagnostics: 0.157.0, Windows 10 build 19045, npm installation

rbleattler commented on Sep 25, 2026

Additional confirmation: official standalone installer, CLI 0.157.0, Windows 11

sergeytolkachyov commented on Sep 25, 2026

kodybrown commented on Sep 25, 2026

tedmarcin commented on Sep 25, 2026

ReneesmeS commented on Sep 26, 2026

bjspi commented on Sep 26, 2026

bjspi commented on Sep 26, 2026

morfeus02 commented on Sep 26, 2026

WillCalderwood commented on Sep 26, 2026

brunoamancio commented on Sep 27, 2026

Floooorian-shi commented on Oct 4, 2026

Environment

What happens

Process information

Expected behavior

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions