Codex Desktop main process leaks memory in Chromium PartitionAlloc / Memory Tag 253 on macOS

What version of the Codex App are you using?

Codex Desktop 26.623.141536 (CFBundleVersion 4753)

Previous reproduction on the same machine also happened on 26.623.101652 (CFBundleVersion 4674).

What subscription do you have?

ChatGPT Pro ($200 plan)

What platform is your computer?

macOS 26.5.2 (25F84)
Apple Silicon / arm64
Physical memory: 25,769,803,776 bytes
Bundle ID: com.openai.codex

What issue are you seeing?

Codex Desktop's main app process (/Applications/Codex.app/Contents/MacOS/Codex) grows to multi-GB physical footprint over long app uptime. The large memory is not primarily in renderer processes, MCP child processes, Chrome/Brave, or Playwright.

footprint attributes almost all of the main-process footprint to app-specific tag 14. vmmap maps the same retained memory to Memory Tag 253 and warns that the Chromium/Electron PartitionAlloc_* zone cannot be inspected.

This looks like an unreleased Chromium/Electron PartitionAlloc allocation pattern in the Codex Desktop main process.

Current observation, 2026-07-09 15:08 CEST

Main process:

PID: 80932
Path: /Applications/Codex.app/Contents/MacOS/Codex
Launch time: 2026-07-07 23:11:41 +0200
Uptime at sample: ~40 hours

top / Activity Monitor:

PID    COMMAND  MEM
80932  Codex    5658M

footprint -p 80932 -summary:

Codex [80932]: 64-bit    Footprint: 5717 MB

5547 MB        0 B        32 MB     102881    app-specific tag 14
 133 MB        0 B        53 MB      12671    app-specific tag 16

phys_footprint:      5717 MB
phys_footprint_peak: 5717 MB

vmmap -summary 80932:

Can't examine target process's malloc zone PartitionAlloc_0x12360a138, so memory analysis will be incomplete or incorrect.

Physical footprint:         5.6G
Physical footprint (peak):  5.6G
Writable regions: Total=6.5G ... resident=1.2G ... swapped_out=4.5G
Memory Tag 253  48.0G  996.4M  965.2M  4.5G  ... 102408 regions

Short trend while the app stayed open:

15:08:51 Footprint 5736 MB, tag14 5568 MB
15:09:02 Footprint 5741 MB, tag14 5572 MB
15:09:12 Footprint 5747 MB, tag14 5577 MB
15:09:23 Footprint 5756 MB, tag14 5584 MB
15:09:33 Footprint 5754 MB, tag14 5587 MB
15:09:44 Footprint 5758 MB, tag14 5593 MB

Previous observation, 2026-07-07

Same machine, previous Codex build 26.623.101652 (4674), main process PID 6031:

Codex [6031]: 64-bit    Footprint: 11 GB
11 GB        0 B        33 MB     205020    app-specific tag 14
phys_footprint:      11 GB
phys_footprint_peak: 11 GB
Memory Tag 253  48.0G  734.7M  702.1M  10.1G  ... 204342 regions

The region count roughly doubles from the 5.6 GB case to the 11 GB case (102408 -> 204342), which suggests accumulation of many small Memory Tag 253 / PartitionAlloc regions rather than one large loaded conversation or file.

Things ruled out locally

• Not Chrome/Brave/Playwright: the large footprint is in /Applications/Codex.app/Contents/MacOS/Codex.
• Not primarily renderer memory: renderers were hundreds of MB, while the main-process footprint was 5.6 GB and previously 11 GB.
• Not primarily MCP child processes: there are duplicate MCP processes, but their RSS is separate and far smaller than the main-process footprint.
• Not all threads being loaded: the Codex thread tool showed only current/recent threads as active or idle; most were notLoaded.
• Archiving old internal/subagent threads reduced unarchived thread count, but the main-process Memory Tag 253 footprint still grew again.
• Not the screenshot-compaction / huge-rollout pattern from #31040: this profile has no rollout JSONL files over 200 MB; largest observed rollout file was 78 MB, and ~/.codex total was about 2.0 GB.
• Not the heartbeat automation loop from #19563: this profile currently has one active cron automation and no heartbeat automation with target_thread_id.

Current Codex process tree context

At the 5.6 GB sample, descendant RSS totals were approximately:

main app                     count=  1 rss_mib= 1379.6
renderer                     count=  3 rss_mib=  942.3
mcp-email python             count=  8 rss_mib=  432.0
codex app-server             count=  1 rss_mib=  391.2
mcp-email uv launcher        count=  8 rss_mib=  328.7
chromium utility service     count=  4 rss_mib=  324.0
github/google mcp node       count=  5 rss_mib=  300.5
gmail mcp node               count=  5 rss_mib=  220.4
computer-use client          count=  5 rss_mib=  178.0
gpu service                  count=  1 rss_mib=  177.8

Those child processes are not ideal, but they do not explain the main-process footprint/Memory Tag 253 numbers.

Related but not duplicate issues

• #18589: similar high RAM on macOS, but reported as content renderer memory. This report is specifically the main process with Memory Tag 253 / PartitionAlloc evidence.
• #30408 and #12491: MCP/child-process lifecycle leaks. Relevant adjacent issue, but not the source of the 5.6 GB / 11 GB main-process footprint here.
• #24510 and #29007: unbounded thread metadata / SQLite hot paths. Adjacent local-history scalability family, but this profile is much smaller and the retained memory is in Memory Tag 253 / PartitionAlloc.
• #31040: screenshot compaction / multi-GB rollout ingestion. Not matching this profile; no huge rollout files were found locally.
• #19563: heartbeat automation resume/unsubscribe loop. Not matching this profile; no heartbeat automation with target_thread_id was present.

Expected behavior

Codex Desktop's main Electron process should not accumulate multi-GB PartitionAlloc / Memory Tag 253 physical footprint during normal long-running use. Memory should stabilize or be released after windows, threads, tool views, or internal subscriptions are no longer active.

Actual behavior

The main app process grows over long uptime from normal size to 5.6 GB and previously 11 GB physical footprint, with almost all retained memory under app-specific tag 14 / Memory Tag 253 and PartitionAlloc_*.

Workaround

Quit and relaunch Codex Desktop. After restart, the main process returns to hundreds of MB, but it grows again over app uptime.

Additional information

I can provide sanitized excerpts of the footprint, vmmap, sample, process tree, and local state diagnostics if useful. I am not attaching raw local session logs publicly because they may contain private prompts, paths, and project metadata.