Last updated: July 25, 2026
Warning
This is an unofficial workaround, not an OpenAI-supported configuration. It disables local diagnostic records used for feedback and troubleshooting. Re-enable logging before collecting data for a support request.
This note explains how to stop the Windows Codex Desktop app from writing diagnostic records to %USERPROFILE%\.codex\logs_2.sqlite
.
It does not disable the separate databases that store conversation and application state.
Issue #28224 in OpenAI's official GitHub repository reported that Codex SQLite diagnostic logging was generating excessive SSD writes.
The affected files were:
%USERPROFILE%\.codex\logs_2.sqlite
%USERPROFILE%\.codex\logs_2.sqlite-wal
%USERPROFILE%\.codex\logs_2.sqlite-shm
In the reported environment, high-frequency TRACE events were continuously inserted and deleted even when the retained row count remained stable.
These operations update the SQLite WAL, indexes, and checkpoints, so the amount written to the SSD can be much larger than the visible database size.
The reporter observed approximately 37 TB of total SSD writes over 21 days.
The following changes were subsequently merged to reduce the main sources of diagnostic-log traffic:
Stop logging every Responses WebSocket event, PR #29432Filter noisy targets from persistent logs, PR #29457Stop persisting bridged log events, PR #29599
The reporter observed an approximately 85% reduction in log traffic and closed Issue #28224 on June 23, 2026.
These changes did not disable diagnostic logging completely.
Continuing SQLite diagnostic writes have been reported in later versions, so environments where SSD write volume matters should measure the current behavior and apply an additional mitigation if necessary.
This procedure prevents new diagnostic records from being inserted into the logs
table in logs_2.sqlite
.
Normal conversations, source-code editing, and command execution do not depend on these diagnostic records.
Disabling them does reduce the information available for:
-
Submitting a report through
/feedback -
Investigating crashes or connection failures
-
Providing diagnostic evidence to OpenAI Support
This is a workaround based on a SQLite trigger, not an official Codex configuration option.
A Codex update or recreation of the log database may remove the trigger.
Confirm that the Python Launcher is available:
py -3 --version
Quit Codex Desktop, all Codex CLI sessions, and any VS Code instance running the Codex extension.
Open Task Manager and verify that no Codex
or codex.exe
processes remain.
Changing the database while another process holds it open may cause lock contention or WAL inconsistency.
Run the following command in PowerShell:
py -3 -c "import sqlite3,os; p=os.path.expanduser(r'~\.codex\logs_2.sqlite'); c=sqlite3.connect(p); c.execute('CREATE TRIGGER IF NOT EXISTS block_log_inserts BEFORE INSERT ON logs BEGIN SELECT RAISE(IGNORE); END;'); c.commit(); print('Diagnostic logging disabled:',p)"
This creates a trigger named block_log_inserts
that silently ignores every INSERT
into the logs
table.
Because the trigger discards inserts without returning an application error, it is less likely to cause a retry loop than making the database read-only.
Start Codex again and use it normally.
Diagnostic logging can be restored before troubleshooting a problem or contacting OpenAI Support.
Quit all Codex-related processes, then run:
py -3 -c "import sqlite3,os; p=os.path.expanduser(r'~\.codex\logs_2.sqlite'); c=sqlite3.connect(p); c.execute('DROP TRIGGER IF EXISTS block_log_inserts'); c.commit(); print('Diagnostic logging enabled:',p)"
Do not apply this workaround to the following files or directories:
%USERPROFILE%\.codex\state_5.sqlite
%USERPROFILE%\.codex\goals_1.sqlite
%USERPROFILE%\.codex\sessions
%USERPROFILE%\.codex\history.jsonl
Do not make the entire .codex
directory read-only.
These locations contain thread metadata, UI state, goals, session history, and other runtime state.
First, verify that the blocking trigger exists:
py -3 -c "import sqlite3,os; p=os.path.expanduser(r'~\.codex\logs_2.sqlite'); c=sqlite3.connect(p); print(c.execute(\"SELECT name FROM sqlite_master WHERE type='trigger' AND name='block_log_inserts'\").fetchall())"
The following output confirms that the trigger is registered:
[('block_log_inserts',)]
Next, start Codex and run this 60-second check:
py -3 -c "import sqlite3,os,time; p=os.path.expanduser(r'~\.codex\logs_2.sqlite'); q=lambda: sqlite3.connect(p).execute('SELECT COUNT(*), COALESCE(MAX(id),0) FROM logs').fetchone(); t=sqlite3.connect(p).execute(\"SELECT 1 FROM sqlite_master WHERE type='trigger' AND name='block_log_inserts'\").fetchone(); a=q(); print('trigger=',bool(t),'before=',a); time.sleep(60); b=q(); print('after=',b); print('PASS' if t and b[1]==a[1] else 'CHECK REQUIRED')"
Send a short prompt to Codex during the 60-second interval to exercise the normal logging path.
If the command reports both trigger=True
and PASS
, the trigger exists and no new log IDs were inserted during the observation period.
The existing row count may decrease because of cleanup, so the check uses the maximum row ID for its pass or fail decision.
If it reports CHECK REQUIRED
, quit Codex and run the disable command again.
The commands in this note assume that SQLite state is stored in the default %USERPROFILE%\.codex
directory.
If the location has been changed through sqlite_home
in config.toml
or the CODEX_SQLITE_HOME
environment variable, replace the value assigned to p
in each command with the actual path to logs_2.sqlite
.