Windows: codex-code-mode-host opens a visible Windows Terminal window

What version of Codex CLI is running?

@openai/codex 0.147.0 (current npm latest at the time of filing).

Also observed while Codex Desktop 26.803.5235.0 was installed, but the visible window captured in this report identified the global npm package path, not the protected WindowsApps package path.

Subscription and model

This appears independent of subscription and model. It occurs when a local Code Mode tool call causes the standalone host process to be spawned.

Platform

Windows 11 x64
Version 10.0.26200, build 26200
Windows Terminal configured as the default terminal application

What issue are you seeing?

When the standalone Code Mode host is started from the Windows npm package, Windows Terminal opens a visible window whose command is the packaged console executable:

%APPDATA%\npm\node_modules\@openai\codex\node_modules\@openai\codex-win32-x64\vendor\x86_64-pc-windows-msvc\bin\codex-code-mode-host.exe

The window can remain open and requires manual closing. A live process/window capture correlated the following components in the same creation-time cluster:

codex.exe
  -> codex-code-mode-host.exe
     -> conhost.exe

OpenConsole.exe / WindowsTerminal.exe -> visible terminal window

The packaged codex-code-mode-host.exe is PE subsystem 3 (IMAGE_SUBSYSTEM_WINDOWS_CUI).

The current source starts the host in codex-rs/code-mode/src/remote_session/connection.rs, Connection::spawn():

codex/codex-rs/code-mode/src/remote_session/connection.rs

Lines 213 to 224 in 3aae5d8

    
           impl Connection { 
        
               pub(super) async fn spawn(host_program: &Path) -> Result<Self, ConnectionError> { 
        
                   let mut command = Command::new(host_program); 
        
                   #[cfg(unix)] 
        
                   command.process_group(0); 
        
                   let mut child = command 
        
                       .stdin(Stdio::piped()) 
        
                       .stdout(Stdio::piped()) 
        
                       .stderr(Stdio::piped()) 
        
                       .kill_on_drop(true) 
        
                       .spawn() 
        
                       .map_err(|error| ConnectionError::Spawn {

The command configures Unix process groups, stdio pipes, and kill_on_drop, but has no Windows creation flag before .spawn():

let mut command = Command::new(host_program);
#[cfg(unix)]
command.process_group(0);
let mut child = command
    .stdin(Stdio::piped())
    .stdout(Stdio::piped())
    .stderr(Stdio::piped())
    .kill_on_drop(true)
    .spawn()?;

Because the parent is a GUI/headless process and the child is a Windows console-subsystem executable, Windows can allocate the configured default terminal for it.

Steps to reproduce

Install @openai/codex@0.147.0 globally on Windows.
Configure Windows Terminal as the default terminal application.
Start a Codex session that uses local Code Mode.
Invoke a local Code Mode tool so the standalone host is created.
Observe a visible Windows Terminal window whose command is codex-code-mode-host.exe.

This may be easier to reproduce after terminating an existing long-lived host so the next tool call must create a fresh one.

Expected behavior

codex-code-mode-host.exe should run as an internal background helper without creating a visible terminal window or stealing focus. Its stdin/stdout/stderr protocol and exit behavior must remain unchanged.

Root-cause hypothesis and validated mitigation

A local proof of concept placed a Windows GUI-subsystem shim at the expected host path and retained the signed vendor binary as codex-code-mode-host.real.exe. The shim:

forwards all arguments;
inherits stdin, stdout, and stderr;
starts the real host with CREATE_NO_WINDOW;
waits for it and returns the same exit code.

Validation results:

shim -> codex-code-mode-host.real.exe: confirmed
stdin/stdout round trip: passed
exit-code propagation: passed
real host startup and EOF shutdown: passed
visible host Terminal windows: 0

Before the mitigation, the visible Terminal window identified codex-code-mode-host.exe. After forcing a fresh host start through the shim, no matching visible window was created.

The binary-replacement shim is only a diagnostic mitigation and is not proposed as the product fix. It is update-fragile and changes the packaged executable identity.

Suggested product fix

In Connection::spawn(), apply CREATE_NO_WINDOW (or the equivalent supported Tokio/Windows process option) to the host command on Windows before .spawn(), while preserving the existing pipe and lifecycle behavior.

Conceptually:

let mut command = Command::new(host_program);

#[cfg(unix)]
command.process_group(0);

#[cfg(windows)]
command.creation_flags(CREATE_NO_WINDOW);

A Windows regression test should verify both protocol behavior and absence of an allocated visible console for a freshly spawned host.

Related but not duplicate

Windows: hide command-safety PowerShell parser process to avoid pwsh.exe console flashes #18984 tracks the command-safety PowerShell parser console flash.
codex exec on Windows spawns a visible long-lived PowerShell helper window when launched headlessly #20510 tracks the long-lived PowerShell helper spawned by background codex exec.
[bug] Computer Use helper's black console briefly appears when a turn completes #33254 tracks the Computer Use turn-ended notifier console window.

Those issues involve different child executables. This report is specifically about the standalone codex-code-mode-host.exe spawn boundary.

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

Powered by Codex Action

Thanks for the duplicate check. I reviewed both candidates; this appears related, but not a duplicate.

Codex Windows PowerShell Console Flash #36560 is specifically the long-lived powershell.exe AST safety parser spawned from the command-safety layer. This report concerns the separate codex-code-mode-host.exe process, spawned by Connection::spawn() in codex-rs/code-mode/src/remote_session/connection.rs.
Windows desktop Codex flashes visible command-prompt windows during work #37153 reports the broader symptom of transient console windows from desktop command runners, but it does not identify codex-code-mode-host.exe or this spawn site.

The executable, lifetime/protocol, and source boundary are different. A fix limited to the PowerShell parser spawn in #36560 would not affect the Code Mode host spawn. Conversely, the proposed CREATE_NO_WINDOW change here belongs on the standalone host Command in Connection::spawn().

I am therefore leaving #37599 open as the precise Code Mode host case. It can be cross-linked with #37153 as one concrete cause of that broader symptom.

Corrected follow-up: below is the final acceptance evidence for the Codex Desktop-version-matched CLI build used to reproduce and mitigate #37599.

Exact version and source provenance

Codex Desktop: 26.803.5235.0
CLI bundled by that Desktop package: codex-cli 0.147.0-alpha.6.5
Local patched CLI: codex-cli 0.147.0-alpha.6.5
Exact upstream source: annotated tag rust-v0.147.0-alpha.6.5, resolving to commit 618b8e9

The patch's three preimage blob IDs match that tag exactly:

codex-rs/code-mode/src/remote_session/connection.rs: d08c8fbbc448...
codex-rs/shell-command/src/command_safety/powershell_parser.rs: 00b18af6f053...
codex-rs/shell-command/src/powershell.rs: 9730439bea31...

#37599-specific patch

The relevant Code Mode Host change is:

 let mut command = Command::new(host_program);
 #[cfg(unix)]
 command.process_group(0);
+#[cfg(windows)]
+command.creation_flags(0x08000000); // CREATE_NO_WINDOW
 let mut child = command
     .stdin(Stdio::piped())
     .stdout(Stdio::piped())
     .stderr(Stdio::piped())
     .kill_on_drop(true)
     .spawn()?;

The end-to-end validation patch also routes the long-lived PowerShell parser and PowerShell discovery probes through the existing Windows no-console helper. Those companion changes remove separate PowerShell popup surfaces; they are not being presented as the root fix for #37599.

The build was installed in an external versioned directory and selected through the supported CODEX_CLI_PATH override. No file under the signed/protected WindowsApps package was modified. The deployed codex-code-mode-host.exe is byte-for-byte identical to the Desktop-packaged host:

patched codex.exe SHA-256:
9447A8C9833C4402379B98A6434B779F618137DB69369196D3247BEC37894DD5

packaged and deployed codex-code-mode-host.exe SHA-256:
E1DD9FA70FEE2BAD00671EB9EF0089CF86CD1A9765CB9A4160082514D7399B95

Validation

The original build/acceptance run passed the focused Rust tests for the affected Code Mode and PowerShell launch paths, the release build, an App Server handshake, and five bounded top-level Windows Terminal observations.

After a full Desktop restart, I repeated the runtime read-back:

the running process chain is the external patched codex.exe -> codex-code-mode-host.exe;
the patched CLI still reports the exact Desktop-matched version;
the App Server initialize handshake returned successfully, exited 0, and produced no stderr;
a 30-second observation at 100 ms sampling recorded 223 samples, 0 visible window events, and 0 newly observed processes with a visible main window.

This is a validated local mitigation, not a claim that upstream is fixed. As of current main commit 355ee6c, Connection::spawn() still has no Windows creation flag, so #37599 should remain open.

I've seen this on Windows x64 using standalone Codex CLI 0.155.0 and 0.155.1, with the native local app-server daemon and local TUI without --remote.

The Code Mode host CREATE_NO_WINDOW fix already demonstrated in this issue worked when I applied it on my end. I used the release source, matching PDBs, and disassembly to apply edits to the parent CLI binary. The code-mode host binary itself was unchanged. The broader daemon workload also showed that there were separate launch sites. The initial helper edits removed the persistent windows, but brief flashes remained. A trace then identified frequent Git console events, covering the captured Git/job path and its fallback eliminated Git show events in the next capture. The remaining events coincided with short computer-use helper launches. Adding no-window to the legacy notification launcher eliminated the remaining observed flashes, which is discussed in #33254.

The important implementation detail for the related background paths is flag replacement. The shared job helper sets CREATE_SUSPENDED, while Git fallback resets creation flags to zero. A no-window flag set only at construction is therefore lost. The intended final flags are CREATE_NO_WINDOW | CREATE_SUSPENDED for contained startup and CREATE_NO_WINDOW for an unsuspended fallback, preserving job assignment/resume and process cleanup. This should be limited to noninteractive callers, and it should not be imposed on interactive TUI/ConPTY launches.

After all of the edits, I saw no flashes during ordinary messages or a broader tool workload. Two traces totaling about 180 seconds recorded zero console show events. There was one invisible pseudo-console creation during interactive terminal testing. The workload included concurrent shell/Git/Node/Python activity, Node REPL restart, large stdout/stderr output, nonzero exits, child cancellation, and interactive terminal I/O.

The attached python script demonstrates the underlying Windows behavior. From a detached parent, the original flags allocate a console. Setting no-window only initially still fails the suspended/fallback cases. Preserving it passes all four cases.

Source references from commit 88ef37c:

Still reproducible on Windows with Codex CLI 0.156.0 and the 0.156.1 app-server daemon (2026-09-23). I launch the CLI from PowerShell. A visible console window is titled %USERPROFILE%\.codex\packages\app-server-daemon\releases\0.156.1-x86_64-pc-windows-msvc\bin\codex-code-mode-host.exe; process inspection showed this host was started by the native codex.exe app-server daemon.

Changing Windows' default terminal application from Windows Terminal to Windows Console Host changed the window's appearance but did not suppress it. In an isolated test, starting Codex with --disable code_mode_host stopped the host window from appearing, but a simple request to list one file failed because the command tool returned code-mode host is disabled. Thus that flag is not a functional workaround.

This confirms the issue also affects the app-server-daemon packaged host in 0.156.1. Please launch the host without allocating a visible console while preserving its stdio protocol.

Additional reproduction on 2026-09-25; this remains present in Codex CLI 0.157.0 and the matching managed app-server daemon.

Environment:

Windows 10 Pro 22H2, build 19045.6466, x64.
Codex CLI 0.157.0, started in Git Bash inside Windows Terminal.
Windows Terminal 1.24.11911.0; Git Bash is the default Terminal profile.
[windows] sandbox = "elevated"; code_mode_host is enabled (the CLI reports it as a stable, enabled feature).
Managed daemon host path, sanitized: %USERPROFILE%\.codex\packages\app-server-daemon\releases\0.157.0-x86_64-pc-windows-msvc\bin\codex-code-mode-host.exe.

Observed:

With Windows Terminal selected as Windows' default terminal application, using Codex opens extra empty Terminal tabs, including one titled with the .codex\packages path.
Changing only the default terminal application to Windows Console Host does not fix the problem: it turns that tab into a separate persistent empty black console window. The window title explicitly identifies codex-code-mode-host.exe at the managed-daemon path above.
The Git Bash profile and Git for Windows version are unchanged by this toggle. The issue is the background host's visible console, not a Git Bash shell failure.

Expected: the local Code Mode host runs without any visible tab/window or focus theft. Switching terminal hosts is not a workaround. Screenshots of both presentations are available if useful.

@loveu8

I’m seeing the same issue from @loveu8 on Windows 11 Pro with Codex CLI 0.157.0.

In my case it’s much more disruptive than a single popup at startup:

launching codex can spawn an empty terminal window
using @ to search for files repeatedly spawns terminal windows
the windows then close again, sometimes rapidly
after a while it can result in multiple terminal windows appearing in quick succession
multiple terminal windows are also spawned and closed repeatedly during Plan mode while Codex is researching/analysing files and the codebase

codex doctor reports the background app-server as not running (ephemeral mode), so this does not appear to be caused by a persistent daemon.

This only started for me after updating to 0.157.0; I did not experience this behavior on the previous version I was using.

The symptoms seem consistent with codex-code-mode-host.exe being spawned without CREATE_NO_WINDOW on Windows, particularly when file search / local tool functionality is invoked.

At the moment this makes 0.157.0 effectively unusable for normal interactive CLI work on Windows.

This also is now happening to me after upgrading the Codex CLI from 0.156.1 to 0.157.0 but with a different internal binary.

C:\Users\ofek\AppData\Local\OpenAI\Codex\runtimes\cua_node\13827bafdc0b5422\bin\node_repl.exe:

2026-09-25.01-13-29.mp4

Occurs now after upgrading to 0.157.0

20260925-0621-55.1608326.mp4

I'm getting this now after updating to 0.157.0
I noticed this only happening if I launch Codex CLI on a git repo folder .. if the folder is not a git repo, it doesn't flash any terminal/cmd windows

it does also open a permanent codex-code-mode-host.exe window in 0.157.0

I found a workaround that makes codex not flash windows all the time kill all codex processes then start with codex --no-daemon

Its looks like running codex --no-daemon could be a potential workaround until this gets fixed as mentioned here #46949 (comment). It's not perfect but at least it's somewhat usable now.

Additional confirmation for the 0.157.0 managed per-user runtime: the host at %USERPROFILE%\.codex\packages\app-server-daemon\releases\0.157.0-x86_64-pc-windows-msvc\bin\codex-code-mode-host.exe is PE subsystem 3 (Windows Console). Process capture shows codex.exe app-server --listen unix:// --managed-daemon → codex-code-mode-host.exe → conhost.exe. The visible-terminal symptom is present in this environment; no host crash was observed. Installed VS Code extension version: 26.917.62051.

Thanks for the bug reports. This will be addressed in an upcoming release. In the meantime, codex --no-daemon should work around the problem.

@zm-oai

@zm-oai @etraut-openai Thanks! Could you please link the PR/commit so that I'd be able to test? The cause of my issue is slightly different so I want to be sure.

@getupkid

Additional data point on Windows, npm-installed CLI 0.157.0 + app-server daemon 0.157.0.

Visible console windows appear during requests for node.exe, node_repl.exe, cmd.exe and codex-code-mode-host.exe — some flash, some persist. So in 0.157.0 this isn't limited to the code-mode host.

Same machine, same projects:

0.157.0 with the shared daemon: affected
0.157.0 with --no-daemon (also tried with --sandbox read-only): no unwanted windows
CLI + daemon downgraded to 0.156.0, daemon enabled: no unwanted windows

Reboot, daemon restart, reinstalling 0.157.0 and app-server daemon update --from-cli did not help. In my case the daemon path in 0.157.0 is what triggers it, though @getupkid reports windows without a running daemon, so there may be more than one launch path involved. Currently staying on 0.156.0.

issue still persists on latest 0.157.1, why is this issue closed?

I updated to 0.157.1 also updated the daemon with the /daemon command in codex and confirmed it now runs 0.157.1

Result: The extra permanent daemon terminal window is now gone. But codex still opens/closes a lot of terminal windows when doing anything. like !git status for example.

So starting with codex --no-daemon still is required for it to be usable

fix this shit

Downgrading to 0.156.1 was the only plausible solution for me.

same here

Confirming this affects my Windows Codex CLI 0.157.0 installation as well. The extra terminal windows appear while Codex is working, across different folders (including outside any particular project), and repeatedly steal focus, making it difficult to use other Windows applications during a task. Please prioritize a fix or provide a clear user-facing workaround. I understand codex --no-daemon has been suggested in this thread; the default behavior remains disruptive.

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

Environment:

Windows 11 Home 25H2, x64
Codex CLI 0.156.0 installed via npm
Launched directly from PowerShell, outside Orca
Also reproduced when Codex is launched through Orca

Symptoms on 0.156.0:

a PowerShell/console window briefly appears during shell tool execution
the desktop visibly flickers
keyboard focus is stolen from the application I am using

Minimal reproduction:

Start Codex CLI from PowerShell in a Git repository.
Ask Codex:
"Do not modify any files. Run git status --short once and return only the result."
A visible PowerShell/console window appears and focus is stolen.

I captured the process with Process Monitor. The short-lived process was:

powershell.exe -NoProfile -Command "try { [Console]::OutputEncoding=[System.Text.Encoding]::UTF8 } catch {}
git --no-optional-locks status --short"

The process ran as:
DESKTOP-...\CodexSandboxOffline

So this is reproducible without Orca and appears to come from Codex's Windows sandbox/shell execution path.

I also tested a rollback:

0.156.0:

console flash: YES
screen flicker: YES
focus stealing: YES

0.155.0:

console flash: YES
screen flicker: YES
focus stealing: NO

So rolling back to 0.155.0 removes the most disruptive focus-stealing behavior, but the visible console flash still remains.

This makes it difficult to use Codex in the background while working in another application.

Expected behavior:
Non-interactive shell/tool child processes should run without creating a visible console window and must not steal foreground focus.

If useful, I can provide the Process Monitor capture and additional process-tree information.

why it keep closed, is impossible to work with codex since i cant even use my pc while codex is being used with 10+ agents using powershell commands rly interisting how a big company can push updates without check accessibility for all platforms MAINLY Windows, is frustrating theses few days even with codex --no-daemon the session is not persistent, it only persists within the created window, so, if my limit runs out and i need to continue with another account in the same session this problem persists cuz is other window.

I see it flashing console Windows all the time now.

Navigation Menu

Windows: codex-code-mode-host opens a visible Windows Terminal window #37599

What version of Codex CLI is running?

Subscription and model

Platform

What issue are you seeing?

Steps to reproduce

Expected behavior

Root-cause hypothesis and validated mitigation

Suggested product fix

Related but not duplicate

Exact version and source provenance

#37599-specific patch

Validation

2 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	impl Connection {
	pub(super) async fn spawn(host_program: &Path) -> Result<Self, ConnectionError> {
	let mut command = Command::new(host_program);
	#[cfg(unix)]
	command.process_group(0);
	let mut child = command
	.stdin(Stdio::piped())
	.stdout(Stdio::piped())
	.stderr(Stdio::piped())
	.kill_on_drop(true)
	.spawn()
	.map_err(\|error\| ConnectionError::Spawn {

Windows: codex-code-mode-host opens a visible Windows Terminal window #37599

Description

What version of Codex CLI is running?

Subscription and model

Platform

What issue are you seeing?

Steps to reproduce

Expected behavior

Root-cause hypothesis and validated mitigation

Suggested product fix

Related but not duplicate

Activity

github-actions commented on Aug 8, 2026

wstczyw commented on Aug 8, 2026

wstczyw commented on Aug 10, 2026

Exact version and source provenance

#37599-specific patch

Validation

bhill298 commented on Sep 21, 2026

yehsuf commented on Sep 23, 2026

loveu8 commented on Sep 25, 2026

getupkid commented on Sep 25, 2026

ofek commented on Sep 25, 2026

TechDudie commented on Sep 25, 2026

wikes82 commented on Sep 25, 2026

per-johansson-74 commented on Sep 25, 2026

2 remaining items

getupkid commented on Sep 25, 2026

MLJ0422 commented on Sep 25, 2026

etraut-openai commented on Sep 25, 2026

ofek commented on Sep 25, 2026

Kir-STR commented on Sep 25, 2026

wikes82 commented on Sep 26, 2026

per-johansson-74 commented on Sep 26, 2026

GabGodz commented on Sep 26, 2026

getupkid commented on Sep 26, 2026

natansalvadorligabo commented on Sep 26, 2026

DataScienceLondon commented on Sep 26, 2026

RycqA commented on Sep 27, 2026

GabGodz commented on Sep 27, 2026

Masterxilo commented on Sep 29, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions