Codex Desktop Windows: Git controls missing when thread git metadata is not backfilled for a valid local repo

Additional datapoint after updating/restarting Codex Desktop:

• Codex Desktop version now shows 26.623.5175.0 on Windows.
• The right-side panel no longer shows the full Environment Info section at all. It only shows a Sources card with the GitHub/source icon.
• This is not limited to one repository according to local observation; the visible environment controls are missing across projects/threads.
• Local terminal Git remains normal for the affected workspace (git status --short --branch shows the branch tracking origin cleanly).
• The current affected thread still has git_branch = main but git_sha = NULL and git_origin_url = NULL in state_5.sqlite.
• Other historical threads in the same local database have complete Git metadata, so this looks like an inconsistent Desktop thread metadata/UI state issue rather than GitHub CLI or Git installation failure.

Also searched public issues for environment info missing, source only panel, and commit push not showing desktop, but did not find an exact duplicate.

Update after additional local diagnostics:

After mitigating the non-ASCII Windows username path issue, new threads now correctly persist Git metadata in state_5.sqlite.

For a newly created thread in the affected repo:

• git_branch is populated
• git_sha is populated
• git_origin_url is populated

The previous EPERM mkdir C:\Users\����� errors no longer appear in the latest logs.

However, Codex Desktop still renders only the Sources section in the right panel. Environment Info / Changes / Branch / Commit or Push controls are still hidden across all projects and new threads.

I also tried:

• resetting state_5.sqlite
• clearing selected global UI state
• clearing Chromium profile UI caches
• restarting Codex Desktop
• creating a new thread

The issue persists even though Git metadata is now present in the local state database. This suggests the remaining problem is likely in the Desktop UI rendering / feature surface / feature flag layer, not Git detection itself.

This appears related to #30336 and especially #30344.

In my case, Git metadata is already populated in local state, but Codex Desktop still only renders the Sources section and hides the Environment Info / Git controls.

Update after final local diagnostics (Windows, all repositories affected):

Current environment

• Codex Desktop package: 26.707.3748.0
• Desktop app-server client version in logs: 26.707.31428
• Bundled Codex CLI: 0.144.0-alpha.4
• Windows 11 build: 10.0.26200
• Git: 2.54.0.windows.1

Scope has expanded

This is no longer limited to one old thread or one repository. The native Git UI fails across all tested local Git repositories and tasks on this machine.

In the representative repository, the right-side Environment Info panel may render the Git controls (Changes / Local / main / Commit or push), but the Changes view does not consume or display the actual local diff. "Generate commit message" also fails.

CLI evidence from the same workspace

git status --porcelain=v1
 M README.md

git diff --numstat
1       0       README.md

git rev-parse --show-toplevel
D:/ai_agent_project/<redacted-project>

git branch --show-current
main

git rev-parse HEAD
<valid SHA>

git remote get-url origin
<valid GitHub origin>

There are no remaining Git permission warnings. Git CLI, branch, HEAD, diff, and origin are all healthy.

Codex state evidence

The active user thread row in state_5.sqlite still contains:

git_branch = main
git_sha = NULL
git_origin_url = NULL
source = vscode

At the same time, older threads and recent threads from another repository can contain complete Git metadata, confirming that the database schema and Git installation are functional. The affected Desktop task does not refresh/backfill SHA and origin even when CLI Git succeeds from the identical cwd.

Local causes ruled out

• Restarted Codex Desktop repeatedly
• Tested multiple repositories and accounts/tasks
• Rebuilt/reset local state DB with backup
• Verified all Codex SQLite databases pass integrity checks
• Verified Git PATH, branch, HEAD, origin, and diff
• Removed a global-ignore permission warning by moving core.excludesFile to an accessible path; CLI output is now clean, but Desktop behavior is unchanged
• Tested proxy/config isolation; this does not explain failure to read the local diff
• No project-level config.toml dependency: all repositories are affected

This now appears to be a Codex Desktop Git metadata refresh/UI synchronization regression rather than a repository-specific backfill edge case.

Possibly related: #30344, #30484, #30659.

Please investigate the Desktop path that populates threads.git_sha / threads.git_origin_url and the native Changes panel from local Git status.

Update: the native Git UI is now visible, but the Commit/Push flow still fails before commit-message generation. This is not a missing-UI symptom and not a GitHub push/auth failure.

Current environment

• Windows 11 build 10.0.26200
• Microsoft Store package: OpenAI.Codex_26.715.8383.0
• Desktop client version in logs: 26.715.61943
• Git for Windows: 2.54.0.windows.1

User-visible failure

Clicking the native Commit/Push action shows the localized error equivalent to:

Unable to generate commit message

Manual Git commands in the same repository work, and a manual commit/push through Git CLI has succeeded. Rebooting Windows and restarting Codex do not provide a durable fix.

Desktop log evidence

At the time of the UI failure, the Desktop log records the local Git status request being cancelled before execution:

2026-07-22T03:07:10.847Z warning [git]
git.command.complete
aborted=true
failureReason=abortedBeforeStart
requestKind=status-summary
source=local_conversation_git_actions
subcommand=status
success=false

The command family is the normal local change-collection path (git status --porcelain). Since the status/diff collection does not complete, commit-message generation has no input.

The same session also recorded:

git remote show origin
failureReason=timed_out
durationMs=10005
requestKind=default-branch
source=startup_prefetch

Process evidence

A process snapshot found 22 live git.exe processes launched by Codex-related command paths. Several had remained alive for more than 40 minutes. Commands included:

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

A current status --porcelain process was directly under the live Codex app-server process, with another Git child beneath it. These are read-only metadata/status commands, yet they remain blocked.

This does not prove that Git for Windows itself is the root cause. The stronger hypothesis is a Codex Desktop Git-worker/process-lifecycle problem: command scheduling, cancellation, pipe handling, or child-process cleanup. The stuck Git processes appear to be a direct symptom and possible amplifier.

This now closely matches:

• #34614 — same Desktop client and Store package versions; duplicate/stuck Git child processes
• #17229 — repeated git status and orphaned git.exe / conhost.exe
• #29408 — stuck Git polling in Windows multi-repo workspaces
• #33264 — orphaned Git processes persisting in newer Windows builds

There is currently no confirmed official workaround. Killing leaked Git processes or restarting the app only clears transient state; the processes can accumulate again after Codex reopens projects.

Please investigate the Windows Desktop Git worker path used by local_conversation_git_actions, especially cancellation before spawn and cleanup of git.exe descendants.