Codex App Using Too Much Memory? Contain It Safely

If Codex is consuming tens of gigabytes of memory, stop new agent work, preserve the repository, identify whether the growth is in codex app-server, the desktop renderer, or a child process, then quit Codex normally. If the app is frozen, terminate only the verified Codex-owned process. Restart with one short thread and no optional integrations, then add concurrency, browser tools, and integrations back one at a time.

Do not start by deleting ~/.codex, session JSONL, or your project. Current reports describe several different failure shapes. A single cleanup recipe can destroy useful history without fixing the process that actually grew.

First, Distinguish RAM, Swap, and Disk

These symptoms can look alike:

Public reports in July and August 2026 include app-server growth to roughly 40-59 GB, an image-heavy 10.2 GB rollout associated with a 27 GB process footprint and 36 GB of swap, accumulated browser workers using 10-18 GB, a renderer crash loop with more than 170 leaked processes, and background shell or media children that continued after the intended task. Those reports prove recurrence, not one universal root cause.

Prerequisites

Before recovery:

1. Stop sending new prompts and cancel any agent turn you can still control.

2. Save open editor files and preserve repository work.

3. Record the Codex app or extension version, operating system, active project, and what the last task was doing.

4. Keep session files private. They can contain prompts, code, local paths, command output, screenshots, and secrets.

5. Do not use broad process-killing commands such as killall, pkill -f, or an unreviewed cleanup script.

Check the repository first:

git status --short
git diff --stat

Expected result: you know exactly which files are modified. Commit, stash, or copy valuable work through your normal reviewed workflow before terminating a process that may still be writing.

Step 1: Capture a Read-Only Process Snapshot

On macOS:

ps -axo pid=,ppid=,%cpu=,rss=,etime=,command= |
  rg 'Codex|ChatGPT|codex app-server|node|ffmpeg|python|powershell'

sysctl vm.swapusage
vm_stat

On Linux:

ps -eo pid,ppid,%cpu,rss,etime,cmd --sort=-rss |
  rg 'codex|node|ffmpeg|python|powershell'

free -h

On Windows PowerShell:

Get-Process |
  Where-Object {
    $_.ProcessName -match "Codex|ChatGPT|node|ffmpeg|python|powershell"
  } |
  Sort-Object WorkingSet64 -Descending |
  Select-Object Id, ProcessName, CPU, WorkingSet64, StartTime

Get-CimInstance Win32_Process |
  Where-Object {
    $_.Name -match "Codex|ChatGPT|node|ffmpeg|python|powershell"
  } |
  Select-Object ProcessId, ParentProcessId, Name, CommandLine

Expected result: you have process IDs, parent IDs, elapsed time, and command lines. On macOS and Linux, RSS is normally reported in KiB. It can understate the total impact after memory has been compressed or swapped, so compare it with the system-level output.

Do not assume every node, python, or shell process belongs to Codex. Match its parent PID and command line to the active task before taking action.

Step 2: Classify the Failure Shape

Use the snapshot to choose the next check.

codex app-server or the renderer is growing

This can correlate with long threads, many observed threads, or a large persisted rollout. Start a new short thread after recovery instead of immediately resuming the same one. If the old thread contained many images or large tool results, measure its storage in Step 4.

Child processes are accumulating

Look for repeated browser workers, node, ffmpeg, PowerShell, Python, test runners, or development servers. Confirm their parent chain and task command. A process that is still performing valuable work should be stopped through its own interface when possible.

Memory rises only under concurrency

Record the number of active threads, subagents, browser sessions, and background commands. Your recovery test should begin with one thread and no subagents. Adding ten agents back immediately removes the negative control you need.

Codex looks small but the machine is still under pressure

Check swap, compressed memory, and residual children. Closing the main window may not release a child that has been re-parented or a process holding a large swapped allocation.

Step 3: Stop Codex Without Broadly Killing Work

First use the app's normal Stop and Quit controls. Wait long enough for the process list to settle, then rerun the snapshot from Step 1.

If the app is frozen and a specific PID is verified, ask it to terminate cleanly.

On macOS or Linux:

kill -TERM <verified-pid

On Windows PowerShell:

Stop-Process -Id <verified-pid

Replace the placeholder with one PID from your snapshot. Recheck the process list before terminating any residual child. Do not escalate to a forced kill unless the exact process ignores a normal termination and you have preserved its output.

Expected result: the verified process exits, system memory pressure begins to fall, and unrelated editors, terminals, and development servers remain running.

If pressure does not fall, the terminated process was not the only owner. Return to the parent-child snapshot instead of killing every process with a familiar name.

Step 4: Check for an Oversized Session Without Opening It

On macOS or Linux:

codex_home_dir="${CODEX_HOME:-$HOME/.codex}"

find \
  "$codex_home_dir/sessions" \
  "$codex_home_dir/archived_sessions" \
  -type f -name "*.jsonl" -size +100M \
  -exec du -h {} + 2>/dev/null |
  sort -h |
  tail -20

On Windows PowerShell:

$codexHomeDir = if ($env:CODEX_HOME) {
  $env:CODEX_HOME
} else {
  Join-Path $env:USERPROFILE ".codex"
}

@("sessions", "archived_sessions") |
  ForEach-Object {
    Get-ChildItem -LiteralPath (Join-Path $codexHomeDir $_) -File -Filter "*.jsonl" -ErrorAction SilentlyContinue
  } |
  Sort-Object Length -Descending |
  Select-Object -First 20 FullName, Length

Expected result: you can see whether one rollout is unusually large without parsing its private contents. The 100M filter is a triage threshold, not an official limit.

Do not remove or edit a JSONL by filename. If one disposable session is clearly responsible, follow Codex Session JSONL Filling Your Disk? Clean It Up Safely, which uses the supported session commands and requires an identity check before deletion.

Step 5: Restart With a Minimal Reproduction

Update Codex through its normal distribution channel, restart the computer if swap remains stuck, and open one small repository in one new thread. Keep the first test bounded:

• no subagents;

• no browser or computer-use task;

• no MCP server or plugin that is not required;

• no image-heavy history;

• no background build, media, or test loop;

• one short read-only task with a clear stopping point.

Capture the process snapshot before the task, after it finishes, and five minutes later. Expected result: the task stops, child counts return near their baseline, and memory does not continue climbing while idle.

Then restore one dimension at a time: the required integration, one browser action, one subagent, or the original workspace. The first change that makes memory or child count grow again gives you a useful reproduction boundary.

For risky or unfamiliar workloads, isolate execution from the host rather than relying on process cleanup alone. See How to Run Claude Code or Codex Safely in a Docker Sandbox after that draft is published, or use the existing sandbox network isolation test.

Step 6: Report a Sanitized Reproduction

A useful issue report includes:

• Codex app, CLI, or extension version;

• operating system and physical memory;

• whether the growing process was app-server, renderer, or a child;

• PID, parent PID, elapsed time, RSS, swap or memory-pressure evidence;

• active thread and subagent count;

• enabled MCP servers or plugins;

• whether a new thread with integrations disabled stayed stable;

• session file sizes, but not the session contents;

• exact safe steps that reproduce the growth.

Do not upload raw rollouts, crash archives, screenshots, or command lines until you have removed credentials, local paths, repository names, and private content.

Why This Recovery Works

The process snapshot separates four boundaries that a single "Codex uses too much RAM" label hides: Codex core processes, UI processes, agent-launched children, and persisted thread state. Normal termination gives each process a chance to flush work. Exact-PID termination contains a hung component without taking unrelated work with it. A fresh one-thread test removes retained history and concurrency, while one-at-a-time restoration reveals which capability makes the symptom return.

This is containment and diagnosis, not proof of a permanent fix. If the same minimal reproduction grows after an update, stop repeating it and attach the sanitized evidence to the closest upstream issue.

Run One Bounded External Check

After the local process is stable, keep provider credentials outside the recovering agent and run a short read-only issue check through Aident Loadout. In your agent, paste:

Follow https://aident.ai/SETUP.md

Then ask:

Check my Aident Loadout account and Vault status.
Find a connected read-only GitHub issue search Action.
Inspect its current schema and preflight it.
Return five open openai/codex issues whose title mentions memory, RAM, swap,
app-server, renderer, or runaway child processes.
Do not create or edit issues, change files, or ask for a provider key.
Stop after five results

Expected result: five relevant issues return, no repository files change, no issue is created, and no GitHub credential appears in the prompt or output. That is the measurable CTA: five results, zero writes, zero pasted secrets.

Sources

• VS Code extension app-server grows unbounded and exhausts about 54 GB swap, OpenAI Codex issue, opened August 1, 2026

• Codex repeatedly grows to 55 GB and freezes macOS, OpenAI Codex issue, opened July 16, 2026

• Repeatable macOS OOM reaches 40-59 GB with runaway subprocesses, OpenAI Codex issue, opened July 29, 2026

• Image-heavy rollout reaches 27 GB footprint and 36 GB swap, OpenAI Codex issue, opened July 23, 2026

• Passive app-server subscriptions pin idle thread heaps, OpenAI Codex issue, opened July 28, 2026

• Browser-use workers accumulate to 10-18 GB, OpenAI Codex issue, opened July 15, 2026

• Renderer OOM loop with many concurrent threads and leaked processes, OpenAI Codex issue, opened July 23, 2026

• Background PowerShell child exhausts system memory, OpenAI Codex issue, opened July 26, 2026

• Duplicate runaway ffmpeg children consume about 900 percent CPU, OpenAI Codex issue, opened July 31, 2026

• Insane memory leaks happening as of this weekend, r/codex, July 20, 2026

• Insane performance issues with the Codex app?, r/codex, July 27, 2026

• Using Codex with your ChatGPT plan, OpenAI Help Center, accessed August 1, 2026