Windows: codex app-server --managed-daemon 0.157.0 opens a visible console window for each stdio MCP server started via npx / .cmd #48023

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   windows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems

   mcpIssues related to the use of model context protocol (MCP) serversIssues related to the use of model context protocol (MCP) servers

   app-serverIssues involving app server protocol or interfacesIssues involving app server protocol or interfaces

   on Sep 25, 2026
2. github-actions commented on Sep 25, 2026

   

   github-actionsbot

   on Sep 25, 2026 – with GitHub Actions

   Contributor

   More actions

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

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

   Powered by Codex Action
3. Roman-Evseev commented on Sep 25, 2026

   

   Roman-Evseev

   on Sep 25, 2026 – with ChatGPT Codex Connector

   More actions

   Additional reproduction on Windows 11:

   • Codex CLI/app-server: 0.157.0
   • Terminal: Windows Terminal 1.24.11911.0
   • Shell: Windows PowerShell 5.1.26100.9168
   • Trigger: codex resume --all
   • Configuration contains multiple stdio MCP servers launched through Python, npx.cmd, and cmd.exe.
   • The same configuration worked for weeks before the 0.157.0 update.
   • After resuming a session, many visible console windows appear in a loop. They contain commands such as:
     C:\Users\User\src\TQMEnterprise\mcp-servers\.venv\Scripts\python.exe -u ...
   • Windows reports error 2147942632 / 0x800700E8 while launching the Python MCP process.
   • Process inspection showed approximately 141 MCP child processes under one Codex app-server process, followed by repeated MCP startup failed ... connection closed: initialize response messages.
   • Downgrading the CLI to 0.153.4 eliminates the visible-console-window storm with the same MCP setup.
   • ACLs were checked under the normal user account; the Python executable and MCP directories have Read & Execute permissions, with no Access Denied / error 5.
   • Removing one MCP entry did not resolve the behavior, so this is not specific to a single MCP server.

   Expected: stdio MCP child processes start hidden, without allocating visible Windows Terminal consoles, and failed starts do not enter a rapid restart loop.
4. JRBusiness commented on Sep 25, 2026

   

   JRBusiness

   on Sep 25, 2026

   More actions

   Codex version

   Codex App 26.915.4065.0; managed app-server daemon 0.157.0.

   Platform

   Windows 11 Pro, build 26200.

   What happens

   Sending a message in a Git repository opens several short-lived Windows Terminal windows. Their tab titles show git.exe. A process trace captured four new OpenConsole.exe instances at a turn start. The Codex app-server daemon launched Git metadata and status commands including rev-parse HEAD, remote -v, and status --porcelain.

   Steps to reproduce

   1. Open Codex App in a Git repository on Windows with Windows Terminal set as the default terminal application.
   2. Send a message to start a turn.
   3. Watch for transient Git terminal windows during turn startup.

   Expected behavior

   Background Git checks should run without creating or focusing terminal windows.

   Root cause and proposed fix

   codex-rs/git-utils/src/git_process.rs starts these commands through JobObject::spawn_contained. On Windows, the job-object spawn sets CREATE_SUSPENDED but does not set CREATE_NO_WINDOW. Its fallback clears creation flags to zero, so that path can also open a console.

   Proposed fix: JRBusiness/codex@67858bd. It combines CREATE_NO_WINDOW with the suspended job-object spawn and retains the no-window flag in the fallback. This is a fork commit because the repository's contribution policy does not accept external pull requests.

   Verification

   • A local Windows launcher using CREATE_NO_WINDOW ran the same turn-start Git checks with zero new OpenConsole.exe or Windows Terminal processes in the watcher. The upstream patch itself has not been deployed in the Codex App.
   • just fmt passed on the proposed patch.
   • just test -p codex-git-utils -p codex-utils-pty passed: 63 tests on Windows.
5. jmkinzer commented on Sep 26, 2026

   

   jmkinzer

   on Sep 26, 2026 – with ChatGPT Codex Connector

   Last edited by jmkinzer

   More actions

   Additional Windows reproduction: ongoing visible shell launches

   This is an active usability problem, not just a brief flash at startup. The user had more than 20 visible command-line windows open and reports that roughly two more visible shells continue to launch every minute during normal use.

   • Managed Codex app-server 0.157.0 was installed locally on 2026-09-25 at about 17:05 MDT; the daemon started at 17:05:46.
   • The active session was in an unrelated repository. A globally enabled plugin contributes several stdio MCP servers, and their background processes started as Codex sessions came up even though none of those tools was requested.
   • Process inspection showed repeated session-start clusters at 19:48, 20:18, and 21:10 local time. One plugin MCP launch chain was: Codex app-server -> uv -> Python MCP bridge -> cmd.exe /c npx.CMD -> Node -> cmd.exe /d /s /c -> Node server. A snapshot contained 10 live cmd.exe processes from these chains.
   • The same snapshot had 25 OpenConsole.exe and about 50 conhost.exe processes across the machine. These process counts do not prove that every host was a visible window. There was also a separate cluster of 17 reusable MSBuild workers with console hosts, so I am not attributing all windows to MCP startup.
   • The user's report of continued new windows every minute has not yet been tied to one exact child process or restart path. It should be investigated as an ongoing launch/visibility problem, not dismissed as one-time MCP initialization.

   Expected: Codex background commands and stdio MCP startup run without opening desktop terminal windows. An enabled plugin should not flood unrelated sessions with visible consoles. The behavior began on the day 0.157.0 was installed; the exact faulty launch path in the installed binary is not yet proven.
6. sporeshield commented on Sep 26, 2026

   

   sporeshield

   on Sep 26, 2026 – with ChatGPT Codex Connector

   More actions

   Additional reproduction from another Windows user after updating Codex earlier today: the visible console windows are effectively non-stop during normal VS Code/Codex work, flashing up and disappearing repeatedly rather than only at startup. Screenshots show ordinary project validation/database commands being surfaced as visible PowerShell/console windows, including:

   • npm exec tsc --noEmit
   • npm exec payload generate:types
   • npm exec payload migrate:status
   • npm exec payload migrate

   The user reports this behavior was not present before today's Codex update and only noticed it after returning to Codex after working in Claude. The windows appear briefly, disappear, and new ones continue appearing. This seems consistent with the ongoing shell-launch behavior already reported here, but importantly it is not limited to MCP startup or Git metadata commands: normal npm/Payload/TypeScript tool execution is visibly spawning consoles too.

   Expected: all of these non-interactive background commands should execute without opening/focusing desktop console windows.
7. ev4ndr0p commented on Sep 28, 2026

   

   ev4ndr0p

   on Sep 28, 2026 – with ChatGPT Codex Connector

   More actions

   Confirming this on Windows too. After updating to 0.157.0, Codex started opening a CMD window for almost every tool/function call. Rolling back to 0.156.1 fixed it immediately, and Codex is back to normal without --no-daemon.