›_ Codex Issues
Codex Issues / #30050

Windows Codex Desktop update causes severe memory pressure and destabilizes Windows

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

What version of the Codex App are you using (From “About Codex” dialog)?

Latest available Windows Codex Desktop version as of June 25, 2026; exact build number not visible/available

What subscription do you have?

Enterprise

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

After recent Codex Desktop updates on Windows, launching Codex causes severe system resource pressure.

Observed behavior:

Codex launches with approximately 15 Codex processes.
Task Manager shows Memory rising to 99% and CPU around 51%.
Microsoft Teams closes or becomes unstable after Codex is launched.
After ending Codex, Memory drops to approximately 24%, CPU drops to approximately 9%, and Teams remains stable.
This started after recent Codex updates. I have seen at least three Codex updates within the last seven days.

Expected behavior:

Codex should not consume nearly all system memory or destabilize unrelated applications such as Microsoft Teams.

Impact:

This affects my work machine and prevents me from safely using Codex Desktop while Teams and other work applications are open.
Chrome and Microsoft Teams together run multiple processes but keep system memory around 36%. By contrast, launching Codex Desktop caused memory to spike to 99% with approximately 15 Codex processes, after which Teams became unstable or closed.

Evidence:

Screenshot showing Codex running with 15 processes and system Memory at 99%.
Screenshot after Codex is closed showing Memory reduced to 24% and Teams stable.

Environment:

OS: Windows
App: Codex Desktop
Codex version/build: Latest available Windows Codex Desktop version as of June 25, 2026; exact build number not visible/available.
Microsoft Teams running at the time: Yes
Chrome running at the time: Yes

This appears to be a Windows Codex Desktop resource/memory regression introduced by a recent update.

<img width="1190" height="1014" alt="Image" src="https://github.com/user-attachments/assets/6329d0fe-a5ed-4d78-940d-043c53afd524" />

What steps can reproduce the bug?

Steps to reproduce:

  1. On Windows, make sure Microsoft Teams and Google Chrome are open.
  2. Launch the latest available Windows Codex Desktop app.
  3. Observe Task Manager immediately after Codex launches.
  4. Codex opens approximately 15 processes.
  5. System memory rises sharply, reaching approximately 99%.
  6. CPU rises to approximately 51%.
  7. Microsoft Teams becomes unstable and/or closes.
  8. End the parent Codex process group in Task Manager.
  9. Observe that system memory drops back down significantly, approximately 24% in my test, and Teams remains stable again.

Bug behavior:

After recent Codex Desktop updates on Windows, launching Codex causes severe system resource pressure. Task Manager showed Codex running approximately 15 processes while system Memory rose to 99% and CPU rose to approximately 51%. Microsoft Teams then became unstable or closed. After ending Codex, Memory dropped to approximately 24%, CPU dropped to approximately 9%, and Teams remained stable.

This started after recent Codex Desktop updates. I have seen at least three Codex updates within the last seven days.

Expected behavior:

Codex Desktop should launch without consuming nearly all system memory and should not destabilize unrelated applications such as Microsoft Teams.

Code snippet / reproducibility note:

No code snippet is required to reproduce this issue. The bug reproduces by launching the Windows Codex Desktop app itself. This appears to be a Windows Codex Desktop resource/memory regression, not a bug caused by a particular repository command or code file.

Session ID:

Not available. I am unable to keep Codex Desktop open long enough to generate or retrieve a session ID because launching the app causes severe system resource pressure and destabilizes Microsoft Teams.

Token/context usage:

Not applicable or not available. The issue occurs at app launch/resource level, not during a specific long-context Codex task.

Context window usage:

Not applicable or not available. The issue occurs when launching Codex Desktop and observing Windows Task Manager.

What is the expected behavior?

Expected behavior:

Codex Desktop should launch normally on Windows without causing severe system resource pressure. It should not consume nearly all available memory, spawn excessive active processes, or destabilize unrelated applications such as Microsoft Teams.

Microsoft Teams, Google Chrome, and other open work applications should remain stable while Codex Desktop is running. If Codex requires additional resources during startup, usage should remain within normal limits and should not cause system memory to rise to 99% or force other applications to close.

Additional information

_No response_

View original on GitHub ↗

6 Comments

github-actions[bot] contributor · 25 days ago

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

  • #28980
  • #28524

Powered by Codex Action

miquadri · 25 days ago

Update: Issue reproduced after Repair in a new chat

I tested again after using the Windows app Repair feature.

Result:

  • Codex successfully opened far enough to start a new chat.
  • A new chat responded to a simple “Hello” message.
  • However, Task Manager showed the severe system resource issue reproduced and it Codex would not load any previous Chats.

Task Manager during new-chat test:

  • System CPU: approximately 72%.
  • System Memory: 99%.
  • System Disk: approximately 59%.
  • Codex process group: approximately 11 processes.
  • Codex parent process group memory: approximately 1,498.4 MB.
  • One child codex process showed approximately 1,425.6 MB memory.
  • Chrome was approximately 332.8 MB, so Chrome does not appear to be the memory driver in this capture.

Current status:

  • Repair did not resolve the issue.
  • Codex can open and respond in a new chat, but doing so again drove system Memory to 99%.
  • This confirms the original resource/memory pressure bug still reproduces after Repair.
  • I ended Codex again to prevent system instability.

Screenshots attached:

  1. New Codex chat responding to “Hello.”
  2. Task Manager showing system Memory at 99%, CPU around 72%, Disk around 59%, and Codex running with approximately 11 processes.
  3. Task Manager after ending Codex.

Additional confirmation after ending Codex:

After the new-chat test reproduced the issue, I ended the Codex process group.

Result after shutting down Codex:

  • System CPU dropped from approximately 72% to approximately 24%.
  • System Memory dropped from 99% to approximately 24%.
  • System Disk dropped from approximately 59% to approximately 21%.
  • Codex processes were no longer visible in Task Manager.
  • Chrome remained open at approximately 369.7 MB, confirming Chrome was not the source of the 99% memory pressure.

This further confirms that Codex Desktop is the trigger for the severe resource/memory pressure.

<img width="1642" height="1017" alt="Image" src="https://github.com/user-attachments/assets/a99f0178-3620-4144-99f8-e84820ea32b8" />

<img width="1469" height="673" alt="Image" src="https://github.com/user-attachments/assets/12d91139-5759-4bf2-a69d-0bf9b3982242" />

<img width="927" height="402" alt="Image" src="https://github.com/user-attachments/assets/007aa45d-c251-47d1-a1ff-b85f269e1772" />

miquadri · 25 days ago

Additional update: Codex crashed with memory allocation failure

Codex has now crashed and displayed an explicit memory allocation error.

Error shown in Codex:

  • “An error has occurred”
  • “Codex crashed with the following error”
  • “Most recent error: memory allocation of 1502542 bytes failed”
  • “Codex app-server is not available”
  • “Failed to resume chat”
  • “Error creating task”

This appears directly related to the previously reported memory/resource-pressure issue. Earlier testing showed system Memory rising to 99% while Codex was running. Codex now reports a memory allocation failure and the app-server is unavailable, which also explains the chat resume/loading failures.

Screenshot attached showing the crash/error screen.

<img width="1507" height="935" alt="Image" src="https://github.com/user-attachments/assets/8edd44e4-abf4-4d1c-9c54-1965f68e3540" />

miquadri · 25 days ago

Additional profile reset/repair update:

A local Codex profile reset/repair was completed.

What changed:

  • The live Codex profile was swapped out for a fresh profile.
  • The pre-reset profile was preserved at:

C:\Users\miquadri\AppData\Local\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Roaming\Codex\web\Codex.pre-reset-20260625-162830

  • Earlier safety backups were also preserved:

Codex.backup-20260625-160050
Codex.backup-20260625-160627

  • A new live Codex profile was created and rebuilt cleanly.

Result after reset:

  • The reset/repair succeeded at the profile level.
  • However, the Codex backend memory issue still appears to reproduce afterward.
  • After relaunch, a background codex.exe backend process again grew abnormally, reaching approximately 8.4 GB working set/private memory.
  • This suggests the underlying issue is not fully resolved by resetting the local profile.

Current status:

  • I am preserving the backup profiles.
  • I am not restoring the old profile into the live Codex app because doing so may reintroduce the failing state.
  • I am stopping further live Codex Desktop testing to avoid destabilizing the system.
miquadri · 25 days ago

Additional update: likely trigger identified — oversized local session file

I found and quarantined a likely local trigger for this Windows Codex Desktop memory/resource-pressure issue.

A single Codex session file in the active local sessions path was approximately 16.9 GB:

I moved/quarantined the file instead of deleting it.

After quarantining that file, active Codex sessions were reduced to approximately 0.38 GB.

The live codex.exe app-server process was still inflated at the time of discovery, reaching approximately 47 GB private memory, with system committed memory around 62.5 GB. It appears that the app-server does not release the memory until Codex is fully restarted or the process is ended.

This suggests the issue may be triggered when Codex Desktop attempts to scan, hydrate, resume, or index an extremely large .jsonl session file. In this case, the oversized session appears to be associated with an old long-running project chat used to build the FA AI Examiner Desk application.

Important clarification:

  • The application itself appears healthy.
  • Build passed.
  • restart:clean passed.
  • Healthcheck passed.
  • CSS/static assets are healthy.
  • Core routes return 200.
  • The issue appears isolated to the oversized Codex session file and the Codex Desktop app-server memory behavior, not the application codebase.

Current status:

  • The 16.9 GB session file is preserved in quarantine, not deleted.
  • I am not restoring it to the active .codex\sessions path.
  • I am stopping further Codex Desktop testing for the night to avoid destabilizing Windows.
  • Tomorrow I plan to commit the current application work in logical groups and move future coding work to Codex Cloud or a fresh session rather than relying on this broken local Desktop chat.

This may point to a needed guardrail in Codex Desktop: it should detect extremely large/corrupt session .jsonl files and avoid loading them into the app-server in a way that can drive Windows memory/commit usage to exhaustion.

miquadri · 24 days ago

Final clarification:

I closed this issue after identifying and quarantining a likely local trigger: a single oversized Codex session .jsonl file of approximately 16.9 GB in C:\Users\miquadri\.codex\sessions.

However, I want to clarify the product concern.

Even if that oversized session file was the immediate trigger on my machine, Codex Desktop should be able to tolerate many chats and long-running sessions without causing Windows memory/commit exhaustion or system instability. At minimum, Codex Desktop should detect oversized or corrupt session files and handle them safely instead of allowing the codex.exe app-server process to grow into tens of GB of private memory.

Expected guardrails would include:

  • detecting unusually large .jsonl session files;
  • skipping/quarantining oversized or corrupt sessions;
  • warning the user that a specific chat/session is too large to load;
  • lazy-loading session history instead of scanning/hydrating everything into memory;
  • preventing app-server memory from growing without bounds;
  • providing a safe-mode launch path that ignores prior sessions;
  • providing a user-facing session cleanup/export tool.

The issue is mitigated locally by quarantining the 16.9 GB session file, but the underlying Codex Desktop behavior remains a product reliability concern. End users should be able to maintain many Codex chats without the desktop app destabilizing the system.