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

Codex Desktop 26.1007.30912, build 20156 (read from the installed app's Info.plist).
Bundled CLI/app-server: codex-cli 0.162.0-alpha.17.2.

What subscription do you have?

Not included in this public diagnostic report.

What platform is your computer?

macOS 15.5, Apple silicon, 16 GiB RAM.
uname -mprs: Darwin 24.5.0 arm64 arm.

What issue are you seeing?

Completed, idle chats retain separate local tool runtimes for a long time while the Mac is already under yellow memory pressure. Opening historical chats also initializes additional helper batches. Users cannot easily distinguish active work from retained idle runtimes or release one idle chat's resources while keeping its history and normal sidebar position.

This report is deliberately about expensive idle retention and safe reclamation, not a proven unbounded memory leak. Automatic cleanup DID occur during observation.

Measurements on 2026-10-12

Initial system snapshot:

• Activity Monitor: about 13.7 GB used out of 16 GB, yellow memory pressure.
• Compressed memory: about 6.4–7.5 GiB across samples.
• Swap initially about 665–673 MiB; later about 4.0 GiB during a period that included browsing historical chats. Other apps were also running, so this is not attributed exclusively to Codex.
• Codex-owned executable processes: roughly 6.5–7.0 GiB summed physical-footprint accounting initially.

A representative breakdown:

• 13 renderer processes: approximately 3.3 GiB.
• 9 code-review service instances: approximately 781 MiB.
• 9 desktop app-tools service instances: approximately 379 MiB.
• Other computer-use/REPL helpers: approximately 1 GiB.
• Most tool helpers showed negligible CPU-time changes in a 35-second sample.

By correlating process creation times, parent/child relationships, thread start/resume logs, and live thread status, two completed idle chats could be associated with:

• Chat A: 8 tool/runtime processes, approximately 423 MiB.
• Chat B: 5 tool/runtime processes, approximately 164 MiB.

Both chats' most recent turns were completed. A separate active task and the diagnostic chat were deliberately preserved; no processes were killed and the app was not restarted.

Cleanup evidence and limits

• After the user closed two embedded pages, renderer count fell from 13 to 11 and old renderer PIDs disappeared. Thus not all renderers were leaked, and renderer count is not equivalent to visible tab count.
• Logs later recorded successful thread/unsubscribe operations for some idle chats; their helper groups exited.
• Chat B subsequently became notLoaded and all 5 associated helpers were absent. Chat A still retained approximately 422 MiB in 8 helpers at the last check.
• The helper exits establish lifecycle cleanup, not an equivalent measured drop in system-wide physical RAM.
• During historical-chat browsing, new helper batches aligned with thread/resume events. Codex process footprint rose substantially during that interval, but ongoing activity prevents treating this as an isolated A/B measurement.

Read-only inspection of this installed build's frontend bundle found an inactive-thread unsubscriber with a 10,800,000 ms (3-hour) idle TTL and a cap of 10 eligible inactive owner threads. Active views, stream followers and running work are excluded. This is an implementation clue, not proof that every retained process is abandoned or that all memory-pressure handling is absent.

What steps can reproduce the bug?

Observed workflow, rather than a clean-room minimal reproduction:

1. Use several local chats with bundled desktop tools/code-review and computer-use/REPL facilities.
2. Finish work in some chats while leaving another task running.
3. Switch away from completed chats; inspect their helper process groups and live thread status.
4. Open several historical chats without starting new user tasks.
5. Observe new helper batches correlated with thread resume, and idle groups remaining resident.
6. Close embedded pages separately and compare renderer exit behavior with tool-runtime retention.
7. Observe eventual automatic unsubscribe and helper exit without terminating active work.

What is the expected behavior?

• Bound retained idle runtime memory, especially on a 16 GiB machine under memory pressure.
• Start tool servers lazily or safely reuse them where appropriate.
• Reclaim eligible idle runtimes more promptly under pressure.
• Provide a supported “Release idle runtime” action that preserves chat history AND normal sidebar placement, and refuses to unload running tasks or live dependencies.
• Show chat-to-process/resource ownership so users can understand what will be released.
• Avoid requiring whole-app restart, forced process termination, or chat archival merely to reclaim idle resources.

Additional information

Related: #44996 and #51649. This newer macOS report adds observed successful cleanup, measured per-idle-chat groups, and a specific retention-policy/release-control concern; it does not claim the same unbounded failure mechanism as those reports.

Memory methodology: macOS proc_pid_rusage with RUSAGE_INFO_V2 / ri_phys_footprint, plus ps, vm_stat, sysctl, Activity Monitor and sanitized app lifecycle metadata. Summed footprints are process accounting (including compressed-memory charges), not a promise of uniquely reclaimable resident RAM.

Private chat titles/IDs, project paths, credentials, full transcripts and raw logs have been omitted. No heap dump, forced-GC test, controlled restart comparison or exhaustive UI audit was performed. The available automation tools exposed archival but no standalone runtime-release operation; that alone does not prove no such action exists anywhere in the UI.