Data loss on macOS: active rollout JSONLs are repeatedly deleted; sealed snapshot proves continued loss
Summary
Codex Desktop on macOS is repeatedly losing active/unarchived rollout JSONL files while thread rows and secondary metadata remain. Explicitly archived rollout files have survived.
This is not only a stale-index observation. A SHA-256-sealed snapshot taken on August 2 contained two active rollout files and four archived rollout files. By August 11, both active files preserved in that snapshot had disappeared from the live Codex data directory, while all four archived files still existed. Loss continued after the incident was discovered and documented.
Environment
- macOS 27.0 (build 26A5388g), arm64
- Codex Desktop 26.803.61601 (bundle build 6396), inspected August 11
- Bundled Codex CLI 0.147.0-alpha.6.5
- Local filesystem; the Codex data directory is not a symlink
- 18 GiB free at the August 11 inspection
- SQLite integrity check: OK
Before/after evidence
| Observation | Sealed snapshot — Aug 2 | Live state — Aug 11 |
|---|---:|---:|
| Thread rows in state DB | 1,474 | 1,507 |
| Active rollout JSONLs present | 2 | 5 |
| Archived rollout JSONLs present | 4 | 4 |
| DB rows whose rollout path is absent | 1,468 | 1,498 |
Additional crossing proof:
- 35 thread IDs were added to the DB after the August 2 snapshot.
- Only 5 of those 35 currently have a rollout file; 30 are already missing.
- The two active rollout files captured on August 2 subsequently disappeared from the live sessions tree.
- All four archived rollout files captured on August 2 remain present.
- The current DB also no longer contains the two active August 2 root rows, although their files and metadata were preserved in the sealed evidence packet.
The evidence packet's current manifest verifies successfully with SHA-256. Raw snapshots were kept private because they contain conversation content.
Recurring removal timeline
Directory metadata shows successive days when the last remaining entry under a dated active-session directory was removed:
- Aug 4 at 22:30
- Aug 5 at 10:30 and 11:45
- Aug 7 at 11:45
- Aug 9 at 13:15
- Aug 10 at 12:30
- Aug 11 at 09:00
These timestamps establish continued removal after the August 2 snapshot. They do not, by themselves, identify the deleting process or the exact deletion time of every file.
User-visible and logged behavior
After a rollout disappears:
- The DB/thread catalog can continue to list the task.
- Codex logs report a stale rollout path and/or failure to resolve a rollout path because the file does not exist.
- Opening or resuming the task fails, and the task can disappear from the usable UI.
- I found no audit record identifying what removed the rollout or why.
Checks performed
- No matching user shell deletion command was found.
- No cron job, LaunchAgent, LaunchDaemon, or local automation targeting the active-session tree was found.
- The missing files were not in Trash and no compressed copies were found.
- No Time Machine/APFS snapshot recovery path was available.
- No
ENOSPC, “disk full,” or storage-full message was found in the inspected Codex/app logs. - The state SQLite DB passed an integrity check.
- No broad cleanup code targeting the active-session tree was found in the inspected local configuration/operations files.
I cannot yet prove which process performs the deletion. The observed selectivity—active rollouts repeatedly vanish while the four explicitly archived rollouts survive—is consistent with a lifecycle/cleanup defect and warrants an internal deletion-path audit.
Expected behavior
- Active conversation transcripts remain durable unless the user explicitly deletes them.
- Archiving and retention behavior is documented and does not silently destroy recoverability.
- Before removing a rollout, Codex records an audit event containing the reason, actor/process, path, thread ID, policy/retention rule, and result.
- DB/file mismatches are surfaced prominently and do not silently remove the task from the UI.
- The app reconciles metadata safely and provides an automatic backup/recovery path.
Related reports
- #21196 — state still has threads while rollout JSONLs are missing
- #31074 — stale session index / missing rollout paths
- #35385 — silent rollout persistence errors on resume/fork
- #37419 — severe mass rollout deletion report on Windows
This report adds a macOS case with sealed before/after evidence and repeated loss continuing across multiple days, rather than a single migration/reset event.
Privacy and evidence availability
The full evidence packet contains private conversations and account records and should not be posted publicly. I can provide maintainers with a redacted doctor excerpt, aggregate metadata, timestamps, and SHA-256 manifest through a private channel.
3 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Hi @notforyou23, your report looks related to a local session discovery/inventory gap rather than necessarily a lost rollout. I've released Codex Rescue Alpha5, a local read-only diagnostic tool that performs filesystem-first discovery across active and archived rollouts and cross-references SQLite/index metadata without modifying any state.
If you still have the affected local Codex directory, you can inspect it via:
No raw files or databases are needed. If you choose to share output, please review and sanitize any private repository paths or names first.
Not gonna lie, it's kind sus to create a GitHub account just to fork a repo, make a commit, and say you've released it. Especially after the HuggingFace attack.