同じ一文のプロンプトでも、Codex は作業を“サスペンス映画”にしてしまう
プロンプトはたった一文：
このPCの onedrive と関連プロセスのリソース使用状況を確認して
図1～3：Codex（ストーリー重視）
Codex はいきなり真面目に、PowerShell を回す準備をする：Get-Process … *OneDrive* …
ところが即座に盛大にコケる：batch file arguments are invalid
さらに笑えるのが、懲りずに echo hi まで試す——それでも同じエラー。（図1）
そこから“探偵モード”に突入：
- PowerShell と cmd を混同しているのではと疑う
- 特殊文字でパースが壊れているのではと疑う
- 作業ディレクトリ / execpolicy を疑う
- とにかくエラー現場を何度も検証し始める（図1）
最終的なオチは：
「こっちでは実行できないので、あなたが下の大量のコマンドを PowerShell にコピペして実行して、結果を貼ってください」（図2/図3）
つまり：
リソース使用状況を調べてと言ったら、現場で《OneDrive トラブルシューティング手冊》の草案を書いてくれて、作業は結局こっちがやる。
図4：他社（ツール重視）
他社はとても素朴：
コマンドを1本実行 → OneDrive の PID/CPU/メモリを出力 → ついでに要約。（図4）
サスペンスもない、CSI もない、「宇宙が怪しい」もない。
同類の症状：Linux でも同じく“字面に固執”する
ローカルの cliproxyapi ログを見てほしいと言うと、Codex のデフォルト世界観は：
その名前を言ったなら、システム内に 完全一致で存在 しているはずだ。
見つからないとシステムログをあちこち漁り始め、途中で git clone しようとすることすらある……
（私：いや、ログを見たいだけで、あなたのネットサーフィン芸を見たいわけじゃない。）
別の CLI ツールなら普通に：
同名がない → 近い名前/派生名を探す → Docker の中を見る → 終了。
私の推測
Codex の問題はコマンドが書けないことではなく：
「世界は綺麗で、名前は正確で、環境は教科書通りだ」と信じすぎている。
だから、まさにこういうタイプに見える：
- コードを書くのは強い
- でも現場の障害対応だと、1分の作業を1時間の“推理フローチャート”にしてしまう
codexのagent能力補完の提案
- Codex にコードを書かせる
- Codex に「現場運用担当」をやらせる
- どうしてもトラブルシュートに使うなら、プロンプトを runbook 風に書く：
「見つからなければ曖昧検索/派生名確認/systemd確認/Docker確認/関連プロセス列挙……」
