Codex Eating Disk Space and SSD Wear? A Safe Cleanup Playbook (2026)

You open your Mac one morning and the disk is nearly full. You didn't download anything big. You didn't render a video. But somewhere in the last few weeks, while you were happily letting OpenAI's Codex CLI grind through a refactor, a quiet little folder in your home directory swelled into something the size of a movie library. We've watched this happen on our own machines, and the first reaction is always the same: where did all that space go, and is it hurting my SSD? This is a maintenance problem with a calm, repeatable fix.

Quick Answer

If Codex is eating disk space, the cause is almost always its local trace and log store under ~/.codex/ — a SQLite database plus a write-ahead-log file that can grow very large under heavy use. The safe fix, as of June 2026, is: close Codex, run a 30-second size check, then delete only the specific log/SQLite/WAL files (never a broad rm -rf on a guessed path), add a scheduled prune, and exclude that folder from backups so it isn't re-copied forever. This playbook is for anyone running the Codex CLI day to day — solo builders, small teams, and non-engineers who "vibe-code" small tools. It is not a concern if you only use Codex occasionally, or if you use a different agent. Tools change between versions, so check the official Codex docs and the GitHub issue tracker for current behavior before you delete anything.

What This Problem Is

OpenAI Codex — the CLI coding agent that runs in your terminal — keeps a local trace and log store under its home directory, ~/.codex/. That store includes a SQLite database and a write-ahead-log file (something like logs_*.sqlite-wal). Under heavy use, those files can grow very large and write a lot of data to disk over time. The short version: Codex is logging its own activity continuously, and that log doesn't shrink on its own. So the "missing" space isn't a virus or a mystery — it's an agent doing its job a little too enthusiastically and never cleaning up after itself.

One detail makes this trickier than a normal log file. Based on reports on the public openai/codex GitHub issue tracker (open as of June 2026 — check the tracker for current status, since Codex updates often), the verbose tracing is written regardless of the RUST_LOG environment variable. In other words, turning logging "down" the usual way doesn't stop the writes. That's why people get surprised: they think they disabled logging, and the disk keeps filling.

Who Should Care

• Best for: Daily Codex CLI users on laptops with smaller SSDs (256–512 GB), where a runaway log folder actually threatens free space; and anyone who runs Codex in long, heavy sessions.
• Also useful for: Small teams standardizing a setup, people whose cloud backup keeps re-uploading the same growing folder, and tinkerers who want a tidy machine.
• Not a concern for: Occasional users with large drives and light sessions; anyone not using the Codex CLI at all. If you're on Claude Code or Cursor, this specific log sink doesn't apply (more on that below) — though no tool is maintenance-free in general.

What You Need

The Fix at a Glance

Step-by-Step

1. Measure first. Run the size check (commands below) to confirm ~/.codex/ is actually what's eating your space. Don't delete blind.
2. Close Codex completely. Quit the CLI and the desktop app if you use it. Deleting an active SQLite/WAL file while the process is running can corrupt state.
3. Confirm the exact path. List the folder and look for the SQLite database and the *.sqlite-wal file. Make sure you're looking at ~/.codex/ and not something else.
4. Delete only the specific log files. Target the log/SQLite/WAL files by name. Never run a broad recursive delete on a path you only half-remember.
5. Re-measure. Run the size check again to confirm the space dropped. Note: one user reported that deleting the store didn't always immediately reclaim space — if so, a restart or a moment for the filesystem to settle usually helps.
6. Automate the prune. Schedule the cleanup so you're not doing this by hand every week.
7. Exclude from backup/sync. Add the log paths to your backup and cloud-sync ignore lists so they aren't copied over and over.

Copy-and-Paste Commands

These are the actual diagnostic and cleanup commands. Read each one before you run it. Anything marked illustrative is a pattern to adapt, not a guaranteed-exact path — confirm filenames on your own machine, because Codex changes between versions.

1) The 30-second size check.

# macOS / Linux
du -sh ~/.codex

# Windows PowerShell
Get-ChildItem "$env:USERPROFILE\.codex" -Recurse -File | Measure-Object Length -Sum

2) See what's inside, biggest first (so you know exactly which files to remove):

# macOS / Linux
ls -lhS ~/.codex
du -ah ~/.codex | sort -rh | head -n 15

# Windows PowerShell
Get-ChildItem "$env:USERPROFILE\.codex" -Recurse -File |
  Sort-Object Length -Descending |
  Select-Object -First 15 FullName, @{Name='MB';Expression={[math]::Round($_.Length/1MB,1)}}

3) Safe cleanup — close Codex first, then delete only the log/SQLite/WAL files. This targets specific files by pattern; it does not wipe the whole folder (your config and auth live there too). Illustrative patterns — confirm the actual names from step 2 before deleting:

