Windows TUI render corruption in git repos triggered by core.fsmonitor=false git metadata call

[mir3626]

What version of Codex CLI is running?

Regression appears between 0.131.0-alpha.16 and 0.131.0-alpha.17.

Verified matrix:

• 0.130.0: normal
• 0.131.0-alpha.15: normal
• 0.131.0-alpha.16: normal
• a5040d0b3 (tui: split composer attachment and popup state): normal
• 8736e3265 (tests: avoid ambient temp sandbox roots) + CLI compile fix: normal
• 6ec8c4a6 (Ignore fsmonitor config in Git metadata reads) + CLI compile fix: reproduces
• 6ec8c4a6 + CLI compile fix with only .args(["-c", "core.fsmonitor=false"]) removed: normal
• 5a0296251: reproduces
• 0.131.0-alpha.17, .19, .20, .21, .22: reproduce
• 0.131.0, 0.132.0: reproduce

What subscription do you have?

Not relevant.

Which model were you using?

Observed in normal Codex TUI sessions; model does not appear relevant.

What platform is your computer?

Windows 11, PowerShell, Windows Terminal.

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

Windows Terminal.

What issue are you seeing?

In valid git repositories, the Codex CLI TUI can enter a persistent corrupted render state. Symptoms include:

• prompt input text visually disappears while the text is still present internally
• the working indicator/status text becomes clipped to one or two characters
• bottom status line disappears or remains stale after session exit
• cursor intermittently jumps to the next line/left edge during wraps
• resize/streaming output, Korean/CJK text, and IME use make the issue easier to notice, but IME is not required
• /resume does not reliably repair the visible TUI state

A key reproducer is that in a valid git repo, with no prompt typed, holding Backspace on an empty prompt can start corrupting the bottom status/prompt area. Non-git or invalid-git directories do not reproduce in the same environment.

Bisection result

The first triggering commit is 6ec8c4a6ecb17bc3ab10d0c5edf75494b50cab7e:

[codex] Ignore fsmonitor config in Git metadata reads (#22652)

The actual trigger is the single argument added in codex-rs/git-utils/src/info.rs:

.args(["-c", "core.fsmonitor=false"])

Evidence:

• Previous commit 8736e3265 + same unrelated CLI compile fix: normal
• 6ec8c4a6 + same compile fix: reproduces
• 6ec8c4a6 + same compile fix, but with the core.fsmonitor=false line removed: normal

The CLI compile fix mentioned above is only the later plugin CLI compile fix touching:

• codex-rs/cli/src/marketplace_cmd.rs
• codex-rs/cli/src/plugin_cmd.rs

It was needed only to build intermediate commits and is not on the TUI/git path.

Interpretation

This does not look like core.fsmonitor=false directly corrupts the terminal. It appears to change internal git metadata subprocess invocation/timing enough to consistently exercise an existing inline TUI renderer weakness around bottom-pane/status redraw and terminal buffer synchronization.

A local renderer patch in custom_terminal.rs that avoids redundant ClearToEnd on already-empty tail rows and hides the cursor earlier during frame flush mitigated the major symptoms in the same repro cases. That suggests the fsmonitor change is the trigger, while the persistent visual corruption is in the inline renderer/status redraw path.

Related issues

This overlaps symptom-wise with, but is not the same as:

• Inconsistent scrollback / output rendering behavior on Windows Terminal vs macOS terminal #15380 Windows Terminal scrollback/render inconsistency
• Output width remains truncated after resizing Codex CLI window back to full size #5576 output width remains truncated after resizing
• Windows: Korean IME preedit shows blanks or disappears only in Codex CLI #4870 Korean IME preedit blanks
• Permissions error with git fsmonitor #14372 git fsmonitor sandbox/IPC errors
• /review does not see any branches or commits after updating to 0.131 #23446 /review branch picker regression where comments also mention 6ec8c4a6
• v0.131 regression: codex starts in the wrong folder #23367 wrong cwd regression, which /review does not see any branches or commits after updating to 0.131 #23446 was closed as duplicate of

The distinct part here is the minimized regression trigger: 6ec8c4a6 and specifically .args(["-c", "core.fsmonitor=false"]).

What steps can reproduce the bug?

One minimized local repro used:

1. Windows Terminal + PowerShell.
2. A minimal valid git repository/worktree.
3. Codex TUI launched in that repo.
4. No prompt input required; hold Backspace on an empty prompt, or resize/stream output in the same session.
5. Observe prompt/status/footer rendering corruption.

A fake-git harness was also used to isolate the behavior from real repository content. Cases without a valid .git structure did not reproduce; valid git skeleton cases did.

What is the expected behavior?

Adding git -c core.fsmonitor=false ... to Codex's internal git metadata calls should not destabilize TUI rendering. Prompt input, status line, and streaming output should remain visible and correctly positioned across redraws, empty Backspace input, resize, and CJK/IME text.

Additional information

This was bisected locally because the bug was initially suspected to be a Windows Terminal/Korean/resize issue. The bisection showed that Korean/IME and resize are amplifiers, not required root conditions.

[github-actions]

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

• Bug: raw ANSI control sequences in Windows interactive CLI when cwd is a Git repo (`), but not when .git` is removed #23691
• Rendering is completely broken when git is detected #23628

Powered by Codex Action

[fcoury-oai]

This is very, very useful. Thank you.

[fcoury-oai]

Would you be able to run the following PowerShell script below to determine what git.exe Codex is using.

$ErrorActionPreference = "SilentlyContinue"

Write-Host "=== Git diagnosis ==="
Write-Host ""

$gitCommand = Get-Command git -ErrorAction SilentlyContinue
$gitPaths = @()

try {
    $gitPaths = @(where.exe git 2>$null)
} catch {}

if ($gitCommand) {
    Write-Host "PowerShell resolves git to:"
    Write-Host "  $($gitCommand.Source)"
} else {
    Write-Host "PowerShell could not resolve 'git' from PATH."
}

Write-Host ""
Write-Host "All git.exe found on PATH:"
if ($gitPaths.Count -gt 0) {
    $gitPaths | ForEach-Object { Write-Host "  $_" }
} else {
    Write-Host "  none"
}

Write-Host ""
if (-not $gitCommand) {
    Write-Host "Result: Git does not appear to be installed or is not on PATH."
    exit 0
}

$gitExe = $gitCommand.Source
$gitVersion = (& git --version 2>$null)
$gitExecPath = (& git --exec-path 2>$null)

Write-Host "git --version:"
Write-Host "  $gitVersion"

Write-Host ""
Write-Host "git --exec-path:"
Write-Host "  $gitExecPath"

Write-Host ""
Write-Host "Executable details:"
Write-Host "  Path: $gitExe"

try {
    $file = Get-Item $gitExe
    $versionInfo = $file.VersionInfo

    Write-Host "  File version: $($versionInfo.FileVersion)"
    Write-Host "  Product version: $($versionInfo.ProductVersion)"
    Write-Host "  Product name: $($versionInfo.ProductName)"
    Write-Host "  Company: $($versionInfo.CompanyName)"
} catch {
    Write-Host "  Could not read file version metadata."
}

Write-Host ""
Write-Host "Install classification:"

$classification = "Unknown / other Git install"

if ($gitVersion -match "msysgit") {
    $classification = "Old msysgit install"
} elseif ($gitVersion -match "windows\.\d+$" -or $gitExe -match "Git\\cmd\\git\.exe$" -or $gitExe -match "Git\\bin\\git\.exe$") {
    $classification = "Git for Windows"
} elseif ($gitExe -match "Program Files\\Git\\") {
    $classification = "Likely Git for Windows"
} elseif ($gitExe -match "scoop|chocolatey|mingw|msys2|cygwin") {
    $classification = "Nonstandard package-managed or Unix-like Windows Git install"
}

Write-Host "  $classification"

Write-Host ""
Write-Host "Relevant PATH entries containing 'git':"
($env:Path -split ';' | Where-Object { $_ -match 'git' }) | ForEach-Object {
    Write-Host "  $_"
}

Save this as a ps1 script (like notepad $env:TEMP\git-diagnose.ps1 or something similar) then run:

powershell -ExecutionPolicy Bypass -File $env:TEMP\git-diagnose.ps1

If you could do that and send me the result, I can't seem to replicate the issue on the Windows install I'm using.

[fahdarafat]

Running git update fixed it for me

This is the result of the script before I updated git

=== Git diagnosis ===

PowerShell resolves git to:
  C:\Program Files\Git\cmd\git.exe

All git.exe found on PATH:
  C:\Program Files\Git\cmd\git.exe

git --version:
  git version 2.28.0.windows.1

git --exec-path:
  C:/Program Files/Git/mingw64/libexec/git-core

Executable details:
  Path: C:\Program Files\Git\cmd\git.exe
  File version:
  Product version:
  Product name:
  Company:

Install classification:
  Git for Windows

Relevant PATH entries containing 'git':

I updated git to 2.54.0 and Codex is working fine again

[agustindavid-gomes]

I had the same issue after updating Codex from 0.130.0 to 0.132.0 while using git version 2.34.1.windows.1.

Updating Git to 2.54.0.windows.1 fixed it for me as well.

[fcoury-oai]

I updated git to 2.54.0 and Codex is working fine again

I am so glad you helped me getting to the root cause. Installing the old git version got me to replicate the issue and I will be adding a mitigation on the next CLI version. I will be closing this issue for now, thanks again!