最初は、ブラウザ操作やComputer Useのような新しい機能だけの問題だと思っていました。それなら多少動かなくても許容できます。
でも実際につらくなったのは、コードを書くために必要なコマンド実行までsandboxの影響を受けるようになったことでした。ビルドする。テストする。Gitを操作する。コーディングエージェントとして一番普通に使いたい部分で引っかかると、使い続けるのがしんどくなります。
最終的に、WindowsネイティブではいったんClaude中心へ戻しました。
- Windowsネイティブ版Codexは、
[windows] sandboxの設定次第でブラウザ操作だけでなく通常のコマンド実行も不安定になった - GitHubに同種の報告が複数あり、自分の環境だけの問題ではなさそう
- WindowsではいったんClaudeへ戻し、CodexはWSL・Macで使う。Windows版が安定したらまた使う
- ただしClaude側も2026年9月のWindows Updateで障害が出ており、「Claudeなら無傷」ではない
WindowsネイティブでCodexを使いたかった
私は普段Windowsをかなり使っています。WSLも使いますが、Windowsネイティブで動くツールなら、そのままWindowsで使いたい。
Codexは最近、コードを生成するだけのツールではなくなっています。ローカルのファイルを読み、コマンドを実行し、Gitを触り、必要ならブラウザも操作する。そこにChatGPT側のリサーチ能力や画像生成も加わります。
- コードを書く
- 技術情報を調べる
- READMEやブログ用の画像を作る
このあたりまで同じ環境で完結できるなら、かなり便利です。実際、しばらくCodex中心へ寄せようとしていました。
最初は自分の設定がおかしいと思った
私が使っていたのはCodex Desktop（Windowsネイティブ版）です。Windows版Codexにはsandboxがあります。sandboxは、AIが実行するコマンドの書き込み先やネットワークをOS側で制限する仕組みです。Windows版には、管理者権限でセットアップする elevated と、権限なしで動く unelevated の2モードがあり、公式ドキュメントは elevated を推奨、unelevated はそれが使えないときの代替としています。
私がまず試したのが、config.toml の設定を unelevated へ変えることでした。
[windows]
sandbox = "unelevated"ところが、ブラウザ操作が立ち上がりません。
この時点では「BrowserかComputer Useだけの問題かな」くらいに考えていました。ブラウザ操作は便利ですが、私がCodexを使う主目的はコードを書くことです。そこが動けば、しばらくは我慢できます。
問題は、その後でした。
コマンド実行まで怪しくなると話が変わる
🔧 環境: Windows 11 / Codex Desktop 🔧バージョン / [windows] sandbox = "unelevated"
> go test ./...
🔧 実際のエラー文をここに。無ければこのブロックごと削除Codexでコードを書くとき、AIが文章としてコードを返すだけなら、それほど問題にはなりません。実際の開発では、その先があります。
go test ./... を実行する。ビルドする。Gitの状態を見る。生成したファイルを確認する。エラーが出たら修正して、もう一度コマンドを実行する。この繰り返しがコーディングエージェントの便利なところです。
ところがWindows sandboxまわりの問題が出てくると、この通常のコマンド実行まで安心して任せにくくなりました。
私の症状に一番近い外部報告は openai/codex#35070 です。unelevated のsandboxが子プロセスの生成を spawn EPERM で拒否し、next build やesbuildのようにワーカーを起動するツールチェーンが動かない、という内容です。ビルドやテストのコマンドはこの種の子プロセス生成を普通に行うので、そこで引っかかると開発ツールとしては使えません。
ブラウザが動かないだけなら「まだ新機能だから仕方ない」で済みます。でも、コードを書くための基本動作までsandboxの状態を気にしながら使わないといけないとなると、ストレスが一気に増えます。私がCodexからいったん離れた一番の理由はここです。
elevatedは、思っていたより複雑だった
設定を見直す中で、公式が推奨する elevated も調べました。
[windows]
sandbox = "elevated"
sandbox_private_desktop = falseOpenAIは2026年5月、Windows sandboxの仕組みをエンジニアリングブログで説明しています。Windowsには他OSのSeatbeltやbubblewrapに相当する隔離機能がないため、CodexSandboxOffline / CodexSandboxOnline という専用ローカルユーザーを作り、制限付きトークン、ACL、Windows Firewallを組み合わせてAIが実行するプロセスを隔離している、という内容です。
単に「管理者権限を付けるかどうか」という話ではありません。AIにはコードを実行してほしい。でも何でも自由に実行されては困る。その境界をWindows上で作っているわけです。仕組みを読むと、難しいのも分かります。ただ、利用者としては毎回そこまで意識したくありません。
GitHubを見たら、自分だけではなかった
しばらく自分のPCや設定を疑っていましたが、途中からCodex側のissueも調べました。すると、Windowsのsandbox関連でかなり近い報告が複数ありました。
- #25280 —
elevatedのセットアップがsetup refresh failedで失敗し、unelevatedにするとgit statusなどが通るようになる - #29622 —
elevatedにするとCodex Desktopが起動できなくなり、unelevatedに戻すと直る - #23712 —
unelevatedにしているのに、コマンドのたびにelevatedセットアップのUACプロンプトが出る
いずれも2026年5〜7月に立ち、この記事を書いている時点でOpenのままです。環境ごとに症状は違うので、私の環境と同じ原因だとは断定できません。ただ、「Windows版Codexのsandboxまわりで困っているのは自分だけではない」ことは分かりました。
これは結構大きかったです。それまでは「自分のWindows設定が変なのでは」と思って何度も見直していました。でも同じ時期に似た問題が複数出ているなら、設定を延々と触り続けても仕方ありません。
unelevated へ変更して改善する報告もあれば、一部の機能だけ動くようになる例もあります。私の環境でも、ブラウザ操作は立ち上がりませんでした。そして私が欲しいのは「一部の機能が動く状態」ではなく、コードを書いて、コマンドを実行して、テストして、修正する、その基本部分を普通に任せられる状態です。
Codexを使うためにCodexを直す時間が増えてきた
ここまで来ると、目的と手段が逆転してきます。本来やりたかったのはCodexを使ってコードを書くことです。でも実際にやっていたのは、
- sandbox設定を調べる
elevatedとunelevatedを切り替える- 権限を確認する
- Browserとの関係を調べる
- GitHub issueを読む
という作業でした。
こういう調査自体は嫌いではありません。でも開発したいときに毎回やりたいわけでもありません。AIコーディングエージェントは自分の作業を減らすために使っています。そのAIを動かすための調査時間が増えてきたら、いったん別のものを使ったほうがいい。そう判断しました。
いったんClaudeへ戻した。ただしClaudeも無傷ではない
そこで、Windowsネイティブでの普段使いはいったんClaude中心へ戻しました。ChatGPTもCodex中心で使う前提なら上位プランを考えていましたが、そこまで寄せる必要はないと判断してPlusへ戻しています。
Codexを使わなくなったわけではありません。WSLやMacなら引き続き候補です。Windows版もアップデートで改善すれば、また使います。「Codexが駄目だった」というより、「Windowsネイティブで今使うには少ししんどかった」という評価です。
ただ、「ClaudeならWindowsで問題ない」と書くと、それも正確ではありません。
2026年9月8日のWindows Update以降、Claude CoworkのWindows版がローカルコマンドを実行できなくなる障害が公式に案内されています。この記事を書いている時点でステータスは「Identified」のままで、Microsoftが修正を開発中とのことです。
つまり、Windows上でローカルPCをAIに操作させる難しさはCodexだけの問題ではありません。OpenAIもAnthropicも、それぞれ違う方法でWindowsのsandboxや仮想環境と格闘しています。それでも今の私の用途では、Claudeのほうが摩擦が少なかった。だから戻した。それだけです。
Windowsでは「コードが生成できる」だけでは足りない
今回改めて思ったのは、コーディングエージェントに必要なのはモデル性能だけではないということです。
- コマンドが安定して動く
- ファイルを読み書きできる
- Gitを操作できる
- ビルドできる
- テストできる
- 権限問題で頻繁に止まらない
むしろ普段使いではこちらのほうが効きます。モデルが賢くても、go test ./... を毎回安心して任せられないなら、開発体験としてはかなりつらい。今回そこを実感しました。
それでもCodexは惜しい。当面は使い分ける
ここまで書くとCodexにかなり不満があるように見えるかもしれません。実際には逆で、かなり惜しいと思っています。機能が足りなくて離れたのではなく、機能はむしろ十分あるのに、Windows上の基礎部分で引っかかってしまった。
今回、Codexでコードを書こうとしたところから始まって、気がつけばWindowsのsandbox、ACL、専用ユーザー、権限、GitHub issueまで調べていました。さらにClaude側でも、Windows UpdateでCoworkのローカル実行が壊れる問題が出ています。AIがPCを直接操作するようになって、Windowsの複雑な部分が表に出てきたのだと思います。
CodexもClaudeも、そのうちここは改善していくと思います。数か月後に「こんなsandbox問題で困っていたのか」と笑えるくらいになっていればありがたいです。
それまでは、無理に一つへ統一せず、
- WindowsではClaude
- 必要に応じてWSLやMacでCodex
- ChatGPTはリサーチや画像生成にも使う
そのくらいの使い分けでいこうと思っています。
コメント