Codex Appのdatabase is locked対処法：WSLモードで起動しない原因と回避策¶

対象 / ポイント

対象: Windows版Codex AppをWSL2連携で使い、起動時にdatabase is lockedで止まる開発者。

ポイント:

\\wsl.localhost\... がエラーに出る場合、DB破損よりWindows/WSL境界を先に疑う
Codex App 26.609.4994.0 の起動不能は公式リポジトリのIssueで報告済み
WSLモードを切ってPowerShellへ戻すと、Codex App自体は起動できる

Codex Appが起動直後にdatabase is lockedを出すと、最初の仮説はSQLite DBの破損や残留プロセスになりやすい。しかし、Windows版Codex AppをWSLモードで使っている場合、エラーの見た目と原因が一致しないことがある。この記事の問いは、Codex Appのdatabase is lockedをDB修復問題として扱うべきか、アプリ側のWSL連携障害として扱うべきかだ。

2026年6月13日時点で、OpenAIのopenai/codexリポジトリにはWindows App 26.609.4994.0 が更新後に開かないIssueがOpenで存在する¹。同じ時期にWSLモード、Windows側app-server、SQLite状態DBに関する関連Issueも複数報告されている²³⁴。まずローカルDBを壊さない形で切り分ける。

起動すらできない場合の最短復旧手順¶

Codex cannot access its local databaseでアプリがまったく開かない場合でも、WSLモードを切れば起動できる。これはWindowsネイティブ経路に戻す回避策であり、実機で起動成功を確認済みだ（2026年6月14日）。 WSL経路の不具合そのものを直す手順ではない点は分けて考える。

前提として、作業フォルダがWindows側にあるなら、この退避策の実害は小さい。通常のCodex App homeはC:\Users\<User>\AppData\Local\OpenAI\CodexAppHomeにある。ユーザー名や実パスを公開ログに貼る必要はない。

まずDBを消さずに、次の3手順だけを行う。

Codex Appを完全終了する。タスクトレイやタスクマネージャーに残ったCodex関連プロセスも終了する
CodexAppHome\config.tomlをバックアップし、[desktop]を次の設定にする
Codex Appを起動する

[desktop]
runCodexInWindowsSubsystemForLinux = false
integratedTerminalShell = "powershell"

これで開くなら、DB再生成は不要だ。それでも開かない場合だけ、後述のstate_5.sqlite*とlogs_2.sqlite*の退避に進む。さらに失敗する場合は、ローカル設定ではなくビルド固有の不良としてロールバックや修正版待ちを検討する。

症状：database is lockedとWSLパスが同時に出る¶

この障害で見るべき最初の文字列は、database is lockedそのものではなく、直前に表示されるDBパスだ。

典型的なエラーは次の形になる。

Codex cannot access its local database.
failed to initialize sqlite state runtime under
\\wsl.localhost\<Distro>\home\<user>\.codex-app:
error returned from database: (code: 5) database is locked

\\wsl.localhost\... は、Windows側のプロセスがWSLファイルシステムをUNCパスとして見ていることを示す。この時点で、WSL内のext4に直接アクセスしているLinuxプロセスだけを見ても全体像は掴めない。 SQLiteのロックはローカルファイルシステムでは扱いやすいが、Windows/WSL境界やネットワーク共有風の経路が入ると失敗の見え方が変わる。

つまり、database is lockedは「誰かがDBを握っている」と同義ではない。保持者が見つからないのにlockedになるなら、次はアクセス経路を見る。

DB破損かどうかを先に切り分ける¶

DBを削除する前に、WSL側で状態を読むだけの確認を行う。

ls -la ~/.codex-app
fuser ~/.codex-app/state_5.sqlite
df -T ~/.codex-app
sqlite3 ~/.codex-app/state_5.sqlite "PRAGMA integrity_check;"
ps -ef | rg "codex|app-server"

判断の目安は単純だ。

確認項目	DB破損の可能性が低い状態
`fuser`	保持プロセスが出ない
`PRAGMA integrity_check`	`ok` が返る
`df -T`	WSL内ではext4に置かれている
`ps`	WSL側にCodex/app-serverが残っていない

この状態なら、SQLite DBそのものを疑い続ける優先度は下がる。 DB退避、再作成、WAL化を繰り返しても、Windows側のCodexプロセスが\\wsl.localhost越しに同じDBを開くなら再発し得る。

次に確認するのは、Codex Appが本当にWSL内のLinuxバイナリを起動しているかだ。

原因候補：WSLモードなのにWindows側codex.exeが動く¶

WSLモードの期待値は、作業ディレクトリもシェルも実行バイナリもWSL側に寄ることだ。ところが関連Issue #21147 では、WSLモード設定にもかかわらずWindows版codex.exe app-serverがWSLラッパー経由で起動し、実行環境がPowerShell側に残る事例が報告されている²。

同じ障害パターンでは、WSL側のプロセスがstate_5.sqliteを保持していない一方、Windows版codex.exeが一瞬だけ現れる構図になる。この場合、ロック保持者をWSL内で探しても見つからない。問題は「DBを誰が握ったか」ではなく、「どのOS側のプロセスが、どのパス表記でDBを開いたか」になる。

ログでは次のような観点を見る。

バイナリ配置: Linux版codexを期待する場所に展開できているか
spawn先: codexではなくcodex.exeが起動していないか
DBパス: \\wsl.localhost\... や /mnt/c/... が混在していないか
設定ホーム: Windows側とWSL側のCODEX_HOMEや~/.codexが分裂していないか

22759 では、Windows Desktop + WSL構成でWindows側設定とWSL側設定の読み分けが分裂する挙動も報告されている³。¶

この種の障害では、設定画面で見える値と実際にapp-serverが読む値が一致しない可能性がある。

26.609.4994.0なら既知Issueを確認する¶

Codex App 26.609.4994.0 を使っているなら、ローカル作業より先に公開Issueを確認する価値が高い。

27979 は、Windows Codex App `26.609.4994.0` に更新後、アプリが開かなくなる問題として2026年6月12日に作成され、2026年6月13日の確認時点でOpenだった¹。¶

Issue本文では、AppXパッケージ自体の状態はOkだがアプリが起動しない、既存の作業履歴にアクセスできない、更新直後から発生した、という症状が整理されている。

これは「全ユーザーで必ず同じ原因」と断定する材料ではない。ただし、同じビルド番号、Windows、WSLモード、SQLite初期化失敗が重なるなら、個別DB修復ではなくアプリビルド側の回帰として扱うほうが判断を誤りにくい。

公開ログやIssueに貼る情報は必ず削る。 C:\Users\<user>、/home/<user>、ワークスペース名、認証ファイル、会話履歴、.codex全体の圧縮ファイルは載せない。

23848 でも、`.codex`全体には認証情報や会話履歴が含まれ得るため、丸ごと共有しない注意が書かれている⁴。¶

すぐ使う回避策：WSLモードを切る¶

最短でCodex Appを復旧したい場合、WSLモードを一時的に切ってWindowsネイティブ構成に寄せる。

23848 は別種のSQLite migration checksum問題を扱うIssueだが、Windows側GUIを復旧する運用手順として、WSLモードを無効化し、PowerShellを使い、SQLite状態DBを再生成させる流れを示している⁴。¶

database is lockedの根本原因が同一とは限らないが、9p/UNC経路を避ける退避策としては実用的だ。

基本手順は冒頭の最短復旧手順と同じだ。まずrunCodexInWindowsSubsystemForLinux = falseとintegratedTerminalShell = "powershell"だけを設定する。これで起動できるなら、SQLite状態DBは触らない。

それでも起動しない場合のみ、次の追加手順に進む。

workspace rootをWindows側パスに変更する
state_5.sqlite* と logs_2.sqlite* だけを退避する
Codex Appを再起動し、状態DBを再生成させる

削除ではなく退避にする。また、.codexや.codex-app全体を共有・削除する前に、中の認証情報や履歴を確認する。

WSLモードが必要なら修正版待ちかロールバック¶

WSL内のLinuxツールチェーンを前提にしているプロジェクトでは、Windowsネイティブ構成は一時退避にしかならない。その場合は、修正版の配布を待つか、組織ポリシー上可能なら直前の正常ビルドへ戻す選択になる。

このとき避けたいのは、DBに対する処置だけを繰り返すことだ。

DBのWAL化: 同時書き込み競合には効くが、Windows/WSL境界の起動失敗には効かない可能性が高い
state_5.sqliteの再作成: DB破損でない場合、同じアクセス経路で再び失敗する
Linux版codexの手動配置: アプリがパッケージ内のコピー元を前提に判定している場合、配置先だけ補っても使われない

「保持者がいないlocked」は、SQLiteだけの問題として扱うと時間を失う。 WSLモードで起動しないCodex Appは、バージョン、起動バイナリ、DBパス、設定ホームの4点をまとめて見る。

まとめ：DB修復より先にパスとビルド番号を見る¶

Codex Appのdatabase is lockedは、SQLite DB破損のメッセージに見える。しかし、エラーに\\wsl.localhost\...が含まれ、WSL側に保持プロセスがなく、26.609.4994.0のような既知の起動不能ビルドに当たっているなら、優先すべきはDB修復ではない。

見る順番は、DB、プロセス、パス、ビルド番号だ。この順で確認すれば、消してはいけない認証情報や履歴を守りながら、Windowsネイティブ退避、ロールバック、修正版待ちのどれを選ぶべきか判断しやすい。

最後に残る実務上の教訓は、ログをそのまま貼らないことだ。障害共有に必要なのは、個人名やローカルパスではなく、ビルド番号、OS、WSLモードの有無、DBパスの種類、起動したバイナリ名である。