Codexのfailed to resolve rollout path対処法｜セッションを消す前に確認

Codexでfailed to resolve rollout pathと表示されても、すぐに会話履歴が消えたとは断定できません。最初に確認するのは、エラーに表示されたrollout JSONL（1行ごとにJSONを記録するセッションファイル）が実際に存在するか、エラーが過去の1スレッドだけで起きるか、新規会話でも起きるかです。

安全な順序は次のとおりです。

エラー全文とthread IDを記録する
Codexが使っているCODEX_HOMEを確認する
ファイルを開かず、エラーに表示されたパスの存在だけ確認する
sessionsとarchived_sessionsをthread IDで限定検索する
変更が必要になる前にセッション関連ファイルをバックアップする

state_5.sqliteの削除・直接編集、空のJSONL作成、セッションフォルダの一括移動は行わないでください。公式GitHubには手作業で直した報告もありますが、一般向けの正式な復旧手順ではなく、別のスレッドまで壊す可能性があります。

症状から確認先を絞る
rollout pathエラーは何を示しているのか
1. エラー全文とthread IDを記録する
2. 実際のCODEX_HOMEを確認する
3. エラーに表示されたファイルの存在だけ確認する
4. thread IDで保存先を限定検索する
5. 新規会話も失敗するなら空き容量と環境差を確認する
6. 変更前にセッション関連データをバックアップする
結果別の安全な対応
やってはいけない対処
解決しない場合に残す情報
まとめ
出典

症状から確認先を絞る

同じエラー文でも、発生範囲によって確認すべき場所が異なります。

症状	考えられる状態	最初の確認	安全な暫定対応
過去の1スレッドだけ開けない	保存済みパスと実ファイルの不一致、またはファイル欠落	エラーのパスとthread IDを検索	別スレッドで作業を継続し、対象データを保存
複数の過去スレッドが開けない	セッション索引と保存ファイルの広い不一致	`sessions`と`archived_sessions`の両方を確認	Codexを終了してバックアップ、削除操作はしない
新規会話も毎回失敗する	rollout作成前の初期化失敗、保存先、空き容量など	`CODEX_HOME`、空き容量、DesktopとCLIの差	更新・再起動後、CLIが動くなら新規作業だけ一時継続
会話は使えるがアーカイブだけ失敗する	アーカイブ処理時のパス解決不整合	対象JSONLが実在するか	無理に移動せず、未アーカイブのまま保全
`Permission denied`や`Access denied`が中心	rollout pathではなく書き込み権限の問題	親フォルダの書き込み可否	Codexのファイル編集権限の切り分けを確認

この表の「考えられる状態」は診断候補です。OpenAI公式GitHubのIssueには、実ファイルが欠落していた報告と、ファイルは存在するのにWindowsのパス表現が一致せず失敗した報告の両方があります。エラー名だけで片方に決めないことが重要です。

rollout pathエラーは何を示しているのか

OpenAIのrolloutテストコードでは、セッションファイルを次のような構造で扱っています。

CODEX_HOME/
├── sessions/
│   └── YYYY/MM/DD/
│       └── rollout-日時-thread-id.jsonl
└── archived_sessions/
    └── rollout-....jsonl

rollout JSONLには会話やツール実行に関係する記録が含まれます。一方、Codexはスレッド一覧や保存先を管理する情報も持っています。failed to resolve rollout pathは、スレッドに対応するファイルの場所をCodexが解決できなかったことを示しますが、その理由まではエラー名だけで分かりません。

Issue #21196では、スレッドのメタデータが残る一方、多数のrollout JSONLが見つからない状態が報告されています。Issue #39378では逆に、対象ファイルが通常のWindowsパスに存在していても、データベースに保存されたパスの表現が異なるためアーカイブできない状態が報告されています。

どちらもopenai/codexリポジトリ上の不具合報告です。すべての利用者に共通する確定原因や、OpenAIが推奨する一般的な修復手順として扱うべきではありません。

1. エラー全文とthread IDを記録する

操作を変える前に、次の情報をメモします。

何をしたときに出たか：再開、メッセージ送信、アーカイブなど
過去の特定スレッドだけか、新規会話でも出るか
Codex Desktop、CLI、IDE extensionのどれか
OSとCodexのバージョン
エラーに表示されたパス
rolloutファイル名の末尾に含まれるthread ID

たとえば次のファイル名では、日時に続くUUID形式の部分がthread IDです。

rollout-2026-08-25T10-20-30-019f....jsonl

スクリーンショットやログを公開するときは、Windowsのユーザー名、プロジェクト名、会話本文、アクセストークンを隠してください。rollout JSONLそのものをIssueへ添付するのは避け、必要な場合もOpenAIの案内する安全な窓口と共有範囲を確認します。

2. 実際のCODEX_HOMEを確認する

CODEX_HOMEはCodexの設定やセッションを置くホームディレクトリです。未設定なら通常はユーザーの.codexが使われますが、保存先を変更した環境では別ドライブにあります。

Windows PowerShellでは、次の確認だけを実行します。このコマンドはファイルを変更しません。

$codexHome = if ($env:CODEX_HOME) {
    $env:CODEX_HOME
} else {
    Join-Path $env:USERPROFILE ".codex"
}

$codexHome
Test-Path -LiteralPath $codexHome

WSL、Linux、macOSでは次のように確認できます。

codex_home="${CODEX_HOME:-$HOME/.codex}"
printf '%s\n' "$codex_home"
test -d "$codex_home" && echo "CODEX_HOME exists"

PowerShellとWSLは別の環境です。Windows Desktopのエラーを調べるのに、WSL側の\(HOME/.codexだけを見ても判断できません。エラーに表示されたWindowsパスと、Windows側で取得した\)codexHomeを照合します。

以前CODEX_HOMEをCドライブからDドライブへ移した場合は、古い場所と新しい場所が混在していないか確認してください。移行方法とWindows・WSLの違いはCodexの保存場所をCドライブからDドライブへ変更する方法で整理しています。

3. エラーに表示されたファイルの存在だけ確認する

エラーに完全なパスが表示されている場合、PowerShellのTest-Pathで確認します。

$rolloutPath = 'C:\Users\your-name\.codex\sessions\2026\08\25\rollout-....jsonl'
Test-Path -LiteralPath $rolloutPath

Trueなら、ファイルは存在します。中身を編集せず、ファイルサイズと更新日時だけ確認します。

Get-Item -LiteralPath $rolloutPath |
    Select-Object FullName, Length, LastWriteTime, IsReadOnly

Falseなら、すぐに「削除された」と結論づけません。アーカイブ済みの場所、CODEX_HOME移行前の場所、日付フォルダの不一致などを次の手順で調べます。

JSONLの内容には会話、ローカルパス、コマンドなどが含まれ得ます。存在確認の段階でエディタへ読み込んだり、全文をターミナルへ出力したりする必要はありません。

4. thread IDで保存先を限定検索する

エラーからthread IDをコピーし、CODEX_HOMEの中だけを検索します。PC全体を検索する必要はありません。

Windows PowerShellの例です。

$threadId = '019f0000-0000-0000-0000-000000000000'

Get-ChildItem -LiteralPath $codexHome `
    -Filter "*$threadId*.jsonl" `
    -File -Recurse -ErrorAction SilentlyContinue |
    Select-Object FullName, Length, LastWriteTime

WSL、Linux、macOSではfindの対象を2フォルダに限定します。存在しないフォルダの警告は非表示にします。

thread_id='019f0000-0000-0000-0000-000000000000'

find "$codex_home/sessions" "$codex_home/archived_sessions" \
  -type f -name "*${thread_id}*.jsonl" -print 2>/dev/null

結果は次の3通りです。

検索結果	分かること	まだ分からないこと
エラーと同じ場所にある	単純なファイル欠落ではない	パス表現、索引、アーカイブ処理などのどこで失敗したか
別の場所に1件ある	保存先の参照がずれている可能性	手動で移動すれば安全に直るか
どこにもない	現在の`CODEX_HOME`内に対応JSONLを確認できない	別のバックアップにあるか、なぜ欠落したか、復元可能か

「別の場所に見つかった」場合も、手動で移動しないでください。Codexの索引が指す場所とファイルの配置をさらにずらす可能性があります。

5. 新規会話も失敗するなら空き容量と環境差を確認する

過去スレッドだけでなく、新規会話の最初のメッセージも失敗する場合は、既存ファイルの参照だけでなく、新しいrolloutを作る段階で止まっている可能性があります。

Windowsでは、CODEX_HOMEがあるドライブの空き容量を確認します。

$drive = (Get-Item -LiteralPath $codexHome).PSDrive
$drive | Select-Object Name, Used, Free, Root

そのうえで、次を比較します。

比較	結果	判断
DesktopとCLIの両方	両方失敗	共通の保存先、空き容量、アカウント、環境設定を確認
DesktopとCLIの両方	Desktopだけ失敗	Desktop固有の初期化・app-server側の可能性を切り分け
過去スレッドと新規会話	過去だけ失敗	対象スレッドの参照不整合に範囲を絞る
通常操作とアーカイブ	アーカイブだけ失敗	セッション内容よりアーカイブ時のパス処理を疑う

Issue #30924では、Windows Desktopの新規会話が失敗する一方、CLIは動作した事例が報告されています。この場合、CLIで新しい作業を一時的に継続できても、壊れた過去スレッドが復元されたことにはなりません。

Issue #31074では、索引と実ファイルの不一致にディスク満杯やプロセス中断が関係した可能性が報告されています。ただし投稿者による分析であり、すべてのrollout pathエラーの原因ではありません。

6. 変更前にセッション関連データをバックアップする

確認の結果にかかわらず、アプリの再設定や修復を試す前にバックアップします。実行中のCodexがファイルを書き換えないよう、進行中の作業がないことを確認してCodex DesktopとCLIを終了してください。

Windows PowerShellでは、state_5.sqlite、session_index.jsonl、sessions、archived_sessionsが存在する場合だけ、デスクトップの新規フォルダへコピーできます。

$backup = Join-Path `
    ([Environment]::GetFolderPath('Desktop')) `
    "codex-session-backup-$(Get-Date -Format yyyyMMdd-HHmmss)"

New-Item -ItemType Directory -Path $backup | Out-Null

$items = @(
    'state_5.sqlite',
    'session_index.jsonl',
    'sessions',
    'archived_sessions'
)

foreach ($item in $items) {
    $source = Join-Path $codexHome $item
    if (Test-Path -LiteralPath $source) {
        Copy-Item -LiteralPath $source -Destination $backup -Recurse
    }
}

$backup

このバックアップには会話内容、プロジェクト名、ローカルパスなどが含まれる可能性があります。Gitリポジトリへ追加したり、クラウドへ無条件で共有したりしないでください。復旧作業が終わるまでローカルの安全な場所に保管します。

結果別の安全な対応

対象ファイルが存在する場合

rollout JSONLが実在するなら、空ファイルの作成や履歴消失では説明できません。次の順で対応します。

Codexを最新版へ更新する
進行中の作業がないことを確認して完全終了し、再起動する
過去スレッド、新規会話、アーカイブのどこで失敗するか再確認する
ファイルが存在する証拠として、パス、サイズ、更新日時だけを記録する
openai/codexの既存Issueを確認し、重複がなければ再現情報を報告する

Windowsの\\?\C:\...形式を通常パスへ書き換えて解決したIssue報告がありますが、state_5.sqliteの直接編集が必要です。バックアップがあっても操作を誤れば別スレッドに影響するため、本記事では標準手順として案内しません。

対象ファイルが見つからない場合

現在のCODEX_HOMEとアーカイブ先のどちらにも見つからない場合、メタデータだけから会話本文を復元できるとは確認できません。

以前のCODEX_HOMEや自分で作成したバックアップを確認する
現在の作業は新しいスレッドで継続する
欠落が1件か複数かを記録する
既存データを削除せず、更新で修復機能が提供される可能性に備えて保全する

空のJSONLを期待パスへ作っても、元の会話内容は戻りません。エラーだけを消す目的でダミーファイルを作ると、正常なセッションとして誤認される可能性があります。

新規会話だけでも作業を再開したい場合

Desktopだけが失敗しCLIが正常なら、原因調査中の新規作業に限ってCLIを使う選択肢があります。反対に、CLIも同じCODEX_HOMEを使って失敗するなら、何度も新規スレッドを作らず、空き容量と保存先を確認してバックアップを優先します。

選択肢	利点	注意点
更新・再起動して再確認	データを直接変更しない	欠落したファイルを復元する方法ではない
CLIで新規作業を継続	Desktop固有かを切り分けられる	過去スレッドの復旧にはならない
新しいスレッドで継続	作業を止めずに済む	元スレッドの文脈は手動で引き継ぐ必要がある
バックアップしてIssue報告	修復前の状態を保存できる	JSONLや認証情報を公開しない配慮が必要
SQLiteを手作業で編集	一部のIssueでは成功例がある	非公式で高リスク。本記事では推奨しない

やってはいけない対処

state_5.sqliteやsession_index.jsonlをすぐ削除する

一覧から壊れた表示が消えても、残っているスレッド情報まで失う可能性があります。原因調査とバックアップが終わる前に削除しません。

空のrollout JSONLを作る

ファイルの存在だけを満たしても、元のセッション記録は復元されません。形式不正や別の読み込みエラーを増やす可能性があります。

見つけたJSONLを手動で移動する

索引が古い場所を指したままなら、実ファイルとの不一致が続きます。sessionsとarchived_sessionsの間を手作業で動かさず、Codexの通常操作か正式な修復手順を待ちます。

再インストールだけで履歴も直ると考える

Issue #30924には、Windows Desktopを再インストールしても同じ症状が続いた報告があります。ローカル状態がインストール先とは別に残る場合、再インストールだけでは参照不整合を解消できません。実施する場合も先にバックアップします。

JSONLやデータベースを公開する

会話本文、ローカルパス、プロジェクト情報が入っている可能性があります。Issueには、必要最小限のエラー、伏せ字にしたパス、thread ID、ファイルの有無、サイズ、発生範囲を記載します。

解決しない場合に残す情報

openai/codexへ報告するときは、次の情報があると「ファイル欠落」と「パス解決不整合」を区別しやすくなります。

Codexの製品：Desktop、CLI、IDE extension
Codexバージョン
OSとバージョン
発生操作：resume、send、archive
過去1件、過去複数、新規すべてのどれか
エラー全文（ユーザー名などは伏せる）
CODEX_HOMEが既定か変更済みか
Test-Pathの結果
thread ID限定検索の件数
rolloutファイルのサイズと更新日時（存在する場合）
DesktopとCLIで再現するか
問題発生前にディスク満杯、強制終了、保存先移行があったか

原因と断定せず、「確認した事実」と「直前に起きたこと」を分けて書きます。認証情報、会話本文、リポジトリ内の秘密情報は添付しません。

まとめ

failed to resolve rollout pathが出たら、削除やデータベース編集より先に、エラーの発生範囲、実際のCODEX_HOME、rollout JSONLの存在を確認します。

ファイルが存在するなら、単純な履歴消失とは限らない
ファイルが別の場所にあっても手動で移動しない
ファイルが見つからなくても空JSONLを作らない
新規会話も失敗するなら、空き容量とDesktop・CLIの差を確認する
変更前にセッション関連データをバックアップする

公式GitHubには複数の発生パターンが報告されていますが、共通原因と正式な復旧方法は確認できません。確認結果を保全し、低リスクな作業継続と不具合報告を優先するのが安全です。

出典

GitHub Issueは利用者による不具合報告であり、OpenAIが確定した原因や正式な復旧手順ではありません。本記事は2026年8月25日に確認した情報を基にしています。

Codexのfailed to resolve rollout pathを安全に切り分ける方法｜セッションを消す前に確認