Windows版Codex CLIで「CreateProcessWithLogonW failed: 1385」が発生する原因とは？workspace-writeで読み取りすら失敗する症状を徹底整理
Windows環境でCodex CLIを使っていると、単純なファイル一覧取得やワークスペース内の読み取りコマンドですら実行前に失敗し、原因が見えにくいケースがあります。とくに workspace-write を有効にした構成で Get-ChildItem -Force や rg --files のような読み取り中心のコマンドが止まる場合、表面的には「ファイルアクセス権限の問題」に見えますが、実際には別の層でエラーが起きている可能性が高いです。
今回の事象では、コマンド本体が失敗しているのではなく、Codexが内部的に起動しようとした中間実行プロセス codex-command-runner.exe の起動前段階で CreateProcessWithLogonW failed: 1385 が発生していました。この記事では、この症状の意味、なぜ誤解しやすいのか、どこを見れば切り分けが進むのか、そして今後の対処の考え方までをわかりやすく整理します。
まず押さえたい結論
今回のポイントは非常に明快です。Get-ChildItem や rg --files のような単純な読み取りコマンド自体が悪いわけではありません。問題は、Codex CLIが workspace-write セッションの内部処理として、実コマンド実行前に専用のランナーを起動しようとした時点で失敗していることです。
つまり、見えている失敗は「ワークスペースのファイルが読めない」という話ではなく、「Codex側のWindowsサンドボックス実行レイヤーがプロセス起動に失敗している」ことを示しています。この違いを理解するだけで、調査の方向は大きく変わります。
一般的に、PowerShellで Get-ChildItem -Force が失敗したと聞けば、対象フォルダの権限不足や隠しファイルへのアクセス制限を疑う人が多いはずです。しかし、今回のログでは実コマンドが開始される前にエラーが返されており、Shellの挙動やファイルシステムのACLよりも先に、プロセス生成の仕組みを疑うべき状況です。
発生していた環境の整理
症状が確認された環境は、Windows上でCodex CLIを利用している構成です。利用バージョンは codex-cli 0.118.0、モデルは gpt-5.4、端末は Windows Terminal + PowerShell 7、OSは Microsoft Windows NT 10.0.26100.0 x64 という組み合わせでした。
設定の中でも重要なのは次の部分です。
-
sandbox_mode = "workspace-write" -
approval_policy = "on-failure" -
experimental_windows_sandbox = false -
[windows] sandbox = "elevated"
さらに、対象プロジェクトは trusted として扱われていました。ここで注目すべきなのは、ワークスペースが信頼済みであっても、そして実行しようとしているコマンドが単なる読み取りであっても、Windows側のサンドボックス起動条件に引っかかれば実行前に止まるという点です。
この構図は、日常的にLinuxやmacOSでCLIツールを扱っている人ほど見落としがちです。Windowsでは、ファイル権限だけでなく「そのプロセスをどういう資格情報・権限モデルで起動するか」が別の問題として存在し、今回の1385はまさにそこに関係していると読むのが自然です。
何が起きていたのか
表面上の実行例は非常にシンプルです。
-
Get-ChildItem -Force -
rg --files
どちらもワークスペースの状態を確認する、かなり基本的なコマンドです。しかも書き込みではなく読み取り寄りです。そのため、これらが失敗すると「そんな基本操作すら許可されないのか」と感じてしまいます。
しかしログの読み方を変えると、見え方は一変します。Codexはユーザーが指定したコマンドをそのまま即実行するのではなく、内部で中間ランナーやサンドボックス設定用の補助実行ファイルを起動します。今回のケースでは、その起動段階で CreateProcessWithLogonW failed: 1385 が出ており、コマンド本体に到達していませんでした。
ここが最大の論点です。実際に Get-ChildItem がディレクトリを読みに行って拒否されたわけではありません。rg --files がファイル一覧収集中に例外を起こしたわけでもありません。Codexがそれらを実行するための土台をWindows上に組み立てようとした時点で止まっているのです。
なぜこのエラーは誤解を招くのか
この種の障害が厄介なのは、ユーザーに見える現象と実際の障害点がズレているからです。
ユーザーの視点では、打ち込んだコマンドが失敗したように見えます。しかも対象はワークスペース内の単純な読み取りです。これでは「trusted設定が効いていない」「workspace-writeなのに読み取りすら通らない」「PowerShellとripgrepの相性が悪い」など、さまざまな誤解が生まれます。
ですが、内部ログが示しているのはもっと手前の失敗です。CodexはまずWindows用のサンドボックス補助コンポーネントを呼び出し、その後にコマンドランナーを起動しようとします。ここでプロセス開始処理そのものが成立しないため、ユーザーが意識しているコマンドには一切処理が渡っていません。
この「実コマンド未到達」という事実は非常に重要です。なぜなら、コマンドを変えても再現する可能性が高いからです。Get-ChildItem だけでなく rg --files でも同様に失敗していることは、まさにコマンド個別の問題ではなく、共通の起動経路に問題があることを裏づけています。
error 1385 が意味するものをどう考えるべきか
Windowsで CreateProcessWithLogonW が絡むエラーは、単純な「ファイルがない」「パスが違う」といった種類とは毛色が異なります。名前の通り、プロセスを特定のログオン条件や資格情報に基づいて開始する処理に関係するため、OS側のセキュリティポリシー、ユーザー権限の割り当て、あるいは実行コンテキストの整合性が問題になりやすい領域です。
今回のケースでは、CodexがWindows上で安全にコマンドを実行するための中間レイヤーを立ち上げる際、その開始条件がOSに受け入れられなかったと考えるのが妥当です。とくに sandbox = "elevated" のような設定が関与する場合、通常権限のプロセス起動よりも複雑な前提が増えます。
ここで大切なのは、1385という数字そのものを暗記することではありません。重要なのは、「これはワークスペースのファイル読取失敗ではなく、プロセス生成と権限委譲の境界で起きているエラーだ」と認識することです。この認識があるだけで、無意味なファイルACL調査やプロジェクト設定の見直しに延々と時間を使わずに済みます。
ログから読み取れる本質
今回のログには、切り分けに役立つヒントが複数含まれています。
まず、Codexは pwsh.exe -NoProfile -Command ... という形でPowerShellコマンドを準備しています。ここだけを見ると、PowerShellの実行準備は進んでいるように見えます。しかしその直後に、Windowsサンドボックス関連のセットアップ実行ファイルを起動している痕跡があり、そこから先の流れで問題が発生しています。
ここでの本質は、Codexが単純にPowerShellを直接叩いているのではなく、Windowsサンドボックス構成を踏まえた実行チェーンを組んでいる点です。そのチェーンの途中で codex-command-runner.exe あるいは関連コンポーネントの起動が失敗すれば、最終的にはユーザーが打ったコマンド全体が「失敗した」ように見えます。
つまり、ログを読むときは「どのコマンドが失敗したか」ではなく、「どの層で止まったか」を見る必要があります。今回のように setup、runner、sandbox といった語が並んでいる場合は、ワークスペースの中身よりも先に、実行基盤の状態確認が必要です。
workspace-writeなのに読み取りが失敗する理由
一見すると、workspace-write なら少なくともワークスペース内の読み取りは安全に許されそうに思えます。ところが実際には、ユーザーが期待する「論理的な権限」と、Windows上でその権限を実現する「実装上の起動手段」は別問題です。
Codexの設定で workspace-write が有効でも、それを成立させるために内部で別のプロセスを特定の条件で起動する必要があります。もしその内部プロセスの起動にWindowsが制約をかければ、結果的に読み取りコマンドまで巻き添えで失敗します。
この点は、利用者目線ではかなり直感に反します。なぜなら、権限モデルとしては「読み取り可能」であるにもかかわらず、技術的にはその前提を支える仕組みが成立せず、結果として何も実行できないからです。
そのため、この症状に遭遇した場合は「workspace-writeの概念が壊れている」と考えるより、「workspace-writeを実現するWindows側ランナー起動が失敗している」と理解したほうが正確です。
注目すべき設定項目
今回の情報から、特に確認価値が高いのは以下の観点です。
sandbox_mode の実際の影響
workspace-write は便利ですが、内部的には安全性を保つための補助処理が増えます。Windowsではこの補助処理がLinux系環境より複雑になりやすく、失敗点も増えます。単純な読み取りテストでさえ通らない場合、モード設定とWindowsサンドボックスの相性を最優先で疑う価値があります。
experimental_windows_sandbox の状態
今回の構成では experimental_windows_sandbox = false でした。これ自体が直ちに悪いとは言えませんが、どのサンドボックス経路が使われるのかを把握する材料になります。Windows対応は内部実装の差異が症状を大きく左右しやすいため、同じ「workspace-write」でも実際の挙動は設定の組み合わせ次第で変わります。
windows.sandbox = "elevated"
この設定は特に重要です。elevated という言葉が示す通り、通常より高い権限や異なる起動文脈が絡む可能性があります。Windowsでは、昇格や別資格情報による実行がセキュリティポリシーと衝突すると、見た目以上に早い段階で失敗します。今回の1385は、まさにその種の問題を連想させます。
利用者がやるべき切り分けの考え方
同じような症状に当たった場合、まずやるべきは「コマンドの善し悪し」を疑うことではありません。PowerShellコマンドやripgrepの書き方を変える前に、内部ランナーの起動可否を意識した切り分けに切り替えるべきです。
たとえば、同じセッション内で複数の単純コマンドが一律に失敗するなら、共通実行基盤の障害である可能性が高いと判断できます。逆に特定コマンドだけ失敗するなら、そのコマンド固有の問題を後から検討すれば十分です。今回のように Get-ChildItem -Force と rg --files が同時に落ちるなら、個別コマンド調査は優先度が低くなります。
また、ログ内に START: の直後で runner や sandbox setup の痕跡があるかを確認するのも有効です。これが見えているなら、実行レイヤーは単純ではなく、Codex内部の安全実行機構を経由していると考えられます。そうなれば、問題の中心はワークスペースそのものではなく、Windows上の実行コンテキストです。
この事象が示す本当の教訓
今回のケースは、単なる不具合報告にとどまりません。CLIツールが高度な安全制御を導入するほど、「ユーザーが実行したいコマンド」と「実際にOSへ投げられる内部処理」の間にギャップが生まれることを示しています。
以前なら、ls や dir が失敗したらそのコマンドを疑えばよかったかもしれません。しかし、現代のツールチェーンでは、その前にランナー、サンドボックス、権限制御、ポリシー適用、監査のような多層構造が入ることがあります。すると、表面に見える失敗だけで原因を決めつけると遠回りになります。
今回の1385問題もまさにそれです。表面は「読み取りコマンド失敗」ですが、実態は「Codex内部ランナーの起動失敗」です。この差を見抜けるかどうかで、対応速度も、開発チームへの報告精度も大きく変わります。
まとめ
Windows版Codex CLIで workspace-write を利用中、単純な読み取りコマンドが失敗しても、すぐにファイルアクセス権限の問題と決めつけるべきではありません。今回の事象が示しているのは、コマンド本体の失敗ではなく、codex-command-runner.exe の起動前に CreateProcessWithLogonW failed: 1385 が発生しているという点です。
これは、ワークスペースの中身に触れる以前の段階で、Windows側のプロセス生成・権限モデル・サンドボックス実装のどこかが成立していないことを意味します。したがって、調査の起点は Get-ChildItem や rg --files の内容ではなく、CodexのWindowsサンドボックス設定、内部ランナー起動経路、そして elevated を含む権限実行条件に置くべきです。
一見すると小さなCLIエラーに見えても、実際にはツールの安全実行基盤に関わる問題であることは珍しくありません。今回のようなケースでは、「何のコマンドが落ちたか」よりも「どの層で止まったか」を見抜くことが、最短で本質へたどり着く鍵になります。Windows環境でCodex CLIを安定運用したいなら、この視点は今後ますます重要になっていくはずです。