# macOS / Linux  —  Codex must be closed
# Look, then delete by specific pattern. No broad rm -rf on a guessed path.
ls -lh ~/.codex/logs_*.sqlite* 2>/dev/null
rm -i ~/.codex/logs_*.sqlite-wal
rm -i ~/.codex/logs_*.sqlite-shm
# Only remove the main log db if you've confirmed it's the trace store, not config:
rm -i ~/.codex/logs_*.sqlite

# Windows PowerShell  —  Codex must be closed
Get-ChildItem "$env:USERPROFILE\.codex" -Filter "logs_*.sqlite*" |
  ForEach-Object { Write-Host $_.FullName }
Remove-Item "$env:USERPROFILE\.codex\logs_*.sqlite-wal" -Confirm
Remove-Item "$env:USERPROFILE\.codex\logs_*.sqlite-shm" -Confirm
# Confirmed it's the trace store, not config? Then:
Remove-Item "$env:USERPROFILE\.codex\logs_*.sqlite" -Confirm

The -i (macOS/Linux) and -Confirm (PowerShell) flags make each deletion ask first. Keep them. They're cheap insurance against fat-fingering a path.

4) A scheduled prune. Trim the WAL/log files on a cadence so the folder never balloons again. Illustrative — adapt the path and schedule:

# macOS / Linux  —  cron entry (run `crontab -e`)
# Weekly, Sunday 3am: remove stale Codex WAL/shm files when Codex isn't running.
0 3 * * 0  find "$HOME/.codex" -maxdepth 1 -name 'logs_*.sqlite-wal' -delete; find "$HOME/.codex" -maxdepth 1 -name 'logs_*.sqlite-shm' -delete

# Windows  —  Task Scheduler one-liner to register a weekly cleanup task
$action  = New-ScheduledTaskAction -Execute "powershell.exe" `
  -Argument '-NoProfile -Command "Remove-Item \"$env:USERPROFILE\.codex\logs_*.sqlite-wal\",\"$env:USERPROFILE\.codex\logs_*.sqlite-shm\" -ErrorAction SilentlyContinue"'
$trigger = New-ScheduledTaskTrigger -Weekly -DaysOfWeek Sunday -At 3am
Register-ScheduledTask -TaskName "Prune Codex logs" -Action $action -Trigger $trigger

5) Exclude the log paths from backup / cloud-sync so they aren't re-copied endlessly:

# macOS Time Machine — exclude the Codex folder
sudo tmutil addexclusion ~/.codex

# Linux (restic example) — pass an exclude when backing up
restic backup ~ --exclude="$HOME/.codex/logs_*.sqlite*"

# Windows — if you use OneDrive/Dropbox selective sync, un-tick ~/.codex in the app's settings (GUI).

Optional — point the log dir somewhere less precious. On macOS/Linux you can keep the trace files on a RAM-backed tmpfs or a secondary disk so your main SSD isn't taking the sustained writes. This is more involved and version-dependent; check the official Codex documentation for the supported way to relocate its data directory before symlinking anything by hand.

Example: What You'll See

A typical "uh oh" moment looks like this — the size check returns something far bigger than you expected for a logging folder:

$ du -sh ~/.codex
214G    /Users/you/.codex

$ ls -lhS ~/.codex
-rw-r--r--  1 you  staff   180G  Jun 21 09:14  logs_trace.sqlite-wal
-rw-r--r--  1 you  staff    33G  Jun 21 09:14  logs_trace.sqlite
-rw-r--r--  1 you  staff    16M  Jun 21 09:14  logs_trace.sqlite-shm

That WAL file doing most of the damage is the classic signature. For context, one user on the GitHub tracker reported the store reaching hundreds of GB, and another estimated cumulative writes on the order of hundreds of terabytes per year — that TB/year number is one user's estimate in a GitHub issue, not an official OpenAI figure, so treat it as a rough signal, not gospel.

Example: After the Fix

After closing Codex and removing the specific WAL/SQLite files, the same check looks healthy again:

$ du -sh ~/.codex
1.1G    /Users/you/.codex

One honest caveat: a user reported that deleting the store didn't always immediately reclaim the space — sometimes the number lags until the process fully releases the file or you restart. If your free-space readout doesn't move right away, give it a minute or reboot, then re-check. A separate report tied an oversized store to the desktop app failing to start; if your Codex app won't launch, an overgrown ~/.codex/ is worth ruling out first.

Tested Notes

• Input type: A laptop with a single internal SSD where ~/.codex/ had grown into the hundreds of GB after weeks of heavy agent sessions.
• Tool used: OpenAI Codex CLI.
• Best result: Closing Codex and deleting only the logs_*.sqlite-wal / -shm files (then the trace .sqlite once confirmed) reclaimed the bulk of the space safely, with config and auth left untouched.
• What failed: Lowering RUST_LOG did not stop the writes (reported behavior), so "just turn logging down" is not a fix. Deleting did not always reclaim space instantly.
• Manual edits still needed: Confirming the exact filenames on your machine, deciding whether to relocate the log dir, and setting the schedule/backup-exclusions to fit your setup.

Pitfalls We've Actually Hit

The first trap is deleting while Codex is still running. SQLite uses that WAL file as live state; yank it mid-write and you can corrupt the store. Always close the CLI (and the desktop app) first. The second is over-deleting — your config and login also live under ~/.codex/, so a blanket wipe logs you out and resets your settings. Target the log/WAL files specifically. The third is assuming RUST_LOG saves you; in the reported behavior it doesn't touch these writes, so don't rely on it. And the fourth is the disappearing-space illusion: if free space doesn't jump immediately, that matches what one user reported — wait or restart before assuming the delete failed.

Common Mistakes

1. Running rm -rf ~/.codex to "just clear it." That nukes config and auth too, and a broad recursive delete on a guessed path is exactly the kind of move a careful operator never makes.
2. Deleting with Codex still open. Risks corrupting the SQLite store. Close it first, every time.
3. Trusting RUST_LOG to stop the writes. Reported behavior says it doesn't, so the folder keeps growing.
4. Letting backup/cloud-sync re-upload the folder. You delete it locally, but your backup keeps a giant copy and re-syncs it — wasted space and bandwidth.
5. Treating the TB/year figure as official. It's one user's estimate in a GitHub issue. Useful as a "manage this," not a measured fact.

Tool Alternatives

FAQ

Will heavy Codex logging actually wear out my SSD?

Probably not quickly. SSDs have a finite write endurance, measured as TBW (terabytes written), and sustained background writes do consume that budget plus your free space. But modern consumer SSDs carry high TBW ratings, so this is worth managing, not panicking over. As of June 2026, the sensible posture is to prune regularly and consider relocating the log dir if you run Codex hard — treat it as routine maintenance rather than an emergency.

Is it safe to just delete the whole ~/.codex folder?

We don't recommend it. That folder also holds your configuration and authentication, so wiping it logs you out and resets settings — and a broad recursive delete on a guessed path is risky on principle. Close Codex, confirm the exact filenames, and delete only the logs_*.sqlite-wal, -shm, and (once confirmed) the trace .sqlite. Keep a confirmation flag like -i or -Confirm on the command so each deletion asks first.

Why doesn't lowering RUST_LOG stop the disk from filling?

According to reports on the openai/codex GitHub tracker (open as of June 2026), the verbose tracing is written regardless of the RUST_LOG environment variable — so turning logging "down" the usual way doesn't stop these specific writes. That's the surprise that catches people. Because this is reported behavior on a fast-moving tool, check the tracker and the official docs for the current status before assuming it still holds in your version.

I deleted the files but my free space didn't change — did it fail?

Not necessarily. A user reported that deleting the store didn't always immediately reclaim space. The filesystem may need the process to fully release the file, or a restart, before the number updates. Re-run the size check after closing Codex completely, and reboot if it's still stuck. If space genuinely never returns, double-check you removed the right large files (use the "biggest first" listing) rather than empty placeholders.

Does Claude Code or Cursor have the same disk problem?

Not this specific one. We verified that Claude Code does not have this always-on SQLite-WAL log sink — it's architecturally different, so the Codex log-store bug doesn't apply there, and the same goes for Cursor's different design. That said, no agent is maintenance-free in general: any tool can leave caches or data dirs that grow. Glance at each tool's storage occasionally and check its official docs for where it writes data, as of June 2026.

Final Recommendation

Make the 30-second ~/.codex size check a habit, not a fire drill. When it's big, close Codex, confirm the path, delete only the specific log/WAL files, then let a scheduled prune and a backup-exclusion keep it from coming back. Keep the framing proportional: this is housekeeping for a finite-endurance SSD, not a countdown to failure. And keep the deletion narrow and confirmed — narrow, on-purpose cleanup is the same discipline that keeps an AI agent from doing damage anywhere else on your machine.

👉 Bookmark this routine and pair it with our companion guide on keeping AI coding agents from deleting your files, then browse the rest of the AI Automation hub for the full local-agent maintenance set.

Related Guides

• How to stop an AI coding agent from deleting your files — the safety guardrails that make narrow deletion the default.
• The 5 problems of running AI coding agents locally (+ a maintenance routine) — the hub this playbook plugs into.
• ChatGPT vs Claude vs Gemini for coding web apps — how the major assistants compare when you actually build.
• AI Automation category hub — more local-agent ops guides.