Codex CLIやCodex VS Code拡張を起動したときに「Error loading configuration: failed to load your workspace-managed config」と表示される場合、まず疑うべきなのはCodex本体の故障だけではなく、設定ファイル・ワークスペース管理設定・拡張機能側の読み込み失敗です。GitHub issueやOpenAI Developer Community、公式ドキュメントを整理すると、config.toml、auth.json、ワークスペース設定、PATH、Windows sandbox、VS Code拡張のログなど、確認すべき場所がかなりはっきり見えてきます。
この記事では、2026年5月18日時点で確認できる情報をもとに、エラーの意味、最初に試すべき復旧手順、Codex CLI・Codex app・Codex VS Code拡張・Windows環境・WSL環境それぞれの切り分け方をまとめます。体験談ではなく、公開されている不具合報告と公式情報から、検索してきた人がそのまま作業できる形に整理しています。
| この記事のポイント |
|---|
✅ failed to load your workspace-managed configで最初に見るべき場所がわかる |
✅ config.toml、auth.json、VS Codeログ、PATHの切り分け順がわかる |
| ✅ codex cli、codex app、codex vscode、codex windowsの違いを整理できる |
| ✅ 再発を避けるための設定管理とバックアップ方法がわかる |
codex error loading configuration failed to load your workspace-managed configの原因整理
- codex error loading configuration failed to load your workspace-managed configはconfig.tomlやワークスペース管理設定を疑うべきエラー
- codex cli update直後に出た場合は最新版の不具合と設定破損を切り分ける
- codex cli install後すぐ落ちる場合はCODEX_HOMEとconfig.tomlの場所を確認する
- codex vscode拡張で止まる場合は出力ログからconfigエラーを読む
- codex windowsではsandboxやPATHの影響も同時に確認する
- codex app cliを併用している環境ではデスクトップ版とCLIの設定競合を疑う
codex error loading configuration failed to load your workspace-managed configはconfig.tomlやワークスペース管理設定を疑うべきエラー
このエラーは、直訳すると「構成の読み込みエラー: ワークスペース管理の設定を読み込めなかった」という意味になります。検索している人の多くは、Codexを起動した瞬間にアプリやCLIが落ちてしまい、そもそも会話画面まで進めない状態だと思われます。
GitHubのIssue #14143では、Codex CLI 0.112.0を起動した直後に「Error loading configuration: failed to load your workspace-managed config」と表示される事例が報告されています。報告者は、組織側で中央管理のCodex設定をホストしていないにもかかわらず、このメッセージが出たと説明しています。つまり、表示文だけを見ると「企業管理設定」のように見えますが、実際にはローカル設定やワークスペース側設定の読み込み失敗として扱ったほうがよさそうです。
“Error loading configuration: failed to load your workspace-managed config”
引用元: https://github.com/openai/codex/issues/14143
まず押さえておきたいのは、Codexにはユーザー単位の設定とプロジェクト単位の設定がある点です。公式ドキュメントでは、Codexのローカル状態は通常CODEX_HOME配下に保存され、デフォルトでは~/.codexが使われると説明されています。さらに、プロジェクト内の.codex/config.tomlも読み込まれる仕組みがあるため、1つの設定ファイルだけを見て判断すると原因を見落とすかもしれません。
📌 エラーメッセージから見る初期判断表
| 表示・状況 | 最初に疑う場所 | 補足 |
|---|---|---|
| CLI起動直後に落ちる | ~/.codex/config.toml |
ユーザー設定の破損や非対応キーの可能性 |
| 特定プロジェクトだけ落ちる | .codex/config.toml |
プロジェクト設定の読み込み失敗の可能性 |
| VS Code拡張だけ止まる | VS CodeのOutputログ | 拡張機能側の設定読み込みエラーかもしれません |
| Windowsだけ不安定 | PATH・sandbox・Visual C++ | Codex以外の環境依存も疑う |
ここで重要なのは、すぐに再インストールへ走らないことです。もちろん再インストールで直るケースもあり得ますが、調査した範囲では、config.tomlやauth.jsonの削除・修正、VS Codeログの確認、PATH調整など、設定周りの対応で改善したという報告が目立ちます。
🧭 まず見るべき順番
| 優先度 | 確認項目 | 理由 |
|---|---|---|
| 1 | エラーがCLIかVS CodeかCodex appか | 表面ごとに原因が違うため |
| 2 | ~/.codex/config.toml |
Codexの主要なローカル設定だから |
| 3 | プロジェクトの.codex/config.toml |
workspace-managed configに関係しやすいから |
| 4 | auth.json |
ログインや拡張機能の再認証に関係するため |
| 5 | PATH・Windows sandbox | Windowsでは環境要因が混ざりやすいため |
結論として、このエラーは「Codexが読もうとした設定のどこかで失敗している」と捉えるのが実務的です。 企業管理設定が本当に存在するケースもあるかもしれませんが、個人利用や小規模開発環境では、ローカルのconfig.toml、プロジェクト配下の.codex/config.toml、VS Code拡張の設定破損から順に確認するのが現実的です。
codex cli update直後に出た場合は最新版の不具合と設定破損を切り分ける
Codex CLIをアップデートした直後にこのエラーが出た場合、まず考えたいのは「新しいバージョンが古い設定をうまく読めなくなった可能性」です。これは断定ではありませんが、OpenAI Developer Communityでは、VS Code拡張の更新後にconfig.toml内の特定設定を削除したら動いたという報告があります。
特に注意したいのは、model_providerのような高度な設定です。コミュニティ投稿では、Codex拡張のOutputログにmodel-provider関連のエラーが出ており、その設定を削除して拡張機能を無効化・再有効化したところ、デフォルトのモデルプロバイダーで起動できたという流れが紹介されています。つまり、アップデート後は以前は有効だった設定が、今のバージョンでは合わないことがあるかもしれません。
公式のChangelogを見ると、Codex CLIは2026年5月時点でも継続的に更新されています。2026年5月8日のCodex CLI 0.130.0では、app-serverやWindows sandbox関連の改善、設定変更の反映に関する修正などが記載されています。更新頻度が高いツールでは、機能追加と同時に設定の扱いが変化することも一般的にはあります。
📌 アップデート直後の切り分け表
| 状況 | 見る場所 | 試すこと |
|---|---|---|
| 更新直後からCLIが落ちる | codex --version |
どのバージョンで起きたか記録する |
| 古い設定を使っている | ~/.codex/config.toml |
一時的にリネームして起動確認 |
| 特定プロジェクトのみ失敗 | .codex/config.toml |
プロジェクト設定を一時退避 |
| VS Code拡張だけ失敗 | OutputのCodexログ | TOML構文や非対応キーを確認 |
いきなり~/.codexフォルダ全体を削除する方法も見かけますが、これはログイン情報や履歴に影響する可能性があります。作業前には、できればフォルダごとバックアップしてから進めるのが無難です。たとえばWindowsなら%USERPROFILE%.codex、macOSやLinuxなら~/.codexをコピーしておくと戻しやすくなります。
🛠 バージョン更新時に残しておきたい情報
| メモする項目 | 例 | なぜ必要か |
|---|---|---|
| Codex CLIバージョン | 0.112.0、0.130.0など |
GitHub issueや修正履歴と照合しやすい |
| インストール方法 | npm、brew、desktop appなど | 依存関係や更新経路が変わるため |
| 使用環境 | Windows、Darwin、WSLなど | OS固有の問題を切り分けるため |
| 変更した設定 | model_providerなど |
戻すべき箇所を特定するため |
Codex CLI update後のトラブルでは、「最新版だから常に安定している」とは限りません。逆に、古いバージョンへ戻すことで改善するケースもコミュニティ上では報告されています。ただし、古いバージョンへの固定はセキュリティや機能面で不利になることもあるため、まずは設定ファイルの退避や最小構成での起動確認を優先するとよいでしょう。
codex cli install後すぐ落ちる場合はCODEX_HOMEとconfig.tomlの場所を確認する
Codex CLIをインストールした直後に落ちる場合、インストールそのものだけでなく、Codexが参照する設定フォルダを確認する必要があります。公式ドキュメントでは、Codexのローカル状態はCODEX_HOME配下に置かれ、デフォルトでは~/.codexが使われると説明されています。
CODEX_HOMEというのは、Codexが設定や認証情報、履歴などを置くホームフォルダのようなものです。ここにはconfig.toml、auth.json、history.jsonl、ログやキャッシュなどが存在する可能性があります。つまり、Codex CLIを再インストールしても、このフォルダに壊れた設定が残っていれば、同じエラーが出続けるかもしれません。
GitHub Issue #2928では、npm i -g @openai/codexでインストールした後に「Error loading configuration: No such file or directory (os error 2)」が出る事例も報告されています。今回のメインエラーとは文言が違いますが、どちらも設定読み込みまわりの失敗として近い領域にあります。
📌 CODEX_HOMEまわりの確認表
| 確認対象 | 標準的な場所 | 役割 |
|---|---|---|
config.toml |
~/.codex/config.toml |
Codexのユーザー設定 |
auth.json |
~/.codex/auth.json |
ファイルベース認証情報の可能性 |
history.jsonl |
~/.codex/history.jsonl |
履歴保存が有効な場合の履歴 |
.codex/config.toml |
プロジェクト配下 | プロジェクト単位の設定 |
特に初心者が混乱しやすいのは、「Codex CLIを入れ直したのに直らない」という状態です。アプリ本体と設定フォルダは別物なので、本体を削除しても~/.codexが残っていれば、同じ設定を再び読み込もうとします。これはVS Code拡張でも似た構造になりやすく、拡張を入れ直してもユーザー設定が残っていると症状が続くことがあります。
🧪 最小構成で起動確認する考え方
| 手順 | 操作イメージ | 注意点 |
|---|---|---|
| 1 | config.tomlをバックアップ |
削除ではなく退避が安全 |
| 2 | Codexを起動 | デフォルト設定で動くか確認 |
| 3 | 動いたら設定を少しずつ戻す | 一気に戻すと原因が見えにくい |
| 4 | 動かなければ認証やPATHを見る | 設定以外の要因へ進む |
公式ドキュメントでは、CLIから一時的に設定を上書きする--configも説明されています。たとえばモデルやsandbox設定を一回だけ変えて起動する使い方です。ただし、エラーで起動前に設定読み込みが止まっている場合は、まず壊れている設定ファイルの退避が必要になることもあります。
codex vscode拡張で止まる場合は出力ログからconfigエラーを読む
Codex VS Code拡張で「Loading」のまま止まる、ログイン画面が出ない、タスクを読み込めない、入力できないといった症状が出る場合、まずVS CodeのOutputログを見るべきです。コミュニティ投稿では、View > Outputからcodexを選び、ログに出ている設定エラーを確認したという事例が紹介されています。
VS Code拡張の問題は、CLI単体の問題と重なって見えることがあります。たとえば、CLIでは動くのにVS Code拡張だけ止まる場合、拡張機能のバージョン、VS Code側の状態、.codex/config.toml、auth.json、認証状態、PATHなどが絡みます。反対に、CLIも拡張も両方落ちるなら、より根本的なCodex設定を疑うべきです。
OpenAI Developer Communityでは、~/.codex/フォルダを削除してVS Codeを再起動したところ、再ログインが促されてauth.jsonが再作成され、拡張機能が読み込まれたという投稿があります。また、別の投稿ではconfig.toml内のmodel provider設定を削除して改善したとされています。
📌 VS Code拡張の症状別チェック表
| 症状 | 優先確認 | 参考になる対応 |
|---|---|---|
| Loadingのまま止まる | Outputログ | codexチャンネルのエラーを見る |
| ログイン画面が出ない | auth.json |
退避後に再ログイン |
| 入力できない | 拡張機能バージョン | ダウングレード報告もあり |
| TOML parse error | config.toml |
構文修正または設定削除 |
| MCP process exited | Visual C++など | Windows依存の可能性 |
ここで注意したいのは、auth.jsonやconfig.tomlを削除すると、ログイン状態や設定がリセットされる可能性がある点です。コミュニティ投稿では「Delete auth.json and config.toml」といった強い対処も見られますが、まずはファイル名を変えて退避するほうが安全です。
📁 VS Code側で確認したい場所
| 場所 | Windows例 | 目的 |
|---|---|---|
| Codex設定 | %USERPROFILE%.codex |
認証・設定の確認 |
| VS Code拡張 | %USERPROFILE%.vscodeextensions |
拡張の削除・再導入確認 |
| Outputログ | VS Code内 | 実際のエラー文確認 |
| ワークスペースファイル | *.code-workspace |
フォルダ解決エラー確認 |
VS Code関連では、Codexそのものではなくワークスペースのパス解決が原因になることもあります。Stack Overflowでは、VS Codeのworkspace folderが解決できない場合、.code-workspace内のフォルダパスを絶対パスに直す対応が紹介されています。Codexのworkspace-managed configエラーと同じとは限りませんが、ワークスペース関連の表示が絡む場合は確認する価値があります。
codex windowsではsandboxやPATHの影響も同時に確認する
WindowsでCodexを使っている場合、config.tomlだけでなく、Windows sandbox、PATH、Visual C++ Redistributable、Git Bashなどの影響も考える必要があります。公式のWindowsドキュメントでは、CodexはWindowsネイティブ環境でsandboxを使い、ファイル書き込みやネットワークアクセスを制限すると説明されています。
Windows sandboxには、elevatedとunelevatedというモードがあります。公式ドキュメントでは、elevatedが推奨され、管理者承認が難しい環境ではunelevatedがフォールバックとして使えるとされています。ただし、企業管理PCではローカルユーザー作成、ファイアウォール、ログオン権限などが制限され、sandbox設定が失敗することもあるようです。
Codex VS Code拡張の「Failed to Load Tasks」に関するコミュニティ投稿では、C:Program FilesGitbinをPATHから外したら動いたという報告もあります。これはすべての環境に当てはまるとは言えませんが、WindowsではPATH上のbashやGit関連ツールが影響する可能性もあると考えておくとよいでしょう。
📌 Windowsで混ざりやすい原因表
| 原因候補 | 代表的な症状 | 確認方法 |
|---|---|---|
config.toml破損 |
起動直後の設定エラー | ファイル退避で確認 |
| PATHのbash衝突 | VS Code拡張のタスク読み込み失敗 | PATHからGit binを一時的に外す |
| Visual C++不足 | 0xC0000135など |
Outputログの終了コード確認 |
| sandbox権限 | コマンド実行失敗 | sandboxログや公式FAQを確認 |
| ワークスペースパス | フォルダ未解決 | .code-workspaceを確認 |
OpenAI Developer Communityでは、WindowsでMCP/Codexプロセスが3221225781 (0xC0000135)で終了する場合、Microsoft Visual C++ Redistributable 2015–2022 x64の不足が原因だったという投稿もあります。今回のメインエラーとは別系統かもしれませんが、VS Code拡張が起動しない場合には見逃せない情報です。
🧪 Windowsでの切り分け順
| 順番 | 作業 | 狙い |
|---|---|---|
| 1 | VS Code Outputログを確認 | 具体的なエラーを見る |
| 2 | config.tomlを退避 |
設定起因か確認 |
| 3 | auth.jsonを退避 |
認証起因か確認 |
| 4 | PATHを確認 | Git Bashなどの影響を切り分け |
| 5 | sandbox設定を確認 | Windows固有の権限問題を見る |
Windowsでは、1つの対処だけで決め打ちしないほうが安全です。設定ファイル、認証、拡張機能、PATH、Visual C++、sandboxが同時に絡むことがあります。特に会社PCやセキュリティソフトが強い環境では、Codexの問題に見えて実はOSポリシーや権限設定が原因というケースもあり得ます。
codex app cliを併用している環境ではデスクトップ版とCLIの設定競合を疑う
GitHub Issue #14143では、報告者がbrewでCodexをインストールしており、さらにCodex desktop appも使っていたと説明しています。このことから、Codex appとCodex CLIを併用している環境では、どちらがどの設定を読んでいるのかを意識する必要があります。
Codex app、Codex CLI、Codex VS Code拡張は、表面としては別物に見えても、ローカルのCodex設定や認証情報を共有している可能性があります。公式ドキュメントでも、CODEX_HOME配下に設定や認証情報が置かれると説明されているため、CLIで壊れた設定がVS Code拡張にも影響する、あるいはその逆が起きることも考えられます。
特に、Codex app cli、codex app server、codex app windows、codex app wslのように複数の実行面を使い分けている人は、問題の切り分けが難しくなります。たとえば、Codex appは起動するのにCLIだけ落ちる場合と、CLIは動くのにVS Code拡張だけ止まる場合では、見るべき場所が違います。
📌 Codexの利用面ごとの切り分け表
| 利用面 | 起きやすい確認ポイント | 優先して見る場所 |
|---|---|---|
| Codex CLI | config.toml、CLIバージョン |
~/.codex |
| Codex app | アプリ状態、共有設定 | app側の設定とCODEX_HOME |
| VS Code拡張 | Outputログ、拡張バージョン | VS Code Output |
| WSL | Linux側Node・npm・~/.codex |
WSL内ホーム |
| app server | config変更反映やサーバー状態 | changelogと起動ログ |
Codex CLI 0.130.0のChangelogでは、app-serverのlive threadsが設定変更を再起動なしで拾う修正が入ったとされています。これは今回のエラーそのものの修正とは断定できませんが、Codex周辺では設定変更の反映や複数面の管理が継続的に改善されていることがわかります。
🧭 併用環境での確認マトリクス
| CLI | VS Code | Codex app | 推定しやすい原因 |
|---|---|---|---|
| 落ちる | 落ちる | 落ちる | 共通設定や認証の問題かもしれません |
| 落ちる | 動く | 動く | CLI固有設定やPATHの可能性 |
| 動く | 落ちる | 動く | VS Code拡張やOutputログを優先 |
| 動く | 動く | 落ちる | app側の状態や更新を確認 |
| WSLだけ動く | Windowsは落ちる | 状況次第 | Windows sandboxやPATHを疑う |
併用している人ほど、「どこで起きているか」を最初にメモするだけで復旧が早くなります。Codex app、Codex CLI、Codex VS Code拡張を一度に直そうとせず、まず1つの面で最小構成起動を確認し、その後ほかの面に広げるのが現実的です。
codex error loading configuration failed to load your workspace-managed config後の再発防止と関連トラブル対策
- codex cli windowsの復旧はバックアップしてから設定を最小化すること
- codex vscode windowsの復旧はauth.json削除や再ログインも選択肢になる
- codex approval_policyなど高度な設定は一つずつ戻すべき理由
- codex windows sandboxはelevatedとunelevatedの違いを理解して選ぶ
- codex app wslやcodex app linuxへ逃がす判断はWindows固有問題の切り分けに役立つ
- codex cli コマンドの一時上書きで起動確認を短時間で済ませる
- 総括：codex error loading configuration failed to load your workspace-managed configのまとめ
codex cli windowsの復旧はバックアップしてから設定を最小化すること
WindowsでCodex CLIを復旧する場合、最初にやるべきことは削除ではなくバックアップです。%USERPROFILE%.codexを丸ごとコピーし、そのうえでconfig.tomlだけを一時的にリネームする流れにすると、必要な設定を後から戻せます。
よくある失敗は、焦って.codexフォルダを丸ごと削除してしまうことです。コミュニティ上ではそれで直ったという報告もありますが、認証情報や履歴も失う可能性があります。特に仕事で使っている環境では、まず退避、次に最小構成、最後に設定を戻すという順番が無難です。
codex cli windowsで検索している人は、CLI本体のインストール、VS Code拡張、Windows app、PATH、sandboxなどが混ざっていることがあります。復旧作業では「CLIだけを直したいのか」「VS Code拡張も直したいのか」を分けて考えると整理しやすくなります。
📌 Windows復旧の安全な作業表
| 手順 | 操作 | 目的 |
|---|---|---|
| 1 | %USERPROFILE%.codexをコピー |
元に戻せる状態を作る |
| 2 | config.tomlをリネーム |
設定起因か確認 |
| 3 | Codex CLIを起動 | デフォルトで動くか見る |
| 4 | auth.jsonを必要に応じて退避 |
認証起因を切り分け |
| 5 | PATHやsandboxへ進む | Windows固有要因を確認 |
最小構成で起動したら、古いconfig.tomlの内容を一気に戻さないほうがよいです。model、model_provider、approval_policy、sandbox、MCP、hooksなどを少しずつ戻し、どの設定を入れた時点で落ちるか確認します。これにより、問題のあるキーをかなり絞れます。
🧪 設定を戻す順番の目安
| 戻す順番 | 設定例 | 理由 |
|---|---|---|
| 1 | model |
基本設定なので影響を見やすい |
| 2 | approval_policy |
実行権限に関係するため |
| 3 | sandbox |
Windowsでは失敗要因になりやすい |
| 4 | model_provider |
カスタム設定は互換性に注意 |
| 5 | MCP・hooks | 外部連携が絡み複雑になりやすい |
この作業は少し地味ですが、再発防止にはかなり有効です。設定ファイルを「全部入り」にしてしまうと、アップデート後にどこが壊れたのかわかりにくくなります。Codex CLIを安定して使いたいなら、普段使う設定はできるだけ少なくし、特殊な設定はコメントや別ファイルで管理するのがおすすめです。
codex vscode windowsの復旧はauth.json削除や再ログインも選択肢になる
Codex VS Code拡張がWindowsで止まる場合、auth.jsonの退避や再ログインが有効なケースもあります。OpenAI Developer Communityでは、auth.jsonを削除またはリネームしてVS Codeを再起動すると、ログイン画面が再表示されたという報告があります。
ただし、auth.jsonは認証情報に関係するファイルと考えられるため、安易に削除するより、まずはauth.json.bakのように名前を変えて退避するのが安全です。再ログインして動くようになれば、古い認証状態が問題だった可能性があります。
Codex VS Code拡張では、ログイン画面が出ない、Loadingから進まない、入力欄が反応しない、Failed to Load Tasksが出るなど、症状が複数あります。これらを全部同じ原因と決めつけるのは危険です。まずOutputログを見て、認証エラーなのか、設定エラーなのか、プロセス起動エラーなのかを分ける必要があります。
📌 VS Code Windows復旧パターン表
| 症状 | 試す候補 | 注意点 |
|---|---|---|
| ログイン画面が出ない | auth.json退避 |
再ログインが必要 |
| Loadingから進まない | config.toml退避 |
設定が消えないようバックアップ |
| TOML parse error | 構文修正 | 行番号が出る場合はそこを見る |
| 403 Forbidden | アカウント・ワークスペース | 権限や契約状態の可能性 |
0xC0000135 |
Visual C++確認 | Codex設定以外の問題かもしれません |
コミュニティ投稿では、Codex拡張のバージョンを0.4.12に戻したら改善したという報告もあります。ただし、これはその時点の一時的な回避策であり、2026年5月18日時点の最新環境にそのまま当てはまるとは限りません。古いバージョンへの固定は、あくまで一時的な切り分けとして考えるのがよいでしょう。
🧭 VS Code側で見るログの意味
| ログの種類 | 何を示すか | 対応の方向 |
|---|---|---|
| TOML parse error | 設定ファイルの書式ミス | config.toml修正 |
| model provider error | モデル提供元設定の問題 | 該当設定を削除または修正 |
| 403 Forbidden | 権限・ワークスペース問題 | アカウントや組織設定を確認 |
| process exited | 依存DLLや実行環境 | Visual C++やPATHを確認 |
| workspace not found | VS Codeワークスペース | .code-workspace確認 |
VS Code拡張の復旧では、「Codex CLIを先に入れてcodex loginを実行したら動いた」という投稿もあります。これはすべての人に当てはまるとは限りませんが、CLI側で認証を整えてから拡張を開く流れは、切り分けとして試す価値があります。
codex approval_policyなど高度な設定は一つずつ戻すべき理由
Codexの設定には、approval_policy、sandbox、model provider、MCP、hooks、profilesなど、便利な高度設定があります。ただし、こうした設定はアップデートや実行環境の違いで読み込みに失敗する可能性があるため、エラー復旧時には一つずつ戻すべきです。
公式のAdvanced Configurationでは、CLIから--configで一時的に設定を上書きできること、config.tomlにprofileを定義できること、プロジェクト配下の.codex/config.tomlが読み込まれることなどが説明されています。便利な反面、設定レイヤーが増えるほど、どこで失敗しているか見えにくくなります。
approval_policyは、Codexがどの場面で承認を求めるかに関係する設定です。たとえばnever、on-requestなどの方針があります。今回のエラーの直接原因とは限りませんが、設定ファイルの中に書かれている以上、構文ミスや非対応値があれば読み込み失敗の一因になるかもしれません。
📌 高度設定のリスク整理表
| 設定 | 便利な点 | 復旧時の注意点 |
|---|---|---|
approval_policy |
承認フローを調整できる | 非対応値や構文ミスに注意 |
sandbox |
実行範囲を制御できる | Windowsでは権限問題が絡む |
model_provider |
外部プロバイダーを使える | 更新後の互換性に注意 |
profiles |
設定を切り替えられる | IDE拡張では未対応の場合あり |
hooks |
実行前後処理を追加できる | 実験的機能として扱う |
公式ドキュメントでは、profilesは実験的で、Codex IDE extensionでは現在サポートされていないと説明されています。つまり、CLI用に便利なprofileを書いていても、VS Code拡張では想定通り扱われない可能性があります。こうした差分も、エラーの原因に見えることがあります。
🧪 設定レイヤー別の確認表
| レイヤー | 場所 | 確認ポイント |
|---|---|---|
| ユーザー設定 | ~/.codex/config.toml |
まずここを最小化 |
| プロジェクト設定 | .codex/config.toml |
特定repoだけ落ちる場合に確認 |
| CLI一時上書き | --config |
起動確認や検証に使う |
| VS Code設定 | 拡張機能側 | Outputログと合わせて確認 |
| 組織管理設定 | 管理者側 | 個人では見えない可能性あり |
高度な設定を使うこと自体は悪くありません。ただし、Codexのように更新頻度の高いツールでは、設定ファイルを「メンテナンス対象」として扱う必要があります。トラブルが起きたら、まずシンプルな設定へ戻し、動作確認後に一つずつ足していくのが安全です。
codex windows sandboxはelevatedとunelevatedの違いを理解して選ぶ
CodexをWindowsで使う場合、sandboxの理解はかなり重要です。公式ドキュメントでは、Windowsネイティブ環境のCodexは、agent modeでWindows sandboxを使い、作業フォルダ外への書き込みやネットワークアクセスを制限すると説明されています。
設定例としては、[windows] sandbox = "elevated"または"unelevated"があります。elevatedは推奨される強いsandboxで、専用の低権限ユーザー、ファイルシステム権限、ファイアウォールルールなどを使うとされています。一方、unelevatedはフォールバックで、管理者承認が難しい環境でも使いやすい反面、分離の強さは弱めと説明されています。
このsandbox設定が直接「workspace-managed config」エラーを出すとは限りません。しかし、WindowsでCodexが起動しない、コマンドが実行できない、権限エラーが出る、エラー1385が出るといった場合には、sandbox周辺の確認が必要です。
📌 Windows sandbox比較表
| sandbox | 特徴 | 向いている状況 |
|---|---|---|
| elevated | 推奨の強いsandbox | 管理者承認が可能なPC |
| unelevated | フォールバック | 企業PCなどで強い設定が難しい場合 |
| WSL2 | Linux sandboxを使用 | Linuxツール中心の開発 |
| full access | 制限が弱い | 通常は慎重に扱うべき |
公式ドキュメントでは、Windows 11が推奨、最近のWindows 10はベストエフォート、古いWindows 10は非推奨に近い扱いで説明されています。特にWindows 10ではConPTYなどのモダンなコンソール機能が関係するため、古い環境では予期せぬ失敗が起きやすいかもしれません。
🧭 sandbox関連で見るべきエラー表
| 表示・状態 | 可能性 | 対応 |
|---|---|---|
| setup failed | 管理者承認やポリシー | 再実行またはIT管理者確認 |
| error 1385 | ログオン権限不足 | sandboxユーザー権限を確認 |
| フォルダが読めない | sandbox read権限不足 | /sandbox-add-read-dirを検討 |
| writable by Everyone警告 | Windows権限が広すぎる | フォルダ権限を見直す |
| unelevatedへ切替 | elevated失敗 | 暫定利用しつつ原因調査 |
Windows sandboxを触るときは、むやみに制限を外すのではなく、どの制限で止まっているかを見ます。特にfull accessのような強い権限は便利ですが、意図しない破壊的操作のリスクもあるため、普段使いではsandbox境界を維持するほうが無難です。
codex app wslやcodex app linuxへ逃がす判断はWindows固有問題の切り分けに役立つ
WindowsでCodexが不安定な場合、WSL2やLinux環境で同じプロジェクトを試すと、原因がWindows固有かどうかを切り分けられます。公式Windowsドキュメントでは、Codex CLIをWSLで使う手順として、WSLを起動し、Node.jsを入れ、npm i -g @openai/codexでCodexをインストールする流れが説明されています。
WSLを使うメリットは、WindowsのPATH、Visual C++、ネイティブsandbox、企業ポリシーの影響を一部切り離せることです。もちろん、WSL側にもNode.js、npm、認証、~/.codex設定が必要なので、完全に問題が消えるわけではありません。それでも、Windowsネイティブだけで悩むより原因を分けやすくなります。
公式ドキュメントでは、WSL1はCodex 0.114までのサポートで、Codex 0.115以降はLinux sandboxがbubblewrapへ移ったためWSL1はサポート対象外と説明されています。つまり、2026年5月18日時点でWSLを使うなら、基本的にはWSL2を前提に考えるべきです。
📌 Windows・WSL・Linuxの切り分け表
| 環境 | メリット | 注意点 |
|---|---|---|
| Windows native | Codex appやVS Codeと相性がよい | sandbox・PATH・権限問題が出ることあり |
| WSL2 | Linux系ツールに近い | Windows側とは設定場所が別 |
| Linux | シンプルに切り分けやすい | Windows app固有問題は再現しない |
/mnt/c配下 |
Windowsファイルに触りやすい | I/Oや権限で遅い場合あり |
公式ドキュメントでは、WSL内で作業する場合、/mnt/c/...ではなく~/code/my-appのようなLinuxホーム配下にリポジトリを置くほうが速く、シンボリックリンクや権限問題も少ないとされています。Codexの設定トラブルとは別に、開発体験にも影響します。
🧭 WSLへ逃がすべきケース
| 状況 | WSL検討度 | 理由 |
|---|---|---|
| Windows sandbox setupが失敗する | 高 | ネイティブsandboxを避けられる |
| PATHやGit Bashが怪しい | 中 | Linux側PATHで切り分け可能 |
| VS Code拡張だけ不調 | 中 | WSL remoteで再確認できる |
| 企業PCの制限が強い | 中 | ただしWSL自体が制限される場合あり |
| Codex app固有の問題 | 低 | app側の問題はWSLで再現しない可能性 |
codex app linuxやcodex app wslで検索している人は、Windowsで詰まった結果、別環境を探している可能性があります。逃げ道としてのWSLは有効ですが、あくまで切り分け手段です。最終的にWindows appやVS Code拡張を使いたいなら、Windows側のconfig.toml、PATH、sandboxも戻って確認する必要があります。
codex cli コマンドの一時上書きで起動確認を短時間で済ませる
Codex CLIには、--configを使って一回だけ設定を上書きする方法があります。公式ドキュメントでは、専用フラグがある場合はそれを優先し、任意のキーを上書きしたい場合は-cまたは--configを使うと説明されています。
たとえば、モデルを一時的に変える、sandboxのnetwork accessを変える、環境変数ポリシーを調整する、といった使い方が紹介されています。設定ファイルを直接書き換えずに検証できるので、復旧作業では便利です。
ただし、注意点もあります。Codexが起動前にユーザー設定やプロジェクト設定の読み込みで落ちている場合、--configで上書きしても先に読み込みエラーが出る可能性があります。その場合は、まず問題のあるconfig.tomlを退避してから、CLI引数で最小構成を試すほうが現実的です。
📌 CLI一時上書きの使いどころ
| 使いどころ | 例 | 注意点 |
|---|---|---|
| モデル変更 | --model |
専用フラグがあればそちらを使う |
| 任意設定変更 | --config key=value |
値はTOMLとして解釈される |
| sandbox検証 | network accessなど | 安全面に注意 |
| 原因切り分け | 最小設定で起動 | 壊れたconfigは先に退避 |
公式ドキュメントでは、--configの値はTOMLとしてパースされると説明されています。つまり、文字列を渡すときは引用符の扱いに注意が必要です。シェルによってクォートの解釈も変わるため、Windows PowerShell、cmd、bashで同じ書き方が通らないこともあります。
🧪 一時上書きと設定ファイル編集の比較
| 方法 | メリット | デメリット |
|---|---|---|
--config |
ファイルを汚さず検証できる | クォートが難しい場合あり |
config.toml編集 |
永続設定に向く | 壊すと起動不能になりやすい |
| profile | 複数設定を切替可能 | IDE拡張では未対応の場合あり |
| ファイル退避 | 原因切り分けが早い | 再ログインや再設定が必要なことあり |
Codex CLI コマンドで復旧確認をするなら、「最小構成で起動するか」をまず見ます。起動できたら、config.tomlに戻す設定を少しずつ増やします。この進め方なら、どの設定がfailed to load your workspace-managed configにつながっているかを見つけやすくなります。
総括：codex error loading configuration failed to load your workspace-managed configのまとめ
最後に記事のポイントをまとめます。
codex error loading configuration failed to load your workspace-managed configは、まず設定読み込み失敗として見るべきである。- 最初に確認する場所は
~/.codex/config.tomlとプロジェクト配下の.codex/config.tomlである。 - Codex CLIを再インストールしても、
CODEX_HOME配下の設定が残ると同じ症状が続くことがある。 - Codex CLI update直後の発生では、古い設定と新しいバージョンの相性を疑うべきである。
- Codex VS Code拡張では、View > Outputから
codexログを確認するのが重要である。 auth.jsonの退避や再ログインは、VS Code拡張の復旧候補である。- Windowsでは
config.tomlだけでなく、PATH、Visual C++、sandbox、権限ポリシーも確認対象である。 codex approval_policy、model_provider、hooks、MCPなどの高度設定は一つずつ戻すべきである。codex windows sandboxでは、elevatedとunelevatedの違いを理解して選ぶ必要がある。- WSL2やLinux環境で起動確認すると、Windows固有問題の切り分けに役立つ。
--configによる一時上書きは、設定ファイルを壊さず検証するために有効である。- 削除より先にバックアップし、最小構成で起動確認するのが実務的である。
記事作成にあたり参考にさせて頂いたサイト
- https://github.com/openai/codex/issues/14143
- https://community.openai.com/t/bug-report-codex-vs-code-extension-stuck-on-loading-never-shows-login-screen/1355379?page=2
- https://github.com/openai/codex/issues/2928
- https://stackoverflow.com/questions/50992459/vs-code-can-not-resolve-workspace-folder
- https://community.openai.com/t/codex-on-vs-code-failed-to-load-tasks/1355969
- https://developers.openai.com/codex/config-advanced
- https://www.reddit.com/r/codex/new/
- https://developers.openai.com/codex/changelog
- https://www.reddit.com/r/codex/comments/1qujcm7/codex_app_replaces_the_terminal/
- https://developers.openai.com/codex/windows
各サイト運営者様へ
有益な情報をご公開いただき、誠にありがとうございます。
感謝の意を込め、このリンクはSEO効果がある形で設置させていただいております。
※リンクには nofollow 属性を付与しておりませんので、一定のSEO効果が見込まれるなど、サイト運営者様にとってもメリットとなれば幸いです。
当サイトは、インターネット上に散在する有益な情報を収集し、要約・編集してわかりやすくお届けすることを目的としたメディアです。
私たちは、情報の収集や整理を通じて「情報をまとめてわかりやすく伝える」という形で新たな価値を提供できるのではないかと考え、運営しております。
なお、引用や参照の方法には不備、あるいはご不快に感じられる点がございましたら、迅速に対応いたしますので、お手数ですがお問い合わせフォームよりご連絡いただければ幸いです。
今後とも、どうぞよろしくお願いいたします。
当サイトでは、インターネット上に散らばるさまざまな情報を収集し、AIを活用しながら要約・編集を行い、独自の切り口で見解を交えながらわかりやすい形でお届けしています。
情報の整理・編集にあたっては、読者やオリジナル記事の筆者へご迷惑をおかけしないよう、細心の注意を払って運営しておりますが、万が一、掲載内容に問題がある場合や修正・削除のご要望がございましたら、どうぞお気軽にお問い合わせください。
迅速に対応をさせていただきます。
その際には、該当記事の URLやタイトルをあわせてお知らせいただけますと、より速やかに対応 することができますのでそちらもご協力いただけますと大変幸いでございます。
今後とも当サイトをよろしくお願いいたします。
