Notes on coding agents and the pages they leave behind, on moving between notes apps, and on the plain mechanics of keeping what you think. Written and published from a Sumibako vault.
Where Codex keeps your sessions, why the folder can reach 50 GB, and how to read or export one
Where Codex stores session history (~/.codex/sessions), why rollout files reach gigabytes, what October changed, and how to export or clean up.
Prashant Shaw
Founder, Sumibako
6 min read
At the end of October, a Codex user posted a 38-page study of their own session files to OpenAI's forum. Ten months of work had produced 845 files totalling 52.49 GiB. Of that, the actual conversation, what they typed and what Codex answered, was 2.89 percent. Most of the rest was Codex's memory of the conversation, saved again and again, with every screenshot in it. Somewhere in there is a lesson about agents and hoarding, and I say that as somebody whose Downloads folder has its own weather.
This post is where Codex keeps your sessions, why that folder can get so big, what OpenAI changed in October, and how to read, export or clean up a session. Everything was checked on 3 November 2026 against OpenAI's Codex documentation, the Codex source code and release notes on GitHub, and the forum threads where people measured it.
๐๏ธ Where Codex keeps your sessions
Everything local lives under Codex's home folder, ~/.codex unless you set CODEX_HOME. OpenAI's advanced configuration page lists what you will find there: your config.toml, your login if it is not in the system keychain, history.jsonl, and "Other per-user state such as logs and caches".
That last line is doing a lot of work. The full sessions are not in history.jsonl. They are in a folder the configuration page does not mention, and which the Codex SDK's README and the
One file per session, called a rollout: rollout-<date and time>-<session id>.jsonl
~/.codex/archived_sessions/
Sessions you archived, still on disk
~/.codex/history.jsonl
Your prompt history, which you can cap or switch off
~/.codex/config.toml
Your settings
On Windows the same folders are under %USERPROFILE%\.codex. Each rollout is JSON Lines: one event per line, your messages, Codex's replies, every command it ran and its output, and the snapshots it takes when it compacts the context. That last item is the one that fills disks.
๐ Why the folder gets so big
The forum study found the answer in one sentence: "context compaction and storage compaction are not the same operation."
When a Codex conversation gets long, Codex compacts it: it replaces the history the model sees with a shorter version, which I explained for Claude Code in what compaction keeps and loses. The model's view gets smaller. The file on disk does not. Each compaction writes a fresh snapshot into the rollout, and in that study 77.13 percent of all the bytes were compaction snapshots, most of them repeating the snapshot before. Images made it worse: a screenshot that stays in the context is saved again in every snapshot that carries it. As the author put it, "reducing the context visible to the model can still increase the history persisted to disk."
Three people in those threads found out the hard way:
1๏ธโฃ A single 7 GB session, after which "codex became unmanagably slow".
2๏ธโฃ A row of nearly identical 4.9 GB files, explained by the same person: "Imagine a chat not responding anymore and me just forking the chat to get it to continue". Each fork copies the history it came from.
3๏ธโฃ In another thread, someone measured Codex uploading 58 GB in a day from a conversation that had been open since 14 October, with 1,260 compaction records. Nobody from OpenAI has said why yet, but the advice in the thread was the obvious one: start a new conversation.
๐๏ธ What OpenAI changed in October
According to the study, Codex's October releases compress old session files in the background with zstd and prune snapshots that a later one replaces. Its author measured the effect on the same files: 52.48 GiB down to 10.60 GiB. The release notes for version 0.164.0, on 23 October, include "Resuming sessions now finds compressed histories and restores saved thread settings instead of replacing them with global defaults", which suggests the compression arrived a little before the code that reads it back did.
So if your folder was enormous in September, update Codex and look again. If it is still enormous, it is probably one or two long-running sessions full of screenshots.
๐ How to check yours
On macOS or Linux, du -sh ~/.codex/sessions gives the total and du -sh ~/.codex/sessions/*/*/* | sort -h | tail the biggest days. For a fuller picture, codex doctor writes a diagnostic report; OpenAI's command reference says it covers "installation, configuration, authentication, runtime, Git, terminal, app-server, and thread inventory health", and since 0.164.0 its storage figures include compressed rollouts.
๐ How to read or export a session
1๏ธโฃ Resume it.codex resume opens a picker of past sessions, --last takes the most recent one in the current folder, and --all looks everywhere. codex fork copies one into a new session, which is useful and, as above, not free.
2๏ธโฃ Export it as Markdown. Inside a session, type /export. Per OpenAI, "Codex exports the complete conversation as Markdown", to the clipboard or, with /export session.md, to a file. This is the one to use for anything you want to keep.
3๏ธโฃ Read the file itself. A rollout is plain JSON Lines, and the source code's own example is jq -C . on the file. Newer versions compress older files, so run zstd -d on a compressed one first. The format is internal and changes between releases, so treat it as something to look at, not something to build on.
4๏ธโฃ Bring sessions across./import reads chats from Claude Code or Cursor, and "Codex looks for up to 50 chats from the last 30 days."
๐งน How to clean up
Codex has two commands, and the difference matters. codex archive hides a session from the picker; OpenAI says to use it "when you want to clean up the session picker without deleting the transcript", and the file moves to archived_sessions, so it saves no space. codex delete removes it for good: "Use this only when you want to remove the transcript instead of hiding it from active session lists."
For history.jsonl, the configuration page offers history.max_bytes to cap it and persistence = "none" to stop it. Neither touches the sessions folder. OpenAI documents no retention period for sessions at all, and the study's files ran from January to October. That is the opposite of Claude Code, which deletes its sessions after 30 days unless you change a setting. One agent forgets too soon, the other never forgets, and neither asks you.
The habit that keeps the folder small is the same one that keeps the agent sharp: start a new session for a new job instead of running one conversation for a month, and keep screenshots out of sessions that will run long.
๐ Keep the part worth keeping
A rollout is a transcript of how the work went, with every retry and every snapshot. What you want to keep is usually much smaller: what was decided, what was built, and what is left. /export gets you the transcript. A page you write at the end of the session gets you the part worth reading in six months.
That is what I built Sumibako for, so weigh this paragraph accordingly. Codex files a page into it with one command, npx sumibako, on the free plan, and a new session reads it back by name. It will not read your rollout files, and my history viewer reads Claude Code's sessions, not Codex's, at least for now.
Codex keeps everything, forever, in triplicate. It is the most thorough note-taker I have ever met, and I would not let it near my disk without a cleaning schedule.