Skip to content

Codex Desktop on Windows retains/increases memory after opening long tool-heavy thread; memory not released after turns finish #26015

Open
Open
Codex Desktop on Windows retains/increases memory after opening long tool-heavy thread; memory not released after turns finish#26015
Labels
appIssues related to the Codex desktop appbugSomething isn't workingperformancesessionIssues involving session (thread) management, resuming, forking, naming, archivingwindows-osIssues related to Codex on Windows systems

Description

@Duhl-Liamz
Duhl-Liamz
opened on Jun 3, 2026

Summary

Codex Desktop on Windows appears to retain and/or continue increasing memory usage after opening a long, tool-heavy thread. The system remains stable when Codex is not running, and also mostly stable when Codex is open but no heavy thread is opened. Opening a large existing conversation causes memory usage to jump and then continue rising; memory is not released after the turn/conversation activity ends.

This looks related to loading/rendering/resuming long thread history with many tool calls / shell outputs / monitoring turns in the Desktop WebView/renderer/app-server path.

Environment

  • OS: Windows 11
  • Codex Desktop package observed in process path: OpenAI.Codex_26.601.2237.0_x64__2p2nqsd0c76g0
  • Workspace: local Windows project
  • Machine memory: ~16 GB RAM (TotalVisibleMemorySize about 15.19 GB)
  • Affected surface: Codex Desktop app, Windows

Reproduction / A-B observations

  1. Reboot machine.
  2. Do not start Codex. Observe memory for ~20 minutes.
    • Memory remains stable around 40%.
  3. Start Codex Desktop but do not open/operate any heavy conversation.
    • Memory remains stable around 45%.
  4. Open a long existing conversation containing many tool calls, shell outputs, monitoring/waiting turns, and thread-history diagnostics.
    • Memory immediately increases to about 52%.
    • Without heavy new work, it continues rising to 55%+.
  5. Continuing long-running monitoring-style turns eventually pushes memory much higher, up to 90-99%.
  6. Ending a turn does not return memory to the previous baseline. Closing/restarting Codex is the only reliable way observed to reclaim the memory.

Concrete diagnostics observed

When memory was healthy after reboot / light Codex usage:

Codex closed: stable around 40%
Codex open but idle: stable around 45%

After opening the long thread:

Memory jumped to ~52%, then kept rising to ~55%+

During higher-pressure cases with active long monitoring/tool turns:

UsedPct: 88-99%
Available memory: dropped as low as ~13 MB in one snapshot
Standby/cache: compressed down near zero in worst cases

Representative snapshot while pressure was high:

UsedPct: 99.1%
AvailableMB: 13
StandbyGB: 0.01
CacheGB: 0.03
NonpagedGB: ~1.92
PagedGB: ~1.19
CommitGB: ~28.78 / 53.19

Another case after restarting and reproducing by opening/using the long thread:

UsedPct: 88.4%
AvailableMB: 1875
StandbyGB: 1.74
CommitGB: 22.67 / 53.19

Process groups were not individually huge, but Codex/WebView/thread history was consistently involved:

Codex: roughly 1.0-1.1 GB Private across multiple processes
msedgewebview2: roughly 0.8-0.9 GB Private across many processes
Long thread token counters: tens of millions on affected histories
Rollout files: several MB with hundreds of tool calls and outputs

The problematic thread pattern includes:

  • Long-lived Desktop threads
  • Many shell_command calls
  • Monitoring/waiting loops (continue monitoring progress, waiting for remote training epochs, reading logs/history repeatedly)
  • Many tool outputs, some truncated near ~40 KB
  • Thread continuation / summarization chains
  • Large accumulated tokens_used values, e.g. affected histories reaching tens of millions of accumulated tokens

Expected behavior

  • Opening a long thread may temporarily use extra memory, but memory should stabilize and/or be released after the thread is no longer active.
  • Ending a turn should not leave Desktop/WebView/app-server memory permanently elevated.
  • Long tool histories should be virtualized / unloaded / garbage-collected so that opening or leaving a thread does not keep increasing system memory pressure.

Actual behavior

  • Opening the long thread immediately raises memory usage.
  • Staying in the long thread or running additional monitoring-style turns causes memory to continue rising.
  • After turns finish, memory is not released back near the pre-open baseline.
  • Reopening/continuing long threads amplifies the issue.
  • Restarting Codex releases the memory, suggesting retained renderer/session/tool-history state rather than system-wide baseline pressure alone.

Additional notes

I also tested whether this was caused by unrelated system software. After reboot, with Codex closed, memory stayed stable around 40% for ~20 minutes. That makes a pure system-driver leak less likely. GPU overlays / AMD / Lenovo background tools may add pressure, but the cleanest A/B trigger is opening the heavy Codex thread.

This may be a Desktop/WebView memory-retention issue around long conversation history, tool output rendering, stream/log retention, or thread/session state not being released after turns complete.

Activity

  1. github-actions
    added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    windows-osIssues related to Codex on Windows systems
    performance
    sessionIssues involving session (thread) management, resuming, forking, naming, archiving
    on Jun 3, 2026

  2. github-actions commented on Jun 3, 2026

    @github-actions
    github-actionsbot
    on Jun 3, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  3. Duhl-Liamz commented on Jun 3, 2026

    @Duhl-Liamz
    Duhl-Liamz
    on Jun 3, 2026 – with ChatGPT Codex Connector
    Author

    Additional diagnostics from RAMMap / follow-up testing:

    RAMMap evidence

    After reproducing the memory growth, Windows Task Manager showed high "In use" memory, but the top processes did not explain it. RAMMap provided a clearer breakdown:

    Total physical memory: ~15.19 GB
Page Table: ~3,072,072 K (~3.0 GB)
Process Private: ~3,033,200 K total, ~2,949,060 K active
Mapped File: ~3,215,380 K total
Nonpaged Pool: ~1,549,964 K
Paged Pool: ~810,500 K
Driver Locked: ~185,136 K (~181 MB)
Memory Compression: small (~60 MB in Task Manager)

    The important part is that Page Table was around 3 GB, while Driver Locked was only ~181 MB and Process Private was not large enough to explain the high physical memory usage.

    RAMMap Processes tab sorted by Page Table did not show any individual process with a large page table footprint. The largest visible entries were only a few MB, for example:

    explorer.exe: ~3,388 K Page Table
MsMpEng.exe: ~2,916 K
Weixin.exe: ~2,468 K
msedge.exe: ~2,436 K
WebView/WeChat processes: roughly 1-2 MB each

    So the Page Table growth does not appear attributable to one currently-running process. It looks more like accumulated/system-level page table memory after a long tool-heavy Codex Desktop session.

    RAMMap Empty test

    I then ran:

    Empty -> Empty Working Sets
Empty -> Empty Standby List
Empty -> Empty Modified Page List

    This reduced memory usage only partially, down to about 80%, but did not return the system to the post-reboot baseline of about 40-45%. This suggests there are two components:

    • a reclaimable working set / standby / modified-page component, and
    • a non-trivially-reclaimable system/Page Table component that remains until reboot.

    Updated hypothesis

    Codex creating many child processes is expected behavior for tool-heavy sessions. During long sessions it naturally creates many short-lived processes such as:

    PowerShell / shell_command
git / rg / python / node_repl
ssh / log tail / remote status checks
WebView / Chromium renderer processes

    The suspected bug is not that these subprocesses are created. The suspected bug is that after many tool calls / short-lived subprocesses / WebView-heavy thread-history operations, Page Table memory grows to GB scale and does not return to baseline after the subprocesses exit or Codex is closed.

    A more precise formulation of the issue:

    Codex Desktop's high-frequency tool/subprocess pattern appears to trigger Windows Page Table/system-memory retention. Page Table grows to ~3 GB, RAMMap cannot fully reclaim it, and closing Codex only releases a small portion of memory; reboot is required to return to baseline.

    This also explains why regular Task Manager process memory did not add up to the total physical memory usage.

  4. Duhl-Liamz commented on Jun 5, 2026

    @Duhl-Liamz
    Duhl-Liamz
    on Jun 5, 2026 – with ChatGPT Codex Connector
    Author

    Additional reproduction update:

    After more A/B testing, the trigger appears broader than just opening/resuming a very long thread.

    New observation:

    • When Codex Desktop is open but no task/turn is running, system memory can remain stable at a normal baseline.
    • Once a Codex task starts, memory pressure can climb rapidly and eventually become extreme, even when the task is not a very long historical thread.
    • Long/tool-heavy threads still amplify the issue, but they no longer appear to be the only trigger.

    Updated interpretation:

    The earlier long-thread/session-history hypothesis is still relevant, but the immediate trigger may be the Desktop task execution path itself: app-server/tool execution/subprocess/WebView state created during active turns. Large historical threads likely increase the amount of state and tool output involved, but the memory blow-up can also occur during ordinary active tasks.

    This makes the issue more severe than initially described: the system can stay stable while Codex is idle, then become unstable after task execution begins, regardless of whether the thread is especially long.

    The RAMMap observations from the previous comment remain important: the unexplained memory is not accounted for by normal Process Private usage, and Page Table/system memory can remain high after Codex/task activity ends.

  5. Photosounder commented on Jul 11, 2026

    @Photosounder
    Photosounder
    on Jul 11, 2026

    I have this too and it took me days to figure out what the culprit was, I just figured it out through wprui and leave Codex open not doing anything (somehow it called git.exe a lot regardless). I would progressively get up to 7 GB of non-paged memory in about 3 days with no recourse other than a reboot, whereas I would normally leave my machine up for weeks.

    Quick rant: OpenAI has unlimited access to ChatGPT 6.0, they could probably fix this easily, if anyone in the world can fix such bugs easily it's them because they have the tech. Yet here we are, having to reboot our computers regularly because of an app.

  6. aujurd22 commented on Aug 4, 2026

    @aujurd22
    aujurd22
    on Aug 4, 2026 – with ChatGPT Codex Connector

    Additional Windows reproduction on a newer desktop build.

    Environment:

    • Windows desktop app
    • Bundled Codex build: OpenAI.Codex_26.727.6591.0
    • 31.12 GiB total physical RAM

    Reproduction:

    1. Open/resume a long ERP conversation.
    2. Monitor the local codex.exe app-server process.
    3. The process was codex.exe -c features.code_mode_host=true app-server --analytics-default-enabled.

    Observed behavior:

    • codex.exe private memory reached approximately 16.77 GiB and working set reached approximately 16.79 GiB.
    • During consecutive samples it continued increasing (about 16.43 -> 16.79 GiB).
    • System free RAM fell to approximately 1.97 GiB.
    • The process was terminated to prevent the machine from becoming unresponsive.
    • After termination, free RAM recovered to approximately 18.39 GiB.
    • The automatically restarted codex.exe used approximately 0.05 GiB private memory / 0.11 GiB working set.

    Session-size evidence:

    • The affected ERP UI/deployment conversation's archived rollout file is approximately 918.6 MiB on disk.
    • Other ERP P0 rollout files checked for comparison were only approximately 1.35-1.42 MiB.

    This suggests that resuming/loading a large historical rollout can cause severe app-server memory amplification or retention. The exact allocator/root cause is unknown, but this is reproducible as continuous private-memory growth in the Codex app-server and is not normal system cache behavior.

    Expected:
    Opening a long conversation may temporarily use additional memory, but memory should remain bounded and the app should not consume most of a 32 GB system.

    No raw ERP transcript, project files, credentials, or customer data are attached.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbugSomething isn't workingperformancesessionIssues involving session (thread) management, resuming, forking, naming, archivingwindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions