Codex desktop app intermittently freezes Windows shell/UI; opening Codex Settings stops the freeze

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

• #15481

Powered by Codex Action

I get this exact taskbar and explorer freeze too.
I note this was on a repo where I not pushed a github commit yet,
Looking in RAMMAP, I can see 100s of git.exe and conhost.exe which don't show in Task Manager processes list.

Same here. But opening Codex Settings does not stop the freeze for me.
The only thing that helps is closing the Codex GUI.

Yeah, opening Settings didn't help me either. Codex seems to be rapidly creating 100s of zombie processes (git.exe and conhost.exe) which use up page table memory and don't get cleaned up and eventually prevent other processes from launching.

I’m having seen issue. I’m forced to reboot my computer. The fix I found is to uninstall Codex and just use Claude code.

I believe I've tracked this down to a bug in AMD Adrenaline Edition drivers that caused a zombie process handle leak as I have a AMD Ryzen 7 series CPU. More details here https://yngve.vivaldi.net/amd-you-infected-my-pc-with-zombies/
So, the actual bug is in the AMD drivers, but given that Codex spawns a LOT of short-lived background git processes, that magnifies the problem.

Do the other people reporting this have AMD GPUs or CPUs?

Nvidia drivers for me

AMD CPU here

I have exactly same issue. Nvidia GPU and AMD CPU. The app is just unusable.

I'm experiencing a similar issue. After some period of time, Codex will hang. Ending the Codex tasks in Task Manager will allow me to reopen it and use it for some additional time, but it will eventually hang again. In the interim, Windows functionality will begin to degrade. The first noticeable behavior is usually failure of the Print Screen button, then Alt-Tab, then the Start Menu. Other open applications generally continue to operate without issue.

A reboot will bring the machine back to the normal working state and will operate normally until I resume using Codex, at which point the degradation restarts itself.

I'm also on an AMD CPU.

I switched to the Codex extension in VS Code because of the app instability. Unfortunately, it's eventually nuking system processes from that environment as well (my Print Screen just stopped working). The underlying Codex stack seems to be corrupting Windows regardless of which head it runs under.

I can reproduce this class of issue as well on Windows.

Observed behavior on my side:

• While Codex app is running, Windows shell gradually degrades/freezes (taskbar and status area become unresponsive).
• In this state, opening Task Manager and force-ending Codex background process(es) restores normal Windows behavior.
• The issue then reappears after using Codex app again for some time.

This matches the reports in this thread about shell/UI freeze and recovery after killing Codex processes.

I’m adding this datapoint because it looks very similar to a process/resource leak pattern (consistent with reports mentioning many short-lived git/conhost processes).

I found thatusing Google Drive will cause this. Verified.

Same... It's awful!

I can reproduce this class of issue as well on Windows.

Observed behavior on my side:

While Codex app is running, Windows shell gradually degrades/freezes (taskbar and status area become unresponsive).
In this state, opening Task Manager and force-ending Codex background process(es) restores normal Windows behavior.
The issue then reappears after using Codex app again for some time.

I believe I've tracked this down to a bug in AMD Adrenaline Edition drivers that caused a zombie process handle leak as I have a AMD Ryzen 7 series CPU. More details here https://yngve.vivaldi.net/amd-you-infected-my-pc-with-zombies/ So, the actual bug is in the AMD drivers, but given that Codex spawns a LOT of short-lived background git processes, that magnifies the problem. Do the other people reporting this have AMD GPUs or CPUs?

I also ran into the same issue. I have an Nvidia GPU, however there is an onboard AMD GPU, and the problematic driver mentioned in the article is installed (probably automatically). After deactivating the onboard GPU, the issue is fixed.
Thanks for finding this is related to that driver issue. The linked article is from January 2025, so it is rather strange that a fix hasn't been installed by Windows Update, as it seems the issue has now been well known for a long time.

This might still be a bug in Codex, too, with launching too many Git processes - I am pretty sure that was the issue as the task manager showed a lot of these processes (probably "zombies" as in the article). Since processes are a limited system resource, Codex should probably be a bit more conservative with launching them, or maybe re-use existing processes.

Having this issue on an AMD CPU and Nvidia GPU tbh

I’m seeing a similar frequent freeze/stuck issue in the Codex desktop app on Windows.

Environment:

