›_ Codex Issues
Codex Issues / #23888

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

Resolved 💬 6 comments Opened May 21, 2026 by mir3626 Closed May 22, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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:

  • #15380 Windows Terminal scrollback/render inconsistency
  • #5576 output width remains truncated after resizing
  • #4870 Korean IME preedit blanks
  • #14372 git fsmonitor sandbox/IPC errors
  • #23446 /review branch picker regression where comments also mention 6ec8c4a6
  • #23367 wrong cwd regression, which #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.

View original on GitHub ↗

6 Comments

github-actions[bot] contributor · 2 months ago

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

  • #23691
  • #23628

Powered by Codex Action

fcoury-oai contributor · 2 months ago

This is very, very useful. Thank you.

fcoury-oai contributor · 2 months ago

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 · 1 month ago

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 · 1 month ago

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 contributor · 1 month ago
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!