agentleFS
hanzwhanzw/potato-chips/skills/codex-memory-health/SKILL.md

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.

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
  1. Distinctive:

    Run the bundled audit from this skill directory:

    line 17
  2. Very specific:

    If the report lists SAFE_CLEAN_CANDIDATES, run:

    line 25
  3. Very specific:

    Use --disk only when the complaint is storage, not RAM.

    line 46
  4. Distinctive:

    If a renderer alone grows large, preserve task state first, then recommend closing unused Codex tasks or restarting the desktop app.

    line 48
  5. Distinctive:

    Prefer one stable semantic-index project per repository.

    line 52
  6. Very specific:

    Keep generated trees, node_modules, nested worktrees, build outputs, browser artifacts, and caches excluded from semantic indexing.

    line 53
  7. Distinctive:

    Treat repeated orphan helpers as a lifecycle bug: capture the exact command, age, RSS, and parent chain before updating or disabling the …

    line 54
  8. Very specific:

    Never delete ~/.codex/sessions, ~/.codex/memories, ReMe data, repository files, credentials, or handoff state.

    line 59
  9. Distinctive:

    Never clear all caches to fix RAM.

    line 60
  10. Very specific:

    Never use broad pkill node, killall, unresolved globs, or unverified PID lists.

    line 61

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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 --audit

The 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-safe

The cleanup must re-resolve every PID and fail closed if its command or parent changed. It may terminate only:

  1. orphan codebase-mcp --daemon processes whose installed script has disappeared or whose RSS is at least 2 GiB;
  2. 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

  1. Confirm system pressure with physical memory, memory_pressure, and swap.
  2. Rank by RSS; use VSZ only as diagnostic context.
  3. Prove ownership and orphan status from PID, PPID, exact command, and installed-script existence.
  4. Clean the smallest recoverable target and immediately remeasure.
  5. Use --disk only 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 --disk

Download now (ZIP)

Does 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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.