• Codex app: 26.602.4764.0
• Codex CLI: 0.124.0
• OS: Windows 10 Home, version 2009, build 26200, 64-bit
• Install source/package: Microsoft Store package OpenAI.Codex_26.602.4764.0_x64__2p2nqsd0c76g0

Observed behavior:

• Codex desktop frequently becomes stuck/unresponsive during normal use.
• This feels like a local desktop UI freeze, not just delayed model output or slow network response.
• Restarting or closing the app is sometimes needed to recover.

Expected behavior:

• Codex desktop should remain responsive during normal agent/thread usage.

I have not attached logs because they may contain sensitive local paths/session content, but I can provide a session ID or sanitized logs if helpful.

I can reproduce what appears to be the same issue on Windows.

Environment

• Codex app: OpenAI.Codex_26.616.9593.0
• Windows 11, OS build 26200
• AMD CPU/iGPU + NVIDIA dGPU
• NVIDIA driver: 610.62

Observed behavior

• Taskbar, Start menu, and Search become extremely sluggish or stop responding while Codex is open.
• Pressing Win + Ctrl + Shift + B temporarily recovers the UI, but the issue quickly returns.
• Closing Codex immediately restores normal taskbar/shell behavior.

Event log / diagnostics

• StartMenuExperienceHost.exe and ShellExperienceHost.exe crash/hang around the freeze window.
• Faulting module observed: Windows.UI.Xaml.dll
• Exception code observed: 0xc0000409
• nvidia-smi shows Codex.exe running a GPU process on the NVIDIA GPU.

Mitigations tried

• Clean NVIDIA driver installation
• Hardware-accelerated GPU scheduling disabled
• Windows Graphics preference set to Power Saving for Codex
• Per-exe GpuPreference=1 registry entry

The GPU preference setting did not appear to take effect; Codex still used the NVIDIA GPU. The most reliable workaround so far is closing Codex Desktop.

This is also happening on my device now.
Windows 11, NVIDIA GPU and AMD CPU.

After 1 minute of having the app open, the task bar, and other shell features like alt+tab commands or just pressing the windows key stop functioning completely. After a while the entire background disappears, taskbar disappears, explorer.exe as a whole just won't work. Can't start it a new either.

The second I end the Codex process in task manager, everything instantly resolves itself.

This issue has been reported around the end of March, it is now the end of June and outside of this github issue thread, I can not find a single thing about this.

Very sad, I'm paying a monthly subscription for this and it is now completely unusable for me, as I can't use it AND switch to other processes or use the rest of my computer at the same time...

The Codex app and any other app just runs fine during this as well, it's just the windows shell locking up for me.

Same issue here on Windows. This is severe enough that I’ve had to force-restart the PC multiple times.

Environment:

• Codex Desktop: OpenAI.Codex_26.623.11225.0_x64__2p2nqsd0c76g0
• Windows 11 Pro, build 26100, x64
• CPU: AMD Ryzen 5 7600X3D
• RAM: 64 GB
• GPU: NVIDIA GeForce RTX 5070 Ti, driver 32.0.16.1062 / 610.62
• iGPU: AMD Radeon(TM) Graphics, driver 31.0.24002.92

Observed behavior:

• Taskbar / Start menu / Search / Explorer gradually become unresponsive while Codex Desktop is open.
• Win + Shift + S and Win + PrtSc stop working or respond minutes later.
• Renaming/opening files in Explorer can hang.
• Desktop/taskbar can disappear or go black.
• Other apps may still be alive, but Windows shell functionality degrades badly.
• Force-killing Codex processes or rebooting restores the system temporarily.

Diagnostics I captured locally:
Codex Desktop process Codex.exe repeatedly spawned short-lived Git/conhost/PowerShell children, roughly every second, even when my current working directory was not a Git repo.

Examples observed:

"C:\Program Files\Git\cmd\git.exe" -c core.hooksPath=NUL -c core.fsmonitor= rev-parse --show-toplevel
git.exe -c core.hooksPath=NUL -c core.fsmonitor= rev-parse --show-toplevel
conhost.exe
powershell.exe -NoProfile -NonInteractive -Command "Get-CimInstance Win32_Process ..."
powershell.exe -NoProfile -NonInteractive -Command "Get-CimInstance Win32_PerfFormattedData_PerfProc_Process ..."

Codex version: 26.623.13972.0
Platform: Windows 11 x64
Package: OpenAI.Codex_26.623.13972.0_x64__2p2nqsd0c76g0

I can reproduce a Windows shell/taskbar freeze triggered by Codex:

• System was at about 43% RAM.
• I started Codex and had not yet typed a prompt.
• Windows Search became unclickable.
• Then the taskbar also became unclickable and showed the busy cursor.
• Task Manager still opened via keyboard shortcut.
• Killing Codex immediately restored the taskbar and Windows Search.
• Earlier RAMMap captures during longer sessions showed Page Table growing to ~9 GB and Nonpaged Pool to ~3 GB, while normal user processes did not explain total RAM usage.

Codex Desktop::Package: OpenAI.Codex_26.623.19656.0_x64__2p2nqsd0c76g0

• Version: 26.623.19656.0
• CLI: codex-cli 0.142.5

Platform:

• OS: Microsoft Windows 11 Pro
• Version: 10.0.26200
• Build: 26200

Hardware:

• CPU: 12th Gen Intel(R) Core(TM) i7-12700KF
• CPU cores/logical processors: 12 cores / 20 logical

RAM: Windows currently reports 31.85 GB visible

• GPU: NVIDIA GeForce RTX 4070 Ti
• GPU driver: 32.0.16.1074

99% Mem Usage - Been fighting this since the weekend issues, canceling and moving to claude

“Codex Desktop on Windows triggers system memory exhaustion and Start/taskbar freezing after reopening. The visible window can close while Codex/Codex helper processes remain alive. At peak, physical memory reached ~100%, committed memory reached ~52 GB / 60.85 GB, but normal process private commit totaled only ~8.27 GB and Codex itself was ~1 GB. Kernel pools were elevated, and Windows began paging heavily. This began after the late-June Codex weekend incident/update window and repeats when Codex Desktop is opened.”

Codex Desktop::Package: OpenAI.Codex_26.623.19656.0_x64__2p2nqsd0c76g0 Version: 26.623.19656.0 CLI: codex-cli 0.142.5 Platform: OS: Microsoft Windows 11 Pro Version: 10.0.26200 Build: 26200 Hardware: CPU: 12th Gen Intel(R) Core(TM) i7-12700KF CPU cores/logical processors: 12 cores / 20 logical RAM: Windows currently reports 31.85 GB visible GPU: NVIDIA GeForce RTX 4070 Ti * GPU driver: 32.0.16.1074 99% Mem Usage - Been fighting this since the weekend issues, canceling and moving to claude “Codex Desktop on Windows triggers system memory exhaustion and Start/taskbar freezing after reopening. The visible window can close while Codex/Codex helper processes remain alive. At peak, physical memory reached ~100%, committed memory reached ~52 GB / 60.85 GB, but normal process private commit totaled only ~8.27 GB and Codex itself was ~1 GB. Kernel pools were elevated, and Windows began paging heavily. This began after the late-June Codex weekend incident/update window and repeats when Codex Desktop is opened.”

Wanted to report back here, that I figured out my issue.
A few of my projects had 4/5gb helper chrome modals. removing these cleaned up nearly 10gb of files that were being indexed. Treesize pro, and requesting codex clean them safely helped.

So today or yesterday, OpenAI announced ChatGPT 5.6 and with it, an agentic desktop app to go along with it.
They said that codex now merges into this app. So I was of course hopeful that this new updated app wouldn't have this same issue.

I have tested and can confirm that in the new ChatGPT desktop app for windows, the problem still exists...

It only happens when the app is "Codex mode" and not in "Work mode".

I can confirm it remains.

On Fri, Jul 10, 2026 at 12:49 PM Yelorix @.***> wrote:

Yelorix left a comment (openai/codex#16374) <https://github.com/openai/codex/issues/16374#issuecomment-4938033782> So today or yesterday, OpenAI announced ChatGPT 5.6 and with it, an agentic desktop app to go along with it. They said that codex now merges into this app. So I was of course hopeful that this new updated app wouldn't have this same issue. I have tested and can confirm that in the new ChatGPT desktop app for windows, the problem still exists... It only happens when the app is "Codex mode" and not in "Work mode". — Reply to this email directly, view it on GitHub <https://github.com/openai/codex/issues/16374?email_source=notifications&email_token=AL62H4GFZNBHTFB5OQFRE2T5EEUDPA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOJTHAYDGMZXHAZKM4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4938033782>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AL62H4EDF2M67SUBTMXZIQT5EEUDPAVCNFSNUABFKJSXA33TNF2G64TZHM4TMNJUGE2TMNBZHNEXG43VMU5TIMJYGI4TCNJVGY2KC5QC> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/AL62H4EH3XMIXQ3T47TUFSD5EEUDPA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOJTHAYDGMZXHAZKM4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJKTGN5XXIZLSL5UW64Y> and Android <https://github.com/notifications/mobile/android/AL62H4ECPH4H3XKJ2EE7IUL5EEUDPA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOJTHAYDGMZXHAZKM4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI>. Download it today! You are receiving this because you commented.Message ID: @.***>

I can reproduce this issue on a current Codex Windows build, and I captured DWM/GPU performance data before and after recovery.

Environment

• Codex package: OpenAI.Codex_26.707.3748.0
• Bundled Chromium: 150.0.7871.101
• Windows 11
• AMD Ryzen 9 7950X
• NVIDIA GeForce RTX 4090, driver 595.79
• AMD integrated graphics also enabled
• 3440×1440 display at 164 Hz

Observed behavior

After leaving the Codex app running for a long time, the entire Windows desktop becomes increasingly laggy. Window dragging visibly stutters and even keyboard input is delayed, while Task Manager appears mostly idle.

The issue correlates specifically with long-running Codex app sessions on this machine.

Measurements while affected

• dwm.exe: approximately 115% CPU, where 100% represents one logical processor
• DWM dedicated GPU memory: 2,191 MB
• DWM private working set: 218 MB
• DWM threads: 192
• DWM handles: 2,850
• No significant DPC/interrupt load
• SSD latency, memory availability, and hardware status were normal
• No relevant display-driver errors appeared in the System event log

Disabling NVIDIA Overlay and fully closing the NVIDIA app did not fix the lag.

Win+Ctrl+Shift+B reset the graphics driver but did not improve the issue. DWM retained approximately 2.2 GB of dedicated GPU memory.

I then force-restarted only dwm.exe with administrative privileges. Codex and all other applications remained open.

Immediately after the DWM restart

• New DWM process confirmed
• DWM CPU: 115% → 21%
• Dedicated GPU memory: 2,191 MB → 851 MB
• Private working set: 218 MB → 62 MB
• Window movement and keyboard input immediately became smooth again

This suggests that Codex’s long-running Chromium renderer/GPU activity may trigger an accumulation of DWM composition surfaces or another persistent compositor state. The resource pressure is visible primarily in dwm.exe, not necessarily in the Codex GPU subprocess itself; after recovery, the Codex GPU subprocess used only approximately 101 MB of dedicated GPU memory.

Restarting the graphics driver was insufficient, while restarting the DWM process cleared the condition without rebooting or signing out.

I would be happy to capture additional counters or logs during the next reproduction if maintainers can specify what would be most useful.

I can confirm that this issue is still reproducible as of July 14, 2026, with OpenAI.Codex_26.707.8168.0 on Windows 11 Pro 23H2 (build 22631.6199, x64, 32 GB RAM).

During the incident, physical memory usage reached 98% while normal live processes could not explain the usage. A RAMMap 1.63 snapshot showed:

• Page Table: 11,075,748 KiB
• Unused / Active: 11,689,316 KiB
• 338,953 distinct entries in the RMP <ProcessList>
• 223,929 git.exe records
• 112,498 conhost.exe records

git.exe and conhost.exe accounted for 99.25% of all retained process records. The arithmetic is unusually exact: approximately 32.68 KiB of Page Table and 34.49 KiB of Unused/Active memory per retained record. The largest currently live process used only about 5.3 MiB of page-table memory, so the 10.56 GiB global total came from hundreds of thousands of exited process objects rather than one large live process.

I also captured a bounded 10.09-second Win32_ProcessStartTrace: 279 process starts (27.65/sec), consisting of 179 git.exe, 93 conhost.exe, and 6 powershell.exe. At least 89 Git processes and four PowerShell processes were direct children of the Codex/ChatGPT desktop process during that short window.

The evidence confirms that Codex is generating extreme short-lived Git/conhost process churn and greatly amplifying the failure. I cannot yet prove which kernel component prevents the exited process objects from being released; a third-party security/HIPS driver is installed, so the retention owner still needs isolation. I retained the 450 MB RMP snapshot and can provide sanitized counts or additional traces if maintainers specify what would be useful.

I can reproduce the same issue consistently.

Codex version:
26.623.13972.0

Package:
OpenAI.Codex_26.623.13972.0_x64__2p2nqsd0c76g0

Platform:
Windows 11 x64

Reproduction:

1. Start Codex Desktop.
2. No project needs to be opened.
3. Windows Search becomes unclickable, and sometimes the entire taskbar becomes unresponsive and shows the busy cursor.
4. Task Manager can still be opened with the keyboard shortcut.
5. Killing Codex immediately restores Windows Search and the taskbar.

The problem still occurs after:

• repairing the Codex app
• resetting the Codex app
• completely uninstalling and reinstalling Codex
• disabling the NVIDIA overlay
• reducing background and startup applications
• testing without opening any project

Memory observations with Microsoft RAMMap:

Directly after reboot:

• RAM usage: approximately 17%
• Page Table: approximately 170 MB
• Nonpaged Pool: approximately 562 MB

After extended Codex use:

• RAM usage: approximately 92–99%
• Page Table: approximately 10.8 GB
• Nonpaged Pool: approximately 3.9 GB
• Paged Pool: approximately 1.75 GB
• Process Private: only approximately 4.2 GB

Closing all normal applications does not release the memory. A reboot resets the Page Table and Nonpaged Pool to normal values.

The issue started recently and appears to coincide with recent Windows updates:

• KB5094126 installed 2026-06-12
• KB5094135 installed 2026-06-10

Codex is the direct trigger in my tests, because killing Codex immediately restores the Windows shell even when overall RAM usage is not yet high.

<img width="1642" height="563" alt="Image" src="https://github.com/user-attachments/assets/0c30b0df-1696-45b7-b888-cdc4940caf38" />

Additional finding:

The same Windows shell/taskbar freeze also occurs when using the Codex VS Code extension.

• The standalone ChatGPT/Codex desktop app was closed.
• Codex was used inside VS Code.
• At approximately 65% total RAM usage, Windows Search/taskbar became unresponsive.
• Killing VS Code immediately restored the taskbar.
• This suggests the issue may involve a component shared by the Codex desktop app and the Codex IDE extension, rather than only the standalone desktop UI.

I am now testing VS Code with the Codex extension disabled to isolate the extension from VS Code itself.

I can confirm that this issue is still reproducible as of July 14, 2026, with OpenAI.Codex_26.707.8168.0 on Windows 11 Pro 23H2 (build 22631.6199, x64, 32 GB RAM). During the incident, physical memory usage reached 98% while normal live processes could not explain the usage. A RAMMap 1.63 snapshot showed: Page Table: 11,075,748 KiB Unused / Active: 11,689,316 KiB 338,953 distinct entries in the RMP <ProcessList> 223,929 git.exe records * 112,498 conhost.exe records git.exe and conhost.exe accounted for 99.25% of all retained process records. The arithmetic is unusually exact: approximately 32.68 KiB of Page Table and 34.49 KiB of Unused/Active memory per retained record. The largest currently live process used only about 5.3 MiB of page-table memory, so the 10.56 GiB global total came from hundreds of thousands of exited process objects rather than one large live process. I also captured a bounded 10.09-second Win32_ProcessStartTrace: 279 process starts (27.65/sec), consisting of 179 git.exe, 93 conhost.exe, and 6 powershell.exe. At least 89 Git processes and four PowerShell processes were direct children of the Codex/ChatGPT desktop process during that short window. The evidence confirms that Codex is generating extreme short-lived Git/conhost process churn and greatly amplifying the failure. I cannot yet prove which kernel component prevents the exited process objects from being released; a third-party security/HIPS driver is installed, so the retention owner still needs isolation. I retained the 450 MB RMP snapshot and can provide sanitized counts or additional traces if maintainers specify what would be useful.

I was able to significantly reduce my memory leak by repairing git, and upgrading it. When I say repair, I mean using codex itself to look at the empty file directories that had .git, and making them real repos. Like the other post here though it does seem as if Chrome and VS code both were affected as well.

I can reproduce a closely related issue on the current Codex Desktop for Windows.

Environment

• Codex Desktop: 26.707.9981.0
• Platform: Windows x64
• GPU: Intel UHD Graphics + NVIDIA GeForce RTX 4060 Laptop GPU

Observed behavior

While the main Codex task view is visible and focused, pointer movement becomes noticeably choppy across the Windows desktop.

This affects both:

• a Bluetooth mouse
• the built-in touchpad

Minimizing or exiting Codex immediately restores smooth pointer movement. This makes a mouse, Bluetooth, or touchpad hardware issue unlikely and suggests that the active Codex renderer/compositor state is affecting desktop responsiveness.

Relevant diagnostics

During the issue, overall system load was normal:

• CPU usage: approximately 9%
• DPC time: approximately 0.10%
• Interrupt time: approximately 0.25%
• Physical disk queue length: approximately 0.01
• Memory committed: approximately 40%

I found no recent WHEA, disk I/O, or display-driver reset events.

However, the active Codex Desktop log contained:

• 597 occurrences of:

ResizeObserver loop completed with undelivered notifications.

• 327 occurrences of:

[desktop-notifications] service starting

The repeated errors were emitted while the renderer window was reported as:

• rendererWindowFocused=true
• rendererWindowVisible=true

The notification service was sometimes initialized four times at the same timestamp after switching task views.

Reproduction pattern

1. Open Codex Desktop.
2. Use a relatively long task containing streamed responses, terminal output, and diagnostic logs.
3. Keep the main task view visible and focused.
4. Move either the touchpad or an external mouse.
5. Pointer movement becomes choppy across the desktop.
6. Minimize or exit Codex.
7. Pointer movement immediately returns to normal.

This may be related to a frontend layout/reconciliation loop or the Chromium GPU compositing path. I am not asserting the exact root cause, but the behavior appears closely related to this issue.

Possibly related:

• #20131 — contains the same ResizeObserver error in Codex frontend logs
• #24904 — Windows GPU-accelerated rendering issue
• #20867 — renderer degradation with long Windows threads

I can provide sanitized application logs if that would help isolate the renderer state responsible for the issue.

Additional findings from another reproducible Windows 11 case:

System

• Windows 11
• 32 GB RAM
• AMD-based laptop with NVIDIA graphics
• Git for Windows was initially 2.55.0.windows.2 and was then upgraded
• Codex tested both in the desktop app and through the VS Code extension
• Main project is a Flutter/Dart repository

Behavior before the Git cleanup

After longer Codex sessions, total RAM usage increased to approximately 85–99%.

RAMMap showed that most of the abnormal growth was not ordinary application memory:

• Page Table: approximately 10.8 GB
• Nonpaged Pool: approximately 3.9 GB
• Process Private: approximately 4.2 GB

The Windows shell then gradually degraded:

• Taskbar became unresponsive
• Windows Search stopped reacting
• Alt+Tab sometimes stopped working
• Explorer appeared partially frozen

Killing the Codex desktop process restored the shell immediately.

The same behavior also occurred when using the Codex VS Code extension. Killing VS Code immediately restored the taskbar.

This means the problem does not appear to be limited to the Codex desktop UI.

Git-related finding

The actual project repository was healthy:

C:\Lumifesta\lumifesta_app\.git

git status was clean, and git fsck completed successfully apart from two harmless dangling blobs.

However, there was an additional .git directory in the parent folder:

C:\Lumifesta\.git

Git did not recognize that parent directory as a valid repository:

fatal: not a git repository (or any of the parent directories): .git

I renamed this invalid parent .git directory, upgraded Git for Windows, and rebooted the computer.

Behavior after the Git cleanup

The situation improved significantly:

• One VS Code instance running Codex
• A second VS Code instance running Claude Code
• RAM remained stable between approximately 50–60%
• Both instances ran for several hours without an immediate shell freeze

However, after switching the second VS Code instance from Claude Code to Codex, meaning two Codex sessions were active simultaneously, the taskbar started hanging again.

At that moment:

• Total RAM was approximately 73%
• Both VS Code instances were still running
• The taskbar eventually recovered by itself

This suggests that:

1. Invalid or incomplete .git directories may significantly amplify the problem.
2. Upgrading or repairing Git can reduce the leak.
3. The underlying issue is not completely resolved.
4. Multiple concurrent Codex sessions appear to increase the probability of the Windows shell freeze.
5. The freeze is not caused only by total physical RAM exhaustion, because it can occur at approximately 65–73% RAM usage.

Given the other reports about large numbers of short-lived or zombie git.exe and conhost.exe processes, it may be useful to investigate:

• process and handle cleanup after Git commands
• page-table growth caused by repeated short-lived subprocesses
• whether the shared Codex backend used by the desktop app and VS Code extension is leaking Windows process handles
• whether concurrent Codex sessions multiply the leak
• behavior when Codex encounters invalid or partial .git directories in parent folders

The Git cleanup greatly delayed and reduced the problem, but did not eliminate it.