Skip to content
Join the waitlist

~/.codex/sessions is huge: what's in it and how to clean it safely

Codex writes every run to a rollout JSONL file and never prunes them — some users report hundreds of gigabytes. What the files are, what indexes them, and how to reclaim space without orphaning threads.

5 min read

If your disk filled up and ~/.codexis the culprit, you're not alone. An open issue titled “Insane Codex Disk Usage from Subagents” reports 755 GB in ~/.codex/sessions, and other commenters report anywhere from about 209 GiB to 890 GiB. Here's what's in that folder and how to reclaim the space without orphaning your threads.

What's in ~/.codex/sessions

Every Codex run is recorded as a rollout file, organized by date:

~/.codex/sessions/2026/10/13/rollout-2026-10-13T09-41-12-<uuid>.jsonl

Each rollout is an append-only JSONL log of the session: messages, tool calls and their output. Subagents and long-running tasks can make single files very large. If you've set CODEX_HOME, look there instead of ~/.codex.

As of October 2026, Codex doesn't delete old sessions on its own, so this folder only grows. Archiving a thread in Codex moves its rollout into ~/.codex/archived_sessions/. That tidies the list, but it doesn't free any space.

Measure it

# Total, including threads you've archived in Codex
du -sh ~/.codex/sessions ~/.codex/archived_sessions 2>/dev/null

# By month
du -sh ~/.codex/sessions/*/* | sort -h | tail

# The individual monsters
find ~/.codex/sessions -name 'rollout-*.jsonl' -size +100M -exec ls -lh {} +

The rollout files aren't the only record

On the Codex install we inspected in October 2026, sessions were also tracked in three other places:

  • a SQLite state database (state_5.sqlite), whose threadstable stores each rollout's path,
  • a session_index.jsonl file,
  • and a separate thread-history database (thread_history_1.sqlite) holding another copy of thread content.

The numbers in those names are schema versions and change between releases. If you delete rollout files, the database rows still point at them. Expect those threads to fail to resume.

A trap when inspecting the databases

Codex's SQLite files use WAL mode. Even opening them with sqlite3 -readonly creates -shm and -walfiles next to them. That's mostly harmless, but it's a write. To look without touching anything, copy the database and its sidecar files first:

mkdir -p /tmp/codex-inspect
cp ~/.codex/state_*.sqlite* /tmp/codex-inspect/
sqlite3 /tmp/codex-inspect/state_5.sqlite '.tables'

Reclaiming space safely

  1. Quit every Codex process:the CLI, IDE extensions and the desktop app. Its databases are shared, and they're actively written.
  2. Back up first, to encrypted storage. Rollouts contain command output and file contents in plaintext.
  3. Archive whole old months (for example ~/.codex/sessions/2026/05) rather than picking files at random, and accept that those threads won't resume unless you restore the files to the same path.
  4. Check the runtime cache too. On the machine we inspected, ~/.cache/codex-runtimes held a 321 MB leftover installer archive alongside the runtime itself.

The short version

  • Sessions are date-organized rollout JSONL files under ~/.codex/sessions, and they're never pruned.
  • Databases point at those files, so deleting rollouts leaves threads that can't resume.
  • Quit Codex, back up encrypted, archive by month, and restore to the exact path if needed.

More guides