Windows CLI 0.157.1: Plain text messages trigger background Git queries and flashing terminal windows (--no-daemon avoids this)

问题摘要

Windows 上的 Codex CLI 0.157.1 在共享 daemon 模式中，发送一条纯文字消息也会短暂弹出多个 Windows Terminal 窗口。捕获到发送阶段的四条自动 Git 查询，以及回复结束时的 Computer Use 通知程序；该轮助手没有调用工具。新建 --no-daemon 对话的单轮纯文字对照没有弹窗。

关联 #44768（共享 daemon 启动 hooks／命令时弹窗）和 #33254（Computer Use 结束通知闪窗）。本报告补充的场景是：发送普通消息、没有助手工具调用时，daemon 自动执行的 Git 查询也伴随可见终端窗口。这可能与 #44768 共用根因，请按需要合并跟踪；本机尚未证明精确源码根因。

环境

Codex CLI：0.157.1，通过 npm 安装。
操作系统：Windows 11 x64。
使用终端：Warp，PowerShell 7；Warp 精确版本本次未记录。
闪出窗口所属程序：Windows Terminal 1.24.11911.0。
模型：gpt-6-astra。
实际处理会话的进程：%USERPROFILE%\.codex\packages\app-server-daemon\releases\0.157.1-x86_64-pc-windows-msvc\bin\codex.exe，PID 13884。
用户已关闭自定义 NatsuTerm 命令 hooks 和 prompt-pane Stop hook，但问题仍然存在。独立的顶层 notify 仍指向 codex-computer-use.exe turn-ended。没有将这些 hook 的禁用状态当作所有运行时自动动作均已禁用的证明。
没有额外运行 codex doctor；以下来自已有进程记录与一次受控捕获。

复现步骤与实际结果

在 Git 工作区中使用普通 Codex CLI 启动／恢复会话，连接共享 daemon。本次捕获来自已经运行的恢复会话，未声称全新配置也已复现。
启动 Process Monitor，仅显示 Process Create；另用 SetWinEventHook 监听顶层窗口 SHOW／HIDE／DESTROY，在回调中读取窗口 PID、窗口类、可见状态、cloaked 状态及矩形。
发送纯文字“弹窗测试 2”。该轮助手只回复文字，没有执行工具命令。
发送阶段出现四个瞬时终端窗口，回复结束附近再出现一个。

预期：自动 Git 元数据查询和结束通知应在后台完成，不应弹出交互式终端窗口。

进程创建证据

以下时间为同一次捕获的本地时间，日期为 2026-09-26，时区 UTC+8。命令仅省略了明确列在表后面的 Git -c 参数。

创建时间	创建者	子 PID	命令
12:36:58.6003312	daemon PID 13884	2800	`git rev-parse HEAD`
12:36:58.6096903	daemon PID 13884	32064	`git remote -v`
12:36:58.6183241	daemon PID 13884	33852	`git config --null --get core.fsmonitor`
12:36:59.5015174	daemon PID 13884	31624	`git status --porcelain`
12:37:08.3641531	daemon PID 13884	17880	`codex-computer-use.exe turn-ended`，通知载荷已省略

四条 Git 命令均带 -c safe.bareRepository=explicit；除 config 查询外，其余三条还带 -c core.hooksPath=NUL -c core.fsmonitor=false。它们执行的是 Git 查询，不是 NatsuTerm 观察程序或 PowerShell hook。

四个 Git 进程分别创建 Conhost.exe PID 31992、33308、33088、29324。Computer Use 辅助程序创建 Conhost.exe PID 2292。

同阶段系统通过 svchost.exe 激活 OpenConsole.exe -Embedding 和 WindowsTerminal.exe -Embedding。不能把系统激活的 Windows Terminal 伪写成 Codex 的普通父子进程关系。

实际窗口证据

下表为窗口监听结果；时间由事件 tick 换算，保留到毫秒作为近似值。五次 SHOW 均实时查询到 PID，IsWindowVisible=true、DWMWA_CLOAKED=0，窗口矩形大小为 1248 × 724，位置在屏幕内。窗口类均为 CASCADIA_HOSTING_WINDOW_CLASS。Process Monitor 中相同 PID 的可执行文件均为 Windows Terminal 1.24.11911.0 的 WindowsTerminal.exe。

