Desktop macOS: shared history DB truncated after power loss during active voice session; all tasks fail to reopen

What version of the Codex App are you using (From “About Codex” dialog)?

26.903.71938, build 8576 (verified from the installed app bundle).

What subscription do you have?

Not included in this report.

What platform is your computer?

macOS 26.2, Apple Silicon. uname -mprs: Darwin 25.2.0 arm64 arm.

What issue are you seeing?

During an active voice conversation, an unexpected power outage occurred. After restarting the Mac and app, the shared thread-history SQLite database was malformed and existing tasks could not reopen. This is a reliability bug report for engineering; manual recovery has already restored use of the application.

What steps can reproduce the bug?

Observed incident sequence, not a deliberately repeated reproduction:

1. An active voice conversation was running in the desktop app.
2. A storm caused an abrupt power outage.
3. After the Mac and app restarted, resuming existing tasks failed with SQLite error 11.
4. The user also observed a newly created conversation becoming inaccessible after another app restart.

No destructive reproduction was attempted. The outage is a plausible trigger, not a proven root cause; this report does not establish that every outage or every voice session causes corruption.

What is the expected behavior?

An interrupted conversation should not leave all tasks inaccessible indefinitely. Startup should detect damaged shared history storage and provide a safe, backup-preserving recovery path where possible, with explicit warnings for any data that cannot be recovered. Please investigate the observed truncation/durability issue and recovery behavior, including voice items.

Additional information

This is an engineering reliability bug report, not a request for recovery assistance. Recovery has already restored operation. Please route the observed failure and evidence to the Codex desktop engineering team for investigation and prevention.

The user experienced an abrupt power outage during an active voice conversation on September 10, 2026. After restarting the Mac and the application, existing tasks could not resume. The user also reported that a newly created conversation became inaccessible after closing and reopening the application. Manual recovery restored operation, and the user has now confirmed that a new conversation and its reply survive an application restart.

Environment

• macOS 26.2.
• Installed application: ChatGPT.app, bundle identifier com.openai.codex.
• Application version 26.903.71938, build 8576.
• Time zone: America/New_York. Exact outage time was not established.
• Affected database: ~/.codex/thread_history_1.sqlite.

Observed error
failed to list thread history: thread-store internal error: failed to open thread history database: failed to open thread history DB at [user directory]/.codex/thread_history_1.sqlite: error returned from database: (code: 11) database disk image is malformed

Verified findings

• With the application closed, a backup of the database was made. The backup listing contained only the main database. No WAL, SHM, or rollback-journal companion files were present during subsequent checks before installation.
• The original and initial backup had identical SHA-256 hashes and remained unchanged throughout recovery preparation.
• The damaged file was 298,946,560 bytes, comprising 72,985 complete 4,096-byte pages. Its header declared 73,310 pages: a discrepancy of 325 pages / 1,331,200 bytes. The header change counter and version-valid-for counter both equaled 5,946. Internal B-tree references pointed to pages beyond the physical end of the file.
• A read-only integrity attempt reproduced SQLite error 11.
• SQLite .recover produced a separate database which passed the full integrity check. Independent parsing of the readable source table pages and comparison of every complete readable record found 59,007 matching records, with no changes or omissions among those readable records.
• Surviving indexes identified at least 58 additional records absent from that initial reconstruction: 40 thread_items and 18 thread_realtime_items. These identified omissions belonged to one task. Because portions of the indexes were also inaccessible, this is a lower bound, not proof of a complete missing-record inventory.
• All 980 available session JSONL files were scanned: 585,897 JSON records, without JSON parse errors or detected file changes during the scan. All 963 recovered history-projection-state thread identifiers had corresponding session files.

Recovery performed

• 55 missing records were found as structured items in the session files: 39 thread_items and 16 thread_realtime_items.
• Their conversion and metadata were checked against 1,074 intact items from the affected session: 94 user messages, 142 assistant messages, 349 tool calls, 129 reasoning items, and 360 voice items. Tool metadata was cross-checked against surviving records for the same tools.
• The 55 items were inserted into a separate recovery copy. All 59,007 baseline records were preserved unchanged. The augmented copy passed SQLite integrity and foreign-key checks.
• Three identified records remain without complete reconstruction: a tool call at the end of the session for which no result was recorded, and two voice items whose contents were not found. No replacement contents or tool results were fabricated. Other omissions cannot be excluded.
• Before installing the recovery, an offline script preserved an additional copy of the damaged database and all current session files, verified the copies, checked that the application was closed and the original unchanged, and replaced only the history database. A rollback procedure preserves both the original and the post-test files.

Outcome

• The user confirmed that the application works after installation and reopening.
• Reading the affected task through the application's history API now succeeds; the same operation previously failed with SQLite error 11.
• The user subsequently confirmed the requested test of creating a new conversation, receiving a reply, fully closing the application, reopening it, and finding the conversation and reply intact.
• This establishes restored operation, not complete recovery of every pre-incident record.

Requested investigation
Please investigate the database durability and restart/recovery behavior around abrupt power loss, including the file-length/header discrepancy and the failure of a shared history database to allow existing tasks to reopen. Please also consider a supported, backup-preserving recovery or reprojection path from session logs, with special attention to voice records and clear reporting of unrecoverable data.

The power outage is a plausible trigger, not a proven root cause. The available evidence does not establish whether the underlying cause lies in application writes/checkpointing, the filesystem, storage, or another layer. No destructive reproduction was attempted.

This report was prepared at the user's request by their assistant for submission to OpenAI Support. It contains no conversation bodies, credentials, account identifiers, private task titles, or raw database/session attachments. The original damaged database and recovery evidence remain preserved locally; any further sharing would need to be scoped separately.

Related but apparently different: https://github.com/openai/codex/issues/27363 concerns a corrupted state_5.sqlite index. This incident affects thread_history_1.sqlite, with an observed file-length/header discrepancy after power loss during an active voice conversation.

Start by examining the affected ~/.codex/thread_history_1.sqlite database and the reported SQLite error 11, including the file-length/header discrepancy after the power loss. Review the existing history and session-file recovery behavior; done should include a reproducible durability or recovery fix that preserves valid data and clearly reports anything unrecoverable.