Windows: Git probe error windows (0x800700E8) still recur when starting/resuming conversations on 0.159.0-alpha.7 after partial console fixes #48601

What version of Codex CLI is running?

0.159.0-alpha.7

What subscription do you have?

chatgpt pro 20X

Which model were you using?

gpt 6 astra

What platform is your computer?

No response

What terminal emulator and version are you using (if applicable)?

No response

Codex doctor report

What issue are you seeing?

This is not limited to the first conversation after starting Codex. It also happens when opening or resuming subsequent conversations while Codex is already running.

An isolated alpha test confirmed that the ordinary command-execution path improved: PowerShell commands completed without opening visible console windows. However, the Git-probe problem remains in actual conversation startup/resume.

This is very disruptive when using Codex on the same Windows workstation for other work. The recurring windows interrupt normal desktop use, and some remain open displaying an error after the underlying command has disappeared. Please prioritize a complete native Windows fix and include it in a stable release.

The environment where this was observed is:

An initial raw Unicode check failed because PowerShell used its native OEM output encoding. The same behavior was reproduced outside Codex. Re-running with the UTF-8 prefix used by Codex passed with the original expected text unchanged. This was not treated as an alpha regression.

The isolated test did not replace the real installation or restart existing sessions. Protected configuration, launcher and executable hashes remained unchanged, and the seven pre-existing Codex processes retained their identities and start times. The isolated app-server was stopped afterwards.

The scope of this successful test is limited: it exercised command execution through the standalone app-server. It did not validate authenticated conversation startup/resume, every internal Git lookup, or the VS Code extension.

The inspected alpha source supports the improvement: the shared child launcher applies CREATE_NO_WINDOW on Windows, and the pipe execution path uses that launcher. The flag is also present in 0.159.0-alpha.7. Tested alpha launcher, pipe execution path, current alpha launcher

Code inspection identified a separate Git launch path that still lacks equivalent no-console handling.

In 0.159.0-alpha.7:

• detect_fsmonitor_override() issues the exact config --null --get core.fsmonitor query shown in the error. Source
• LocalFsmonitorProbeRunner builds a tokio::process::Command, adds safe.bareRepository=explicit, and routes it through the Git-specific process runner. Source
• spawn_git_command() uses JobObject::spawn_contained(). Its fallback resets creation flags to 0. Source
• The job preparation applies CREATE_SUSPENDED, without CREATE_NO_WINDOW. Source

This is a concrete code-level candidate for the remaining visible-console behavior. It is not a complete runtime attribution of the reported popup: the parent PID was not captured at the instant that particular Git error window appeared, and the same Git-probe pattern also exists in the installed VS Code extension.

Two additional paths warrant review, although they were not individually reproduced in the isolated suite: PowerShell discovery/availability probes and the persistent PowerShell AST parser still use direct process launches without explicit no-window handling in the inspected 0.159.0-alpha.7 source. PowerShell probes, AST parser

Please complete the fix across internal Windows launch paths, not only ordinary shell-tool execution. In particular:

1. Ensure internal non-interactive Git probes and helpers launch without visible consoles.
2. Preserve the required no-console flags through job-contained launches and fallback paths.
3. Preserve stdout, stderr, exit codes, cancellation, timeouts and process-tree cleanup.
4. Add regression coverage for the first conversation, subsequent conversation starts, and resuming existing conversations while Codex remains running.
5. Exercise Git metadata probes with core.fsmonitor unset, disabled and enabled.
6. Verify absence of visible windows, focus changes and leftover error windows, then ship the correction in a stable release.

The successful ordinary-command test should not be taken as proof that conversation startup/resume is fixed. The remaining Git popup is still occurring in normal use and is genuinely disruptive.

This appears related to #46949, visible daemon child-process consoles, and #48036, console flashes after CLI 0.157.0, which was linked to that issue. The separate PowerShell parser path is tracked in #18984.

The VS Code extension was also running during the observations. Its backend is separate from the managed CLI daemon. A reproduction with the extension completely closed has not been established.
The current CLI/daemon alignment was verified after the update:
codex --version
codex-cli 0.159.0-alpha.7
Sanitized output from codex app-server daemon version:
{
"status": "running",
"managedCodexVersion": "0.159.0-alpha.7",
"cliVersion": "0.159.0-alpha.7",
"appServerVersion": "0.159.0-alpha.7"
}
The remaining problem can be observed during conversation startup/resume:

1. Run Codex CLI natively on Windows from a Git working directory.
2. Start or resume a conversation.
3. Observe an additional Windows Terminal error window for an internal Git command.
4. With Codex still running, open or resume another conversation.
5. The problem can recur; it is not restricted to the first conversation or initial application startup.
   After upgrading both CLI and daemon to 0.159.0-alpha.7, resuming a conversation produced this message:
   [erreur 2147942632 (0x800700e8) lors du lancement de `"git" -c safe.bareRepository=explicit config --null --get core.fsmonitor']
   Earlier, before that upgrade, another affected command displayed was:
   "git" -c safe.bareRepository=explicit -c core.hooksPath=NUL -c core.fsmonitor=false rev-parse HEAD
   These are internal Git inspection commands. In particular, config --null --get core.fsmonitor reads a configuration value; it does not change it.
   Windows error 0x800700E8 corresponds to Win32 error 232, ERROR_NO_DATA: “The pipe is being closed.” This identifies a pipe/console-launch failure, but does not establish which component closed the pipe first. Microsoft error-code documentation
   There is direct evidence that the ordinary command-execution path improved in alpha.
   On the earlier 0.157.1 daemon, a harmless command was executed through command/exec:
   Write-Output 'CODEX_READ_ONLY_WINDOW_PROBE'
   With tty: false:

• The command completed successfully with exit code 0 and the expected output.
• Native Windows window observation captured a new Windows Terminal window.
• The window had a non-zero size, approximately 1186 × 618, and became the foreground window.
• The window was subsequently confirmed to have disappeared.
  A comparable tty: true execution completed successfully without a new visible console window being observed.
  Next, 0.158.0-alpha.15.2 was tested using the official Windows npm package in an isolated temporary installation. Package integrity was verified against npm metadata. The test used a separate Codex home, configuration, caches, working directory and standalone app-server, with no credentials or real conversations.
  Isolated alpha scenario Functional result New visible console windows observed
  Plain PowerShell stdout Passed 0
  Stderr and intentional exit code 7 Expected output and exit code preserved 0
  Unicode output with Codex’s UTF-8 prefix Passed 0
  PowerShell launching a cmd.exe child Passed 0
  Command with a short wait and multiple outputs Passed 0
  PTY/TTY control case Passed 0

An initial raw Unicode check failed because PowerShell used its native OEM output encoding. The same behavior was reproduced outside Codex. Re-running with the UTF-8 prefix used by Codex passed with the original expected text unchanged. This was not treated as an alpha regression.
The isolated test did not replace the real installation or restart existing sessions. Protected configuration, launcher and executable hashes remained unchanged, and the seven pre-existing Codex processes retained their identities and start times. The isolated app-server was stopped afterwards.
The scope of this successful test is limited: it exercised command execution through the standalone app-server. It did not validate authenticated conversation startup/resume, every internal Git lookup, or the VS Code extension.
The inspected alpha source supports the improvement: the shared child launcher applies CREATE_NO_WINDOW on Windows, and the pipe execution path uses that launcher. The flag is also present in 0.159.0-alpha.7. Tested alpha launcher, pipe execution path, current alpha launcher
Code inspection identified a separate Git launch path that still lacks equivalent no-console handling.
In 0.159.0-alpha.7:

• detect_fsmonitor_override() issues the exact config --null --get core.fsmonitor query shown in the error. Source
• LocalFsmonitorProbeRunner builds a tokio::process::Command, adds safe.bareRepository=explicit, and routes it through the Git-specific process runner. Source
• spawn_git_command() uses JobObject::spawn_contained(). Its fallback resets creation flags to 0. Source
• The job preparation applies CREATE_SUSPENDED, without CREATE_NO_WINDOW. Source
  This is a concrete code-level candidate for the remaining visible-console behavior. It is not a complete runtime attribution of the reported popup: the parent PID was not captured at the instant that particular Git error window appeared, and the same Git-probe pattern also exists in the installed VS Code extension.
  Two additional paths warrant review, although they were not individually reproduced in the isolated suite: PowerShell discovery/availability probes and the persistent PowerShell AST parser still use direct process launches without explicit no-window handling in the inspected 0.159.0-alpha.7 source. PowerShell probes, AST parser
  Please complete the fix across internal Windows launch paths, not only ordinary shell-tool execution. In particular:

1. Ensure internal non-interactive Git probes and helpers launch without visible consoles.
2. Preserve the required no-console flags through job-contained launches and fallback paths.
3. Preserve stdout, stderr, exit codes, cancellation, timeouts and process-tree cleanup.
4. Add regression coverage for the first conversation, subsequent conversation starts, and resuming existing conversations while Codex remains running.
5. Exercise Git metadata probes with core.fsmonitor unset, disabled and enabled.
6. Verify absence of visible windows, focus changes and leftover error windows, then ship the correction in a stable release.
   The successful ordinary-command test should not be taken as proof that conversation startup/resume is fixed. The remaining Git popup is still occurring in normal use and is genuinely disruptive.
   This appears related to #46949, visible daemon child-process consoles, and #48036, console flashes after CLI 0.157.0, which was linked to that issue. The separate PowerShell parser path is tracked in #18984.

What steps can reproduce the bug?

1. Use Codex CLI natively on Windows in PowerShell/Windows Terminal, with a project located in a Git working directory.
2. Verify that both the CLI and the running managed daemon are on 0.159.0-alpha.7:
   codex --version
   codex app-server daemon version
   In my case, cliVersion, managedCodexVersion, and appServerVersion all report 0.159.0-alpha.7.
3. Start Codex and open a conversation, or resume an existing conversation.
4. Observe that an additional Windows Terminal window appears for an automatically launched internal Git command. The window displays:
   [erreur 2147942632 (0x800700e8) lors du lancement de `"git" -c safe.bareRepository=explicit config --null --get core.fsmonitor']
   I did not manually execute this Git command. It is triggered during conversation startup/resume.
5. With the daemon still running, start or resume another conversation. The issue can happen again for subsequent conversations. It is not limited to the first conversation after launching Codex, and restarting the application is not required for it to recur.
   Some error windows remain open after the underlying command has disappeared.
   Environment note: the Codex VS Code extension 26.5917.62051 was also open during these observations. I have not yet reproduced this with the extension completely closed, and I did not capture the parent PID of the specific Git process that produced the error window.

What is the expected behavior?

No response

Additional information

No response