SHOW 时间	窗口句柄	窗口所属 PID	隐藏／销毁时间
12:36:59.183	`0x110368`	32052	12:36:59.507
12:36:59.199	`0xA0980`	32052	12:36:59.569
12:36:59.229	`0x409A0`	32052	12:36:59.585
12:37:00.016	`0x609B6`	30292	12:37:00.258
12:37:08.873	`0x11098A`	33428	12:37:09.044

Git PID 32064／33852／31624 和通知进程 PID 17880 也出现 PseudoConsoleWindow 事件，但这些矩形为零，没有将它们计作肉眼可见的窗口。

daemon 日志同轮记录 12:36:58 turn/start，12:37:08 回复采样结束。捕获中另有桌面 App 发起的 Git，其创建时间始于 12:37:00.0229799，晚于上述四个发送阶段窗口的 SHOW 时间。

对照及证据边界

重启 Windows 后普通模式仍出现弹窗。
同版本使用 codex.cmd --no-daemon 新建对话，单轮纯文字交互没有弹窗。尚未用该模式验证全部工具调用或 Computer Use 功能。
已直接对应实际窗口句柄、宿主 PID 和可执行文件。Git／通知子进程与这些窗口的时间、数量和控制台活动一致，但没有逐个证明前三个窗口分别绑定哪个 Git PID。
尚未捕获对应启动调用的 CREATE_NO_WINDOW 等标志，也未对当前二进制定位到具体源码行；不把相关 issue 中的源码分析当成本机已验证结论。
原始通知命令可能包含会话内容，因此只发布上述脱敏摘要，不附完整命令行、环境或原始捕获文件。

English translation:

Issue summary

In shared daemon mode, Codex CLI 0.157.1 on Windows briefly opens multiple Windows Terminal windows even when sending a plain text message. The capture recorded four automatic Git queries during message submission, as well as the Computer Use notification program at the end of the response; the assistant did not call any tools during that turn. A control test with a single plain text turn in a new --no-daemon conversation produced no pop-up windows.

Related to #44768 (pop-up windows when the shared daemon launches hooks/commands) and #33254 (flashing windows from Computer Use end notifications). This report adds the following scenario: when sending an ordinary message with no assistant tool calls, Git queries automatically executed by the daemon are also accompanied by visible terminal windows. This may share a root cause with #44768; please consolidate tracking as needed. The exact source-code root cause has not yet been proven on this machine.

Environment

Codex CLI: 0.157.1, installed via npm.
Operating system: Windows 11 x64.
Terminal used: Warp, PowerShell 7; the exact Warp version was not recorded this time.
Application owning the flashing windows: Windows Terminal 1.24.11911.0.
Model: gpt-6-astra.
Process actually handling the session: %USERPROFILE%\.codex\packages\app-server-daemon\releases\0.157.1-x86_64-pc-windows-msvc\bin\codex.exe, PID 13884.
The user had disabled custom NatsuTerm command hooks and the prompt-pane Stop hook, but the issue persisted. The separate top-level notify still pointed to codex-computer-use.exe turn-ended. The disabled state of these hooks was not treated as proof that all automatic runtime actions had been disabled.
No additional codex doctor run was performed; the following is based on existing process records and one controlled capture.

Steps to reproduce and actual results

Start/resume a session using the regular Codex CLI in a Git workspace, connecting to the shared daemon. This capture came from an already running resumed session; no claim is made that this was also reproduced with a fresh configuration.
Start Process Monitor and show only Process Create; separately, use SetWinEventHook to listen for top-level window SHOW/HIDE/DESTROY events, reading the window PID, window class, visibility, cloaked state, and rectangle in the callback.
Send the plain text message “Pop-up test 2”. The assistant only replied with text during that turn and did not execute any tool commands.
Four transient terminal windows appeared during message submission, followed by another near the end of the response.

Expected: Automatic Git metadata queries and end notifications should complete in the background without opening interactive terminal windows.

Process creation evidence

The times below are local times from the same capture, dated 2026-09-26, in timezone UTC+8. The only omissions from the commands are the Git -c arguments explicitly listed after the table.

Creation time	Creator	Child PID	Command
12:36:58.6003312	daemon PID 13884	2800	`git rev-parse HEAD`
12:36:58.6096903	daemon PID 13884	32064	`git remote -v`
12:36:58.6183241	daemon PID 13884	33852	`git config --null --get core.fsmonitor`
12:36:59.5015174	daemon PID 13884	31624	`git status --porcelain`
12:37:08.3641531	daemon PID 13884	17880	`codex-computer-use.exe turn-ended`, notification payload omitted

All four Git commands included -c safe.bareRepository=explicit; the three commands other than the config query also included -c core.hooksPath=NUL -c core.fsmonitor=false. They were executing Git queries, not NatsuTerm observers or PowerShell hooks.

The four Git processes created Conhost.exe PIDs 31992, 33308, 33088, and 29324, respectively. The Computer Use helper created Conhost.exe PID 2292.

During the same period, the system activated OpenConsole.exe -Embedding and WindowsTerminal.exe -Embedding through svchost.exe. This system-activated Windows Terminal must not be misrepresented as having an ordinary parent-child process relationship with Codex.

Actual window evidence

The table below shows the window monitoring results; times were converted from event ticks and retained to the millisecond as approximate values. For all five SHOW events, the PID was queried in real time, with IsWindowVisible=true, DWMWA_CLOAKED=0, and a window rectangle of 1248 × 724 positioned within the screen. All window classes were CASCADIA_HOSTING_WINDOW_CLASS. In Process Monitor, the executable for each corresponding PID was WindowsTerminal.exe from Windows Terminal 1.24.11911.0.

SHOW time	Window handle	Window owner PID	Hide/destroy time
12:36:59.183	`0x110368`	32052	12:36:59.507
12:36:59.199	`0xA0980`	32052	12:36:59.569
12:36:59.229	`0x409A0`	32052	12:36:59.585
12:37:00.016	`0x609B6`	30292	12:37:00.258
12:37:08.873	`0x11098A`	33428	12:37:09.044

Git PIDs 32064/33852/31624 and notification process PID 17880 also produced PseudoConsoleWindow events, but their rectangles were zero-sized, so they were not counted as visibly displayed windows.

The daemon log recorded 12:36:58 turn/start for the same turn, with response sampling ending at 12:37:08. The capture also included Git processes launched by the desktop App, whose creation times began at 12:37:00.0229799, later than the SHOW times of all four submission-stage windows above.

Control tests and limits of the evidence

Pop-up windows still appeared in regular mode after restarting Windows.
With the same version, a new conversation started using codex.cmd --no-daemon produced no pop-up windows during a single plain text turn. Not all tool calls or Computer Use features have been tested in this mode yet.
Actual window handles, host PIDs, and executables were directly matched. The timing, count, and console activity of the Git/notification child processes are consistent with these windows, but which Git PID was associated with each of the first three windows has not been individually proven.
Flags such as CREATE_NO_WINDOW for the corresponding launch calls have not yet been captured, nor has a specific source-code line been identified for the current binary; source-code analyses in related issues are not treated as conclusions verified on this machine.
The original notification command may contain session content, so only the sanitized summary above is being published, without complete command lines, environment details, or raw capture files.

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

Windows: background Git checks open Terminal windows at turn start (fix commit) #48029
Windows: terminal windows repeatedly flash during requests after installing the Codex daemon #48074

Powered by Codex Action

Independent reproduction on Windows with npm-installed Codex CLI 0.157.1 and the 0.157.1 managed app-server daemon. The problem began immediately after accepting the CLI's npm update. Windows Terminal version: 1.24.11911.0; Windows build family: 10.0.26200, x64.

Visible terminal windows flash on every message submission, including repeated short plain-text messages, and also when the assistant runs shell tools. This reproduces after completely exiting the third-party terminal host and launching the CLI directly in Windows Terminal, so it is not limited to an embedded terminal.

A 90-second read-only process capture recorded 35 git.exe processes directly parented by the managed codex.exe daemon and 35 conhost.exe processes parented by Git. It also recorded 37 OpenConsole.exe -Embedding activations parented by the system's svchost.exe. These are counts across multiple submissions and diagnostic activity, not counts per message or a one-to-one mapping to visible windows.

Repeated command batches matched this report:

git -c safe.bareRepository=explicit -c core.hooksPath=NUL -c core.fsmonitor=false rev-parse HEAD
git -c safe.bareRepository=explicit -c core.hooksPath=NUL -c core.fsmonitor=false remote -v
git -c safe.bareRepository=explicit config --null --get core.fsmonitor
git -c safe.bareRepository=explicit -c core.hooksPath=NUL -c core.fsmonitor=false status --porcelain

This capture establishes process parentage and timing alongside user-observed flashes. It does not establish individual visible-window ownership or the Windows process-creation flags. We have not yet tested --no-daemon or a rollback on this machine. Raw traces are omitted because unrelated process command lines can contain private data.

Additional corroborating evidence from the same capture:

The managed daemon also launched codex-computer-use.exe turn-ended, and that helper spawned a conhost.exe child. This independently reproduces the notification-process chain described in the original report. The notification payload is omitted because it can contain session content. We did not establish a visible-window mapping for this helper.
All 35 directly daemon-parented Git processes in the capture had the same parent PID. A representative batch was observed at 18:07:51.635-18:07:52.045 on 2026-09-26 (UTC+09:30): rev-parse HEAD, remote -v, config --null --get core.fsmonitor, then status --porcelain. The same four-command batch recurred at 18:07:59.404-18:07:59.818.
Collection used periodic read-only Win32_Process snapshots via PowerShell/CIM, not Process Monitor or a window-event hook. Timestamps are observation times, and very short-lived processes may have been missed; the counts are captured observations, not an exhaustive process-creation log. The recorder ran hidden. The capture includes diagnostic shell activity as well as repeated user submissions.

The remaining useful local comparison is the same CLI version with --no-daemon, checking both a plain-text submission and a shell-tool call. Neither that comparison nor rollback has been completed on this machine, so no successful workaround is claimed here.

docs: upstream comment on console windows (openai#48356); cargo-sig.s…

Measured this on Windows 11 26200 with a harness that launches codex exec with DETACHED_PROCESS (no console, like the daemon) and counts visible top-level console windows during one real turn:

Build	New console windows per turn
0.157.0 stock	28
0.157.1 stock (includes #48138, #48238)	17
0.157.1 + the patch below	0 (several runs)

Root cause. A process with no console hands none to its children. So every console child it spawns without CREATE_NO_WINDOW allocates its own visible console. With 0.157.1 the remaining windows came from:

~10 git.exe per turn. turn_metadata.rs runs git_workspaces via spawn_git_enrichment_task: rev-parse HEAD, remote -v, and status --porcelain plus fsmonitor probes. analytics/src/reducer.rs runs a second remote -v on turn completion.
The SessionStart hook's powershell.exe.
codex-computer-use.exe.

--no-daemon avoids it because the in-terminal process has a console, which its children inherit.

Root-level fix. Fixing each spawn site one at a time keeps missing some. Once at startup, when GetConsoleWindow() is null, call AllocConsoleWithOptions (Windows 11 24H2+, resolved via GetProcAddress) with ALLOC_CONSOLE_MODE_NO_WINDOW. Save and restore any std handles the launcher set. Every child then inherits a windowless console.

It's a no-op on older Windows and for interactive launches, which already have a console. About 90 lines in cli/src/main.rs:
https://github.com/Superintelligent-Group/superintelligent-codex/commits/sig/0.157.1
(commit "cli: give console-less Codex a windowless console on Windows").

The window-count harness is scripts/e2e-codex-windows.ps1 on the sig/harness branch of that repo. With -Diagnose it groups the spawned process tree by parent.

Separately, spawn count. Caching the per-turn git metadata keyed on HEAD, ref, packed-refs and config contents cuts git spawns from 5 to 1 per turn after the first. Only status still runs, since no cheap signal proves the worktree is unchanged. That removes most of these spawns even where the console fix doesn't apply.

Additional reproduction from a second Windows machine (JVPrecision, 2026-09-27): a user launching codex from a new PowerShell terminal saw roughly ten focus-stealing Windows Terminal windows as soon as a prompt/task began. The visible tabs included the Codex cua_node runtime node.exe and another with repl in its path. The user reports the popups interrupt typing and make the computer unusable.

The active managed daemon was ~/.codex/packages/app-server-daemon/releases/0.157.0-x86_64-pc-windows-msvc/bin/codex.exe app-server --listen unix:// --managed-daemon (PID 39556). The npm CLI on PATH had reached 0.157.1, but the already-running daemon remained 0.157.0. Disabling the GSD SessionStart hook, browser/computer-use plugins, and node_repl did not resolve the prompt-time symptom; this aligns with the daemon-side process creation reported here. We did not capture per-window process ancestry, so the runtime names visible in tabs are observations, not a proven root cause.

We removed the global 0.157.x npm install and installed the official @openai/codex@0.155.0. codex --version and npm list -g both confirm 0.155.0; a fresh codex exec turn completed with the original SessionStart hook restored. Existing 0.157.0 daemon processes were left running to avoid disrupting active sessions, so interactive popup elimination on this machine is not yet confirmed. The temporary plugin and shell-tool changes were reverted. Please treat the focus-stealing windows as a usability regression, including when the user only submits a prompt.

Confirming this is still not fixed in 0.158.0 (npm install, Windows 11 26200, Windows Terminal 1.24 as default terminal), with two affected paths measured today (2026-09-28) using an EnumWindows watcher for new CASCADIA_HOSTING_WINDOW_CLASS/ConsoleWindowClass top-level windows plus a WMI process watcher:

1. Daemon git checks while the TUI sits idle — with an idle interactive TUI (no user prompt running), a visible console window titled C:\Program Files\Git\cmd\git.exe appeared roughly every 30–60 s. The caught window's client PID mapped to ~/.codex/packages/app-server-daemon/releases/0.157.1-x86_64-pc-windows-msvc/bin/codex.exe app-server --listen unix:// --managed-daemon — the same daemon-side git enrichment described above. Note the daemon binary was still 0.157.1 even though the npm CLI had already been updated to 0.158.0.

2. TUI shell-tool execs — sent a task asking for three separate echo commands; observed three powershell.exe -NoProfile -Command "try { [Console]::OutputEncoding=..." spawns from the TUI process and three visible windows, strictly 1:1, each window appearing 0.6–2.6 s after its spawn (window creation can lag the spawn by up to ~10 s in our captures, so a short watch window around the exec can miss the correlation).

Regression window: 0.156.1 is clean on the same test — three echo commands → 0 windows, no daemon spawned, clean startup (no probe burst). So this path regressed by 0.157.0 and both paths are still live in 0.158.0.

Auto-update trap: the CLI's startup update prompt defaults to option 1 ("Update now"), so 0.156.1 users get flipped onto this regression with a single Enter press. After updating, the updater also relaunches the session (codex resume ...), which immediately spawns the managed daemon again. check_for_update_on_startup = false did not suppress the check on my machine (consistent with #18543).

Workaround that survives: pin @openai/codex@0.156.1, pick "Skip" on the update prompt, and kill the daemon / rename the app-server-daemon/releases dir (or start with --no-daemon).

Confirmed on Codex CLI 0.157.1 through Orca's managed app-server daemon.

A minimal exec_command call opens a persistent blank PowerShell console:

command: echo CODEX_SHELL_REPRO_OK
requested shell: cmd
login: false
tty: false

The command succeeds, but a visible blank pwsh.exe window is created:

C:\Program Files\WindowsApps\Microsoft.PowerShell_7.6.6.0_x64__8wekyb3d8bbwe\pwsh.exe

The managed runtime is under:

%APPDATA%\orca\codex-runtime-home\home\packages\app-server-daemon\releases\0.157.1-x86_64-pc-windows-msvc\

This started after upgrading to 0.157.x and appears consistent with #37599. Because Orca launches the managed daemon, the CLI --no-daemon workaround is not directly available in this environment.

Likely the same root cause as #48826: background git queries go through codex-rs/git-utils/src/git_process.rs, which spawns via JobObject::spawn_contained — its shared prepare_suspended_spawn never sets CREATE_NO_WINDOW on Windows. Full diagnosis + fix: #48826 (comment)

We're using #48074 to track this, and we're working on a fix.

Navigation Menu

Repository navigation

Windows CLI 0.157.1: Plain text messages trigger background Git queries and flashing terminal windows (--no-daemon avoids this) #48356

问题摘要

环境

复现步骤与实际结果

进程创建证据

实际窗口证据

对照及证据边界

Issue summary

Environment

Steps to reproduce and actual results

Process creation evidence

Actual window evidence

Control tests and limits of the evidence

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Windows CLI 0.157.1: Plain text messages trigger background Git queries and flashing terminal windows (--no-daemon avoids this) #48356

Description

问题摘要

环境

复现步骤与实际结果

进程创建证据

实际窗口证据

对照及证据边界

Activity

github-actions commented on Sep 26, 2026

Issue summary

Environment

Steps to reproduce and actual results

Process creation evidence

Actual window evidence

Control tests and limits of the evidence

github-actions commented on Sep 26, 2026

binaryfire commented on Sep 26, 2026

Caerii commented on Sep 26, 2026

jonvickers commented on Sep 28, 2026

zawxdevildtt commented on Sep 28, 2026

gugonggu commented on Sep 28, 2026

ScienHAC commented on Sep 28, 2026

etraut-openai commented on Sep 29, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions