Disable Codex SQLite diagnostic logging on Windows

codex-sqlite-log-off.md

Disabling Codex SQLite Diagnostic Logging on Windows

Last updated: July 28, 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.

Scope

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.

Overview of Issue #28224

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 #29432
• Filter noisy targets from persistent logs, PR #29457
• Stop 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 (refer to the related URLs), so environments where SSD write volume matters should measure the current behavior and apply an additional mitigation if necessary.

What This Procedure Disables

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.

Prerequisites

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.

Disable Diagnostic Logging

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.

Re-enable Diagnostic Logging

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)"

Data That Must Not Be Disabled

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.

Self-check

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.

Non-default SQLite Locations

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.

Related URLs

• Codex SQLite feedback logs can write ~640 TB/year and rapidly consume SSD endurance, Issue #28224 <-Closed
• Excessive SQLite WAL writes during streaming due to TRACE logs ignoring RUST_LOG, Issue #17320
• High-frequency TRACE writes to logs_2.sqlite after restart, Issue #31478

Updated on July 28

• 2026-06-26 — Issue #30236: Codex App writes high-volume TRACE logs to logs_2.sqlite despite RUST_LOG=warn
• 2026-06-28 — Issue #30405: Windows Codex still persists high-frequency TRACE logs to logs_2.sqlite WAL
• 2026-07-04 — Issue #31132: Log level not configurable — logs_2.sqlite grows to 1.4GB with hardcoded TRACE
• 2026-07-08 — Issue #31542: logs_2.sqlite TRACE churn — root cause and minimal fix
• 2026-07-09 — PR #31789: Stop persisting RMCP service traces <-Merged
• 2026-07-09 — PR #31790: Reduce MCP tool-list trace volume <-Merged
• 2026-07-09 — PR #31791: Filter routine Hyper logs from SQLite <-Merged
• 2026-07-09 — PR #31792: Summarize streamed response item logs <-Merged
• 2026-07-20 — Issue #34291: Large rmcp::service TRACE rows bypass the noisy-target filter
• 2026-07-24 — Issue #35092: Codex CLI 0.145.0 still persists per-SSE TRACE events to SQLite
• 2026-07-25 — Issue #35308: Persistent SQLite TRACE churn remains in bundled 0.146.0-alpha.3.1

codex-sqlite-log-off_ja.md

Windows版CodexのSQLite診断ログを停止する手順

更新日：2026年7月28日

Warning

これはOpenAIが正式にサポートする設定ではなく、非公式の応急処置です。 フィードバックや障害調査に使われるローカル診断ログを停止します。 サポートへ提出するログを採取するときは、事前にログを再開してください。

対象

このメモは、Windows版Codex Desktopが%USERPROFILE%\.codex\logs_2.sqliteへ書き込む診断ログを停止する手順を扱う。

会話履歴やCodexの状態を保存する別のデータベースは対象にしない。

Issue #28224の概要

OpenAIの公式GitHubリポジトリには、CodexのSQLite診断ログがSSDへ大量に書き込まれる問題としてIssue #28224が報告された。

問題の中心は、次のSQLiteファイルだった。

• %USERPROFILE%\.codex\logs_2.sqlite
• %USERPROFILE%\.codex\logs_2.sqlite-wal
• %USERPROFILE%\.codex\logs_2.sqlite-shm

報告環境では、TRACEレベルのイベントが高頻度で追加され、保持行数が一定でも挿入と削除が繰り返されていた。

この処理はSQLiteのWAL、インデックス、チェックポイントを更新するため、データベースの見かけ上のサイズより多くの書き込みをSSDへ発生させる。

Issueの報告者は、21日間でSSDの総書き込み量が約37TBに達したと報告した。

その後、主なログ発生源を削減する次の修正がマージされた。

• Responses WebSocketイベントを毎回記録しない修正 #29432
• 永続ログから騒がしいターゲットを除外する修正 #29457
• 重複するブリッジログを保存しない修正 #29599

報告者の環境ではログが約85%減少し、Issue #28224は2026年6月23日に閉じられた。

ただし、修正は診断ログを完全に無効化するものではない。

修正後のバージョンでもSQLite診断ログへの継続的な書き込みが報告されている（関連URL参照）ため、SSD書き込み量を重視する環境では実測と追加対策が必要になる。

停止するログの範囲

今回停止するのは、logs_2.sqlite内のlogsテーブルへ追加される診断レコードである。

通常の会話、ソースコード編集、コマンド実行には、この診断レコードを参照しない。

一方、ログを停止すると、次の用途で利用できる情報が減る。

• /feedbackによる問題報告
• クラッシュや通信障害の事後調査
• OpenAIサポートへ提出する診断資料

この方法は公式の設定項目ではなく、SQLiteトリガーを使った応急処置である。

CodexのアップデートやログDBの再作成によって、設定が解除される可能性がある。

事前確認

Python Launcherが利用できることを確認する。

py -3 --version

続いて、Codex Desktop、Codex CLI、VS CodeのCodex拡張をすべて終了する。

タスクマネージャーを開き、Codexまたはcodex.exeが残っていないことも確認する。

実行中のプロセスがデータベースを保持したまま変更すると、ロック競合やWALの不整合を招く可能性がある。

診断ログの停止

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)"

このコマンドは、logsテーブルへのINSERTを無視するblock_log_insertsトリガーを作成する。

アプリケーションへエラーを返さずに挿入だけを破棄するため、ファイルを読み取り専用にする方法より再試行ループを起こしにくい。

実行後にCodexを起動し、通常どおり操作する。

診断ログの再開

障害調査やOpenAIサポートへの問い合わせ前には、診断ログを再開できる。

Codex関連プロセスをすべて終了してから、次のコマンドを実行する。

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)"

操作してはいけないデータ

次のファイルやディレクトリは、診断ログ停止の対象ではない。

• %USERPROFILE%\.codex\state_5.sqlite
• %USERPROFILE%\.codex\goals_1.sqlite
• %USERPROFILE%\.codex\sessions
• %USERPROFILE%\.codex\history.jsonl

.codexディレクトリ全体を読み取り専用にする操作も避ける。

これらにはスレッド、UI状態、Goals、セッション履歴などが保存される。

セルフチェック

最初に、停止用トリガーが存在することを確認する。

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())"

次のように表示されれば、トリガーは登録されている。

[('block_log_inserts',)]

続いて、Codexを起動した状態で次の60秒チェックを実行する。

チェック中にCodexで短い質問を送ると、ログ発生経路を動かした状態で確認できる。

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')"

trigger=TrueかつPASSと表示されれば、トリガーが存在し、観測中に新しいログIDが追加されていない。

既存ログの削除処理によって行数だけが減る可能性はあるため、判定には最大IDを使用している。

CHECK REQUIREDと表示された場合は、Codexを終了して停止コマンドを再実行する。

保存先を変更している場合

このメモのコマンドは、SQLite保存先が既定の%USERPROFILE%\.codexであることを前提にしている。

config.tomlのsqlite_homeまたはCODEX_SQLITE_HOME環境変数で保存先を変更している場合は、各コマンドのp=を実際のlogs_2.sqliteのパスへ置き換える。

関連URL

• Codex SQLite feedback logs can write ~640 TB/year and rapidly consume SSD endurance #28224 <-Closed
• Excessive SQLite WAL writes during streaming due to TRACE logs ignoring RUST_LOG #17320
• High-frequency TRACE writes to logs_2.sqlite after restart #31478

7/28 追記

• 2026-06-26 — Issue #30236: Codex App writes high-volume TRACE logs to logs_2.sqlite despite RUST_LOG=warn
• 2026-06-28 — Issue #30405: Windows Codex still persists high-frequency TRACE logs to logs_2.sqlite WAL
• 2026-07-04 — Issue #31132: Log level not configurable — logs_2.sqlite grows to 1.4GB with hardcoded TRACE
• 2026-07-08 — Issue #31542: logs_2.sqlite TRACE churn — root cause and minimal fix
• 2026-07-09 — PR #31789: Stop persisting RMCP service traces <-Merged
• 2026-07-09 — PR #31790: Reduce MCP tool-list trace volume <-Merged
• 2026-07-09 — PR #31791: Filter routine Hyper logs from SQLite <-Merged
• 2026-07-09 — PR #31792: Summarize streamed response item logs <-Merged
• 2026-07-20 — Issue #34291: Large rmcp::service TRACE rows bypass the noisy-target filter
• 2026-07-24 — Issue #35092: Codex CLI 0.145.0 still persists per-SSE TRACE events to SQLite
• 2026-07-25 — Issue #35308: Persistent SQLite TRACE churn remains in bundled 0.146.0-alpha.3.1

まとめていただいて、ありがとうございます。
セルフチェックの部分が PowerShell だとエラーになったので、こっちの方が良いかもしれません。

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())"

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')"

コメントありがとうございます。

ご指摘頂きました通り、元のコマンドでは私の手元でも cmd: 成功、pwsh: 失敗 になりました。失礼いたしました。
ご提案頂きました修正で cmd/pwsh ともに成功することを確認いたしましたので、記事本文に反映いたしました。
ありがとうございました。