Codexでプロジェクトを追加・削除できないときの対処法【Windows・WSL】

Windows版Codex Desktopで「プロジェクトを作成できませんでした」と表示され、新しいProjectを追加できなくなりました。既存Projectの削除も失敗し、Repair、Reset、再インストールを試しても改善しない状態でした。

私の環境では、古いProjectに関する内部情報を整理した後、Agent Environment（エージェントがコマンドを実行する環境）をWSLからWindows Nativeへ変更し、アプリを再起動すると、Windows側のリポジトリを追加できました。ただし、古いProjectの削除と、新しいProjectの追加は、別々の段階で復旧しています。

この記事では実際のログと復旧経緯を紹介しながら、試す順番は設定変更やログ確認から案内します。内部状態ファイルの直接編集は非公式な手順なので、通常の操作で改善しない場合の最後の手段として扱います。

発生した症状と環境
最初に試す順番
1. GitとSSHを確認する
2. Agent EnvironmentをWindows Nativeへ変更する
ログで「どの処理が失敗したか」を確認する
1. 今回見つかった3種類のエラー
古いProjectが消えない場合の最終調査
復旧後に確認したいこと

発生した症状と環境

作業していたのは、WindowsとWSL2（Windows上でLinux環境を動かす仕組み）のUbuntu 24.04を併用する環境です。VS CodeとGitHubも利用していました。

項目	今回の状況
アプリ	Windows版Codex Desktop
ログに記録されたバージョン	`OpenAI.Codex_26.908.9136.0_x64`、app-server `0.154.0-alpha.6.2`
当初のリポジトリ	WSL側の `/home/user/dev/sample-project`
復旧時に追加したリポジトリ	Windows側の `D:\dev\sample-project`
追加時の症状	「プロジェクトを作成できませんでした」／`Failed to create project`
削除時の症状	既存Projectを取り除けず、一部の内部情報を整理しても再起動後に再表示された

バージョンはこの事例の記録であり、最新版を示すものではありません。本文のユーザー名、リポジトリ名、パスは公開用に置き換えています。

Projectの「削除」は、サイドバーにある登録を取り除く操作です。今回の画面では、ローカルファイルやチャットを削除する操作ではないと説明されていました。通常の削除操作は、Projectにあるメニューから「Remove」を選びます。OpenAIのトラブルシューティング

最初に試す順番

同じ症状が出た場合は、次の順番で切り分けると、状態ファイルを書き換える前に確認を進められます。

アプリの更新を確認し、作業を保存して再起動する。
対象フォルダーが存在するか、Gitで読み取れるかを確認する。
Agent Environmentを確認し、WSL利用中ならWindows Nativeを試す。
再起動後に追加・削除を試し、失敗した時刻のログを確認する。
設定や作業内容を退避したうえで、WindowsのRepair、必要ならResetや再インストールを検討する。
古いProjectが残り続ける場合に限り、内部状態ファイルの調査へ進む。

私が実際に試した順番ではRepair、Reset、再インストールでも直りませんでした。ただし、それだけで「再インストールは無意味」「特定のファイルが必ず残る」とは言えません。アプリの再導入で変わる状態と、Projectの登録状態を分けて確認する必要がありました。

GitとSSHを確認する

まず、現在リポジトリがある側の環境で確認します。WSLに置いている場合は、WSLのBashで次を実行します。

# リポジトリの参照可否と未コミットの変更を確認するため、読み取りだけを行う。
git -C /home/user/dev/sample-project rev-parse --show-toplevel
git -C /home/user/dev/sample-project status --short --branch

Windows側にある場合は、PowerShellで確認します。

# Windows側のGitが同じ作業フォルダーを認識できるか確認する。
git -C 'D:\dev\sample-project' rev-parse --show-toplevel
git -C 'D:\dev\sample-project' status --short --branch

ここでエラーが出る場合は、存在しないパスやGitの導入状況を先に調べます。コマンドが成功しても、リポジトリ全体の完全性まで検証したことにはなりません。

GitHubへSSH（鍵を使った暗号化通信）で接続する構成なら、認証も確認できます。HTTPSで接続している場合、この検査は必須ではありません。

ssh -T git@github.com

初回接続でホスト鍵の確認が出たら、表示された指紋をGitHubの公式案内と照合します。今回の確認では、次の応答が返りました。

Hi sample-user! You've successfully authenticated, but GitHub does not provide shell access.

これはGitHubへのSSH認証成功を示します。GitHubはシェルを提供しないため、この検査は成功時でも終了コードが1になります。ただし、特定の非公開リポジトリへのアクセス権や、CodexのProject同期が正常であることまでは分かりません。GitHubのSSH接続テスト

Agent EnvironmentをWindows Nativeへ変更する

アプリの設定でAgent Environmentを開き、WSLからWindows Nativeに変更します。設定名や配置はバージョンで変わる場合があります。変更後はアプリを再起動します。

ここで確認するのは、エージェントの実行環境です。統合ターミナルのシェルをPowerShellへ変える設定とは独立しています。公式資料でも、Windows NativeとWSLの切り替え後には再起動が必要とされています。OpenAIのWindows向け資料

私の環境ではWindows Nativeへの変更直後にセットアップ失敗が表示されましたが、アプリを再起動するとセットアップが完了しました。その後、D:\dev\sample-project をProjectとして追加できました。

ただし、この時点では古いProjectの内部情報も整理済みでした。Windows Nativeへの変更だけで必ず直ると確認したわけではありません。

実行環境	リポジトリの配置候補	利点	移行・運用時の負担
Windows Native	`D:\dev\sample-project` などWindows側	Windows側のツールとファイルの場所を合わせられる。今回の追加成功時の構成	Windows側のGitや、必要な言語処理系・認証設定を確認する必要がある
WSL	`/home/user/dev/sample-project` などLinux側	Linux前提の開発環境を使いやすい	Windowsアプリとの連携では、実行環境とパスの対応も調べる必要がある

OpenAIはNative環境ではWindows側にProjectを置く構成を推奨しています。Microsoftも、主に使うツールのOS側へファイルを置く考え方を案内しています。WSL中心の開発まで一律にWindowsへ移すという意味ではありません。OpenAIのWindows向け資料、MicrosoftのWindows・Linux間のファイル操作

既存リポジトリを別の場所へ用意する場合は、先に未コミットの変更や未追跡ファイルを確認してください。GitHubからの再cloneだけでは、ローカルにしかない作業は戻りません。動作確認が終わるまで元のフォルダーを残します。

ログで「どの処理が失敗したか」を確認する

設定を変更しても追加できない場合は、失敗操作の時刻をメモしてログを調べます。今回の環境では、次の場所に日付別のログがありました。

%LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\Codex\Logs\

これは今回確認した保存場所です。インストール方法やバージョンによっては異なります。見つからないときは、フォルダーを新規作成せず、アプリのログ取得・フィードバック機能も確認します。

次のPowerShellでは、日付別のサブフォルダーも含めて新しいログを最大10件選び、そのファイルからエラーを検索します。

$logDir = Join-Path $env:LOCALAPPDATA 'Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\Codex\Logs'
if (-not (Test-Path -LiteralPath $logDir -PathType Container)) {
    throw 'この保存場所にはログがありません。インストール環境を確認してください。'
}

# 日付別フォルダー内のログを検索対象から漏らさないため再帰的に列挙する。
$logFiles = @(Get-ChildItem -LiteralPath $logDir -Recurse -File -Filter '*.log' |
    Sort-Object LastWriteTime -Descending |
    Select-Object -First 10)
if ($logFiles.Count -eq 0) {
    throw '対象のログファイルがありません。'
}
$logFiles | Select-Object FullName, LastWriteTime
Select-String -LiteralPath $logFiles.FullName `
    -Pattern 'AbsolutePathBuf|assignment sync failed|EISDIR|EXDEV|cross-device link' `
    -Context 2,5

ログはローカルで確認し、共有する場合はトークン、メールアドレス、ユーザー名、非公開リポジトリのURL、個別のthread IDなどを伏せます。最新10件に該当時刻がなければ、その日付のファイルまで対象を広げます。

今回見つかった3種類のエラー

エラー	ログで確認できたこと	この情報だけでは分からないこと
`EISDIR`	WSL側のGitパスを監視する処理が失敗した	リポジトリ自体が壊れているか
`AbsolutePathBuf deserialized without a base path`	ローカルapp-serverへのProject割り当て同期が失敗した	どのパスや状態値が直接の原因か
`EXDEV: cross-device link not permitted`	状態関連ファイルのrename処理が失敗した	Project追加失敗と同じ原因か

最初のログには、次のような識別子がありました。

[git-repo-watcher] Failed to watch git path
errorCode=EISDIR

対象には \\wsl$\Ubuntu-24.04\home\user\dev\old-project や、そのGit関連パスが含まれていました。ここではパス監視の失敗が分かりますが、これを理由に .git を削除したり、作業フォルダーを作り直したりする段階ではありません。

新規Project追加に関して特に気になったのは、次のエラーです。

[host-app-server-projects] Local app-server assignment sync failed
Invalid request: AbsolutePathBuf deserialized without a base path

ログではCLIの初期化後に割り当て同期が失敗していました。そのため、GitHub認証だけを調べ続けるよりも、WSL利用時のProject同期やパスの扱いを確認する方針にしました。ただし、WindowsパスとWSLパスの変換が直接の原因だったかは未確認です。

EXDEV は別途、状態関連ファイルのrename時に出ていました。この環境では、Cドライブ上に見える一部の保存先がジャンクション（別の場所へフォルダーを参照させる仕組み）でDドライブにつながっていました。保存先の実体が関係した可能性はありますが、これがProject追加失敗の根本原因だったとは断定できません。

古いProjectが消えない場合の最終調査

通常の削除操作、再起動、環境変更でも古いProjectが残る場合は、アプリの状態情報を調べる余地があります。ここから先は、今回の事例で行った非公式な調査です。

この手順はCodex内部状態ファイルを直接編集します。必ずCodexを終了し、バックアップを取ってから自己責任で実施してください。

公開された安定仕様として扱えるファイルではありません。キー名や構造が本文と異なる場合や、対象Projectの情報を特定できない場合は編集を止め、匿名化したログと再現手順を添えて、サポートやフィードバック窓口へ相談してください。

1. 完全終了と保存場所の確認

まずCodexの作業を保存し、アプリを終了します。必要ならタスクマネージャーで終了状態を確認します。関連しそうなプロセスを列挙する場合は、PowerShellで次を使えます。

# 名前が似た別用途のプロセスも含み得るため、自動終了はせず候補だけを確認する。
Get-Process |
    Where-Object { $_.ProcessName -match 'Codex|ChatGPT|node_repl' } |
    Select-Object Id, ProcessName, Path

表示されたものを一括で強制終了せず、どのアプリのプロセスか確認します。アプリが動いたまま状態ファイルを編集すると、終了時や同期時に書き戻されるおそれがあります。

今回調べたのは、ユーザーフォルダー配下の .codex にある .codex-global-state.json でした。別の保存先を設定している場合は、実際に使っている場所へ読み替えます。次の例は標準的な配置を確認するものです。

$codexStateDir = Join-Path $HOME '.codex'
Get-Item -LiteralPath $codexStateDir -Force |
    Format-List FullName, Attributes, LinkType, Target

LinkType や Target に値があれば、見えているパスと保存先の実体が異なる可能性があります。今回もこの確認で .codex の参照先を調べました。リンクの張り替えまで同時に行うと切り分けが難しくなるため、まず場所を記録します。

2. 上書きしないバックアップを取る

アプリを終了した状態で、確認済みの保存場所を指定します。次の例は、時刻とランダムな識別子を付けてバックアップを作成し、ハッシュ値でコピーが一致するかを確認します。

$codexStateDir = Join-Path $HOME '.codex'
$statePath = Join-Path $codexStateDir '.codex-global-state.json'
if (-not (Test-Path -LiteralPath $statePath -PathType Leaf)) {
    throw '状態ファイルがありません。実際の保存場所を確認してください。'
}

# 以前の退避ファイルを上書きせず、どの状態へ戻すか選べるようにする。
$backupId = (Get-Date -Format 'yyyyMMdd-HHmmss') + '-' + [guid]::NewGuid().ToString('N')
$backupPath = "$statePath.$backupId.bak"
Copy-Item -LiteralPath $statePath -Destination $backupPath -ErrorAction Stop
if ((Get-FileHash -LiteralPath $statePath).Hash -ne (Get-FileHash -LiteralPath $backupPath).Hash) {
    throw 'バックアップの照合に失敗しました。編集せずに停止してください。'
}
Write-Output "バックアップ: $backupPath"

このコマンドはバックアップのみを作り、元のJSONは変更しません。バックアップにもProject情報などが含まれるため、そのまま公開しないでください。PowerShellのCopy-Itemリファレンス

3. 対象Projectに関連する情報を照合する

今回の状態ファイルには、次のようなキーがありました。キー全体を削除するための一覧ではありません。

キーの例	今回の調査で確認した観点
`local-projects`、`selected-project`、`project-order`	対象Projectの登録や選択・並び順に関係する値
`active-workspace-roots`、`electron-saved-workspace-roots`	古い作業フォルダーへの参照
`thread-project-assignments`、`thread-workspace-root-hints`、`thread-writable-roots`	会話とProject・作業フォルダーの対応に残る参照
`pinned-project-ids`、`sidebar-project-expanded-...`	固定表示やサイドバー表示に関連する値

最初はProject登録やサイドバー周辺の情報を整理しましたが、再起動すると古いProjectが再表示されました。その後の確認で、thread-writable-roots にも古い作業フォルダーのパスが残っていました。

この挙動から、残った会話関連情報が再表示に関係した可能性を考えました。ただし、「Codexが必ずこのキーからProjectを再構築する」という内部仕様を確認したわけではありません。

実際の修復では、WSLからPythonを使い、対象Projectの識別子・パスに対応する登録と関連参照を限定して整理しました。会話本文を保存する sessions/*.jsonl や、Gitリポジトリ、記事などの作業ファイルは削除していません。

この作業を再現するには、現在のJSONの構造、対象の識別子、他のProjectと共有される参照を個別に確認する必要があります。単純な文字列置換や、特定キー配下の全削除は避けてください。ここでは、別バージョンの状態も一括変更してしまう修復スクリプトは掲載しません。

4. 編集結果を確認し、必要なら戻す

編集した場合は、再起動前にJSONとして読み込めるかを確認します。次は構文検査であり、Project間の参照が正しいことまで保証するものではありません。

$codexStateDir = Join-Path $HOME '.codex'
$statePath = Join-Path $codexStateDir '.codex-global-state.json'
Get-Content -LiteralPath $statePath -Raw -Encoding UTF8 |
    ConvertFrom-Json -ErrorAction Stop | Out-Null
Write-Output 'JSONの構文を確認しました。'

その後アプリを起動し、対象Projectの表示だけでなく、他のProjectや既存会話に異常がないかを確認します。構文エラーや想定外の表示があれば、追加の削除は止めます。

戻すときは、再びアプリを完全終了し、変更後のファイルも別名で退避します。そのうえで、記録しておいた編集前のバックアップを .codex-global-state.json にコピーし直し、再起動して確認します。どのバックアップかを確認せず、最新の .bak を機械的に選ばないようにしてください。

私の環境では、対象に関係する情報の整理後、古いProjectがサイドバーから消えました。ただし、この時点でもWSL環境での新規追加は失敗し、AbsolutePathBuf deserialized without a base path が残っていました。

復旧後に確認したいこと

今回の復旧は、次の2段階です。

操作	確認できた結果
古いProjectと関連参照を限定して整理	削除できなかったProjectがサイドバーから消えた
Windows Nativeへ変更し、再起動後にWindows側のリポジトリを追加	新しいProjectの追加に成功した

この違いから、Project削除失敗と追加失敗をひとつの原因で説明しない方が、次に調べる場所を決めやすくなりました。

Windows Nativeを使い続ける場合は、Windows側のGit、使用する言語処理系、認証設定を確認します。WSLにある node_modules やPythonの .venv をそのまま流用せず、必要な依存関係はWindows側で作り直します。GitHub認証も、WSLで成功した結果だけではWindows側の確認を代用できません。

最後に、新規Projectの追加、アプリ再起動後の表示、既存会話へのアクセス、対象フォルダーでのGit操作を確認します。古いProjectの再表示が問題だった場合は、その症状も個別に再確認します。

同じエラーが出ても、原因まで同じとは限りません。まず実行環境と保存場所を合わせて試し、失敗時刻のログから同期処理と保存処理を分けて調べると、内部状態を触る必要があるか判断しやすくなります。

Codex Desktopでプロジェクトを追加・削除できないときの対処法【Windows + WSL】