codex-memory-health
Skill1 starsChanged 3 months agoMITView on GitHub
Diagnose and safely remediate Codex or ChatGPT desktop memory pressure, unusually high RAM or swap, runaway codebase/Serena daemons, orphan MCP servers, or claims that Codex uses tens or hundreds of gigabytes. Use when Activity Monitor shows extreme Codex memory, the machine swaps heavily, MCP tools become slow, or long agent sessions leave helper processes behind.
In this repositoryOne other file it gives its agents.
The file
We split this skill into the rules it gives an agent
10 rules. About 0 are common, 5 are distinctive, and 5 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈5
Distinctive · estimate
This author's own choices. Worth a look.
5
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- could be automatic: a setting could enforce it
- Distinctive: line 17
Run the bundled audit from this skill directory:
- Very specific: line 25
If the report lists SAFE_CLEAN_CANDIDATES, run:
- Very specific: line 46
Use --disk only when the complaint is storage, not RAM.
- Distinctive: line 48
If a renderer alone grows large, preserve task state first, then recommend closing unused Codex tasks or restarting the desktop app.
- Distinctive: line 52
Prefer one stable semantic-index project per repository.
- Very specific: line 53
Keep generated trees, node_modules, nested worktrees, build outputs, browser artifacts, and caches excluded from semantic indexing.
- Distinctive: line 54
Treat repeated orphan helpers as a lifecycle bug: capture the exact command, age, RSS, and parent chain before updating or disabling the …
- Very specific: line 59
Never delete ~/.codex/sessions, ~/.codex/memories, ReMe data, repository files, credentials, or handoff state.
- Distinctive: line 60
Never clear all caches to fix RAM.
- Very specific: line 61
Never use broad pkill node, killall, unresolved globs, or unverified PID lists.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Codex Memory Health
Measure before cleaning. Distinguish four different quantities:
- RSS is physical memory currently resident for a process.
- VSZ is reserved virtual address space and is not RAM usage.
- Swap records system pressure and may remain allocated briefly after RAM is freed.
- Cache/session directory size is disk usage, not memory.
Fast path
Run the bundled audit from this skill directory:
bash scripts/codex_memory_health.sh --auditThe audit prints executable names, not full command arguments, so CLI credentials are not copied into the transcript. A normal run should finish in well under one second.
If the report lists SAFE_CLEAN_CANDIDATES, run:
bash scripts/codex_memory_health.sh --clean-safeThe cleanup must re-resolve every PID and fail closed if its command or parent changed. It may terminate only:
- orphan
codebase-mcp --daemonprocesses whose installed script has disappeared or whose RSS is at least 2 GiB; - orphan Cloudflare MCP child/launcher pairs where the launcher is already adopted by
launchd(PPID=1).
Before changing this skill, run bash tests/test_codex_memory_health.sh. The fixture detector covers Node runtime flags, Python/argument decoys, unsafe Cloudflare parent chains, caller-supplied snapshot rejection, and command-argument redaction. On macOS, also run bash tests/test_live_cleanup.sh; it creates one owned orphan, asserts it is the only safe target, and exercises exact-target TERM/KILL revalidation.
These helpers restart on demand. Never auto-terminate ChatGPT, Codex app-server, Codex Renderer, Chrome, an attached test server, or an arbitrary Node process.
First-principles decision order
- Confirm system pressure with physical memory,
memory_pressure, and swap. - Rank by RSS; use VSZ only as diagnostic context.
- Prove ownership and orphan status from PID, PPID, exact command, and installed-script existence.
- Clean the smallest recoverable target and immediately remeasure.
- Use
--diskonly when the complaint is storage, not RAM.
If a renderer alone grows large, preserve task state first, then recommend closing unused Codex tasks or restarting the desktop app. Do not kill the current renderer from an agent turn.
Recurrence prevention
- Prefer one stable semantic-index project per repository. Do not activate every disposable worktree as a separate codebase project.
- Keep generated trees,
node_modules, nested worktrees, build outputs, browser artifacts, and caches excluded from semantic indexing. - Treat repeated orphan helpers as a lifecycle bug: capture the exact command, age, RSS, and parent chain before updating or disabling the integration.
- Re-run the audit after MCP-heavy work or when swap exceeds one quarter of physical memory.
Hard safety boundaries
- Never delete
~/.codex/sessions,~/.codex/memories, ReMe data, repository files, credentials, or handoff state. - Never clear all caches to fix RAM; cache deletion addresses disk usage and can disrupt a running app.
- Never use broad
pkill node,killall, unresolved globs, or unverified PID lists. - Report any target that is large but not provably safe instead of killing it.
For optional disk attribution, run:
bash scripts/codex_memory_health.sh --diskDoes it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

