Codex Writing Gigabytes a Day? Check the Plugin Cache

If Codex is writing gigabytes while an interactive session sits idle, do not delete ~/.codex. First check whether cache/remote_plugin_catalog/*.json is being rewritten every few seconds, close extra Codex sessions and versions, update Codex, and repeat the measurement. If the writes stop when a fresh session starts with remote_plugin disabled, you have isolated the remote plugin catalog path without destroying sessions, credentials, or installed plugins.

The widely shared figure of roughly 65 GB per day came from one measured Codex CLI 0.145.0 setup with a 7.7 MB catalog, about 40 plugins, and an older resident app-server sharing the same CODEX_HOME. It is not a universal Codex write rate. Measure your own machine before drawing a conclusion.

First, Identify Which Codex Write Is Growing

Several unrelated symptoms are described as "Codex is wearing out my SSD":

The plugin catalog report is specifically about the first path. The reporter measured 55 whole-file rewrites in 421 seconds, and 35 of the 55 payloads had an identical SHA-256 hash. That evidence does not prove that every disk spike comes from the same mechanism.

Prerequisites

Before diagnosis:

1. Stop starting new Codex tasks.

2. Save editor buffers and inspect repository state.

3. Record the Codex version, installation paths, and active process IDs.

4. Keep cache contents private. A catalog can expose account or integration metadata.

5. Do not delete ~/.codex, logs_2.sqlite, session JSONL, or plugin folders as a first step.

Preserve the repository first:

git status --short
git diff --stat

Expected result: you know which changes belong to active work before closing a process that might still be writing.

Step 1: Find Every Codex Version and Process

On macOS or Linux:

command -v -a codex
codex --version
ps -axo pid=,ppid=,etime=,command= | rg 'codex|Codex|ChatGPT'

On Windows PowerShell:

Get-Command codex -All | Select-Object Source, Version
codex --version
Get-CimInstance Win32_Process |
  Where-Object { $_.Name -match "codex|ChatGPT" } |
  Select-Object ProcessId, ParentProcessId, Name, CommandLine

Expected result: each executable path and running process is visible. The original reproduction included CLI 0.145.0 and an older 0.144.5 app-server using the same home directory. Two versions are not required for the catalog rewrite, but they can make model-cache churn worse.

Quit idle sessions through their normal UI or terminal controls. Do not use a broad killall or pkill -f command. If a process must be terminated, verify its PID and preserve its work first.

Step 2: Locate the Catalog Without Opening It

On macOS or Linux:

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

find "$catalog_dir" -type f -name '*.json' -exec ls -lh {} \; 2>/dev/null

On Windows PowerShell:

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

$catalogDir = Join-Path $codexHomeDir "cache/remote_plugin_catalog"
Get-ChildItem -LiteralPath $catalogDir -File -Filter "*.json" -ErrorAction SilentlyContinue |
  Select-Object FullName, Length, LastWriteTimeUtc

Expected result: zero or more catalog files are listed with sizes and timestamps. An empty directory means this exact mechanism is not your current explanation.

Step 3: Watch Timestamps and Hashes for Five Minutes

Keep one otherwise idle Codex session open. On macOS:

for _ in {1..60}; do
  date +%T
  find "$catalog_dir" -type f -name '*.json' \
    -exec stat -f '%m %z %N' {} \; \
    -exec shasum -a 256 {} \; 2>/dev/null
  sleep 5
done

On Linux:

for _ in {1..60}; do
  date +%T
  find "$catalog_dir" -type f -name '*.json' \
    -exec stat -c '%Y %s %n' {} \; \
    -exec sha256sum {} \; 2>/dev/null
  sleep 5
done

On Windows PowerShell:

1..60 | ForEach-Object {
  Get-Date -Format T
  Get-ChildItem -LiteralPath $catalogDir -File -Filter "*.json" -ErrorAction SilentlyContinue |
    ForEach-Object {
      [PSCustomObject]@{
        ModifiedUtc = $_.LastWriteTimeUtc
        Bytes = $_.Length
        Sha256 = (Get-FileHash -Algorithm SHA256 -LiteralPath $_.FullName).Hash
        Path = $_.FullName
      }
    }
  Start-Sleep -Seconds 5
}

Expected result for this reproduction: the modification time advances repeatedly while the size and SHA-256 often remain unchanged. Record the observation window, rewrite count, file size, and number of distinct hashes. Do not extrapolate a daily write rate from a very short sample without labeling it as an estimate.

If the catalog stays unchanged, inspect models_cache.json, logs_2.sqlite*, and the project paths separately. Do not apply a plugin-cache workaround to a different write source.

If the actual problem is a large saved conversation rather than an actively rewritten cache, use Codex Session JSONL Filling Your Disk? Clean It Up Safely to verify the session identity before removing anything.

Step 4: Run a No-Session Negative Control

Quit every verified Codex session normally, then rerun the watcher for five minutes.

Expected result: catalog modification times stop changing. If they continue, return to the process list. A desktop app-server, extension, or second CLI may still be active.

This negative control matters because the original report found no catalog rewrites when there was no session activity. It connects the writes to a live Codex caller rather than a generic operating-system process.

Step 5: Update Once and Remove Version Churn

With work preserved and all Codex sessions closed, update through the supported updater or the package manager that owns your installation:

codex update
codex --version
command -v -a codex

Then restart one short session and repeat Steps 3 and 4. Do not assume a newer version fixed the bug unless the measured rewrite rate changes. At the time of writing, the upstream issue remained open and Codex 0.146.0 release notes did not claim a plugin catalog cache fix.

Expected result: one intended Codex version owns the active session. If two versions remain, find which app or package manager launched each one before removing anything.

Step 6: Test the Remote Plugin Boundary

First confirm that your Codex version exposes the feature:

codex features list | rg '^remote_plugin\s'

If it does, start one temporary diagnostic session with the remote catalog disabled:

codex --disable remote_plugin

Leave that session idle while the watcher runs again. Expected result: remote_plugin_catalog stops refreshing or refreshes materially less often. This is a diagnostic and temporary containment step. It can remove remote plugin discovery, installation, update, or sharing behavior from that session, so do not treat it as a permanent configuration recommendation.

If the writes continue at the same rate, re-enable the normal session and investigate another path. If they stop and you need remote plugins, keep sessions bounded, close idle clients, and follow the upstream issue for a confirmed fix.

What Not to Do

Why This Diagnosis Works

The watcher distinguishes a timestamp change from a content change. The no-session control shows whether a live Codex process owns the behavior. The single-version check removes cache invalidation caused by mismatched clients. Finally, the one-session feature test isolates the remote catalog without deleting user data.

That sequence turns a broad fear about SSD wear into a reproducible report: exact path, version, process, time window, bytes, hashes, and a negative control.

Run One Bounded Issue Check

After local writes are contained, use Aident Loadout to check whether a fix or new reproduction has landed without pasting a GitHub token into the session. 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 about plugin catalog, cache, SQLite,
or excessive disk writes, including version, date, status, and URL.
Do not create or edit issues, change files, or ask for a provider key.
Stop after five results

Expected result: five current issues, zero provider writes, and zero pasted secrets. That is the measurable CTA.

Sources

• Plugin catalog cache is rewritten after every plugin/list, OpenAI Codex issue, opened July 25, 2026

• Codex 0.146.0 release notes, OpenAI Codex release, July 29, 2026

• Codex feature registry, OpenAI Codex source, accessed August 1, 2026

• Codex configuration schema, OpenAI Codex source, accessed August 1, 2026

• Codex CLI still persists high-frequency trace events to SQLite, OpenAI Codex issue, opened July 24, 2026

• Codex is wearing out our devices, r/codex discussion, accessed August 1, 2026

Refresh this guide when OpenAI closes the catalog issue, documents a cache TTL or content check, changes the remote_plugin feature, or ships release notes that confirm a fix.