Codexの基本的な使い方とClaude Codeとの違い｜コマンド・設定・併用方法を解説【2026年版】

2台のノートPCでCodexとClaude Codeの連携と比較を表現したイラスト
2026.07.17
\\n\\n\\n
\\n
\\n CODEX × CLAUDE CODE\\n

似ている操作と、間違えやすい設定の違いを整理。2つのAIコーディングエージェントを無理なく併用するための実践ガイドです。

\\n

2026年7月17日時点の公式ドキュメントを基に解説

\\n
\\n\\n

Codexの使い方は、Claude Codeを使ったことがある人なら難しくありません。プロジェクトのフォルダで起動し、自然言語で調査・実装・テストを頼む流れはよく似ています。

\\n\\n

実際、両者には/model、/permissions、/compact、/mcp、/statusなど、同じ名前のコマンドが数多くあります。しかし、プロジェクト指示はCodexがAGENTS.md、Claude CodeがCLAUDE.mdを使い、設定ファイルや権限管理の考え方にも違いがあります。

\\n\\n

この記事では、Codex CLIの基本操作を押さえたうえで、Claude Codeと併用するときに迷いやすいポイントを具体例つきで整理します。

\\n\\n
\\n この記事の結論\\n
    \\n
  • 日常の操作感はかなり近く、Claude Code利用者はCodexへ移行しやすい
    • \\n
  • 同名コマンドでも、対象や保存範囲が同じとは限らない
    • \\n
  • 共通ルールをAGENTS.mdに置き、Claude Codeから読み込むと管理しやすい
    • \\n
  • 同じ作業ツリーを2つのエージェントに同時編集させないことが重要
    • \\n
\\n
\\n\\n

Codexとは？

\\n\\n

Codexは、OpenAIが提供するソフトウェア開発向けのAIエージェントです。ターミナルで動くCodex CLIでは、リポジトリの調査、ファイル編集、コマンド実行、テスト、コードレビューまでを会話形式で依頼できます。

\\n\\n

この記事で扱うのは主にCodex CLIです。Codexにはデスクトップアプリ、IDE拡張、クラウドなど複数の利用画面がありますが、Claude Codeに最も近い操作感なのはターミナル版です。OpenAIの公式説明でも、Codex CLIはローカルリポジトリを調べ、編集し、既存ツールを実行できるターミナル向けエージェントとして案内されています。

\\n\\n
\\n

Codex全体の機能やCLI・アプリ・クラウドの違いは、OpenAI Codexとは？できること・使い方・料金・CLIとの違いで詳しく解説しています。

\\n
\\n\\n

Claude Code経験者が使いやすい理由

\\n\\n

両者は「チャットにコードを書かせるツール」というより、作業環境を確認しながら自律的に手順を進めるエージェントです。基本のサイクルは共通しています。

\\n\\n
    \\n
  1. プロジェクトのファイルを読む
    2. \\n
  2. 変更方針を考える
    3. \\n
  3. 必要なファイルを編集する
    4. \\n
  4. テストやリンターを実行する
    5. \\n
  5. 結果を報告する
    6. \\n
\\n\\n

そのため、Claude Codeで「このエラーの原因を調べて」「実装前に計画を出して」「変更後にテストして」と依頼している人は、ほぼ同じ頼み方をCodexでも使えます。

\\n\\n

Codexの基本的な使い方

\\n\\n

1. Codex CLIをインストールする

\\n\\n

macOSまたはLinuxでは、公式のスタンドアロンインストーラーを利用できます。

\\n\\n 
curl -fsSL https://chatgpt.com/codex/install.sh | sh
\\n\\n

WindowsではPowerShell用インストーラーが用意されています。npmやHomebrewを使う方法もあります。

\\n\\n 
# Windows PowerShell\\npowershell -ExecutionPolicy ByPass -c "irm https://chatgpt.com/codex/install.ps1 | iex"\\n\\n# npmを使う場合\\nnpm install -g @openai/codex\\n\\n# Homebrewを使う場合\\nbrew install --cask codex
\\n\\n

インストール方法は更新されることがあるため、実行前にCodex CLI公式ページも確認してください。

\\n\\n

2. プロジェクトでCodexを起動する

\\n\\n

対象のプロジェクトへ移動して、codexを実行します。初回起動時はChatGPTアカウントなど、表示された方法でログインします。

\\n\\n 
cd /path/to/your-project\\ncodex
\\n\\n

起動後は、やりたいことを日本語で入力するだけです。最初は、変更を伴わない調査から試すと安全です。

\\n\\n 
このプロジェクトの構成と、起動方法を説明してください。\\nまだファイルは変更しないでください。
\\n\\n

3. 具体的なゴールと確認方法を伝える

\\n\\n

「ログイン画面を直して」だけでも動きますが、対象・期待結果・検証方法まで伝えると精度が上がります。

\\n\\n 
ログイン失敗時に画面が白くなる問題を修正してください。\\n\\n条件:\\n- 原因を先に特定する\\n- 既存のエラー表示デザインを使う\\n- 修正後に関連テストを実行する\\n- 最後に変更ファイルとテスト結果を報告する
\\n\\n

4. 最初に覚えたいスラッシュコマンド

\\n\\n
\\n \\n \\n \\n \\n \\n \\n \\n \\n \\n \\n \\n \\n
コマンド用途使うタイミング
/initAGENTS.mdのひな形を作るプロジェクトのルールをCodexへ伝えたいとき
/modelモデルと利用可能な推論レベルを選ぶ速度や精度を切り替えたいとき
/permissionsCodexが確認なしで行える操作を変える読み取り中心、編集許可などを切り替えるとき
/plan計画モードへ切り替える大きな変更の前に方針を確認したいとき
/diff現在のGit差分を表示する編集内容を確認したいとき
/review作業ツリーの変更をレビューするコミット前に不具合やテスト漏れを探すとき
/compact会話を要約してコンテキストを空ける長いセッションを継続したいとき
/statusモデルや権限などの状態を確認する現在の設定が分からなくなったとき
\\n
\\n\\n

5. 安全な基本ワークフロー

\\n\\n
\\n

調査だけ依頼する

最初に「まだ変更しないで」と伝え、影響範囲と原因を把握します。

\\n

計画を確認する

大きな変更では/planを使い、編集対象と検証方法を合意します。

\\n

実装とテストを任せる

変更範囲を明示し、テスト・リンター・ビルドなど必要な確認も依頼します。

\\n

差分をレビューする

/diffと/reviewを使い、人間も内容を確認してからコミットします。

\\n
\\n\\n
\\n

注意: 最初から広い権限を与える必要はありません。慣れるまでは読み取り中心で調査し、必要な操作だけ承認する運用が安全です。

\\n
\\n\\n

6. codex execで非対話実行する

\\n\\n

対話画面を開かず、スクリプトやCIから実行したい場合はcodex execを使います。

\\n\\n 
codex exec "リポジトリ構成を要約し、リスクが高い箇所を5つ挙げてください"
\\n\\n

公式ドキュメントによると、codex execは標準では読み取り専用サンドボックスで動作します。ファイル編集が必要な自動処理では、実行環境を確認したうえで--sandbox workspace-writeを明示します。

\\n\\n

CodexとClaude Codeの共通点・違い

\\n\\n

両者は操作感が近い一方、永続設定の置き場所とコマンドの細かな意味が異なります。まずは全体像を比較します。

\\n\\n
\\n \\n \\n \\n \\n \\n \\n \\n \\n \\n \\n \\n \\n \\n
項目CodexClaude Code
対話モードの起動codexclaude
非対話実行codex exec "指示"claude -p "指示"
プロジェクト指示AGENTS.mdCLAUDE.md
個人設定~/.codex/config.toml~/.claude/settings.json
共有プロジェクト設定.codex/config.toml.claude/settings.json
個人用プロジェクト設定個人プロファイルや上位設定を利用.claude/settings.local.json
権限の主な考え方サンドボックスと承認ポリシーpermission modeとallow・ask・denyルール
MCP対応。Codex側で設定対応。Claude Code側で設定
繰り返し手順Skills・PluginsなどSkills・Pluginsなど
\\n
\\n\\n

最大の違いはAGENTS.mdとCLAUDE.md

\\n\\n

Codexは作業開始前にAGENTS.mdを読みます。グローバル設定からプロジェクトルート、現在の作業ディレクトリまでを順に探索し、現在地に近い指示ほど後から連結されるため優先されます。AGENTS.override.mdを使った上書きも可能です。

\\n\\n

Claude CodeはCLAUDE.mdを使います。ユーザー共通の~/.claude/CLAUDE.md、プロジェクトのCLAUDE.mdまたは.claude/CLAUDE.md、個人用のCLAUDE.local.mdなどを読み込みます。

\\n\\n
\\n

重要: Claude Codeは標準ではAGENTS.mdを直接読みません。ただし、CLAUDE.mdに@AGENTS.mdと書けば内容をインポートできます。

\\n
\\n\\n

CLAUDE.mdの設計を詳しく知りたい方は、CLAUDE.mdの書き方完全ガイドも参考にしてください。

\\n\\n

設定ファイルはTOMLとJSON

\\n\\n

Codexの個人設定は~/.codex/config.toml、プロジェクト設定は.codex/config.tomlです。モデル、承認ポリシー、サンドボックス、MCPなどを設定できます。プロジェクト設定は、信頼したプロジェクトでのみ読み込まれます。

\\n\\n 
# .codex/config.toml の例\\nsandbox_mode = "workspace-write"\\napproval_policy = "on-request"
\\n\\n

Claude CodeはJSON形式です。チーム共有は.claude/settings.json、端末固有の設定は.claude/settings.local.jsonに分けられます。権限、環境変数、Hooks、プラグインなどを設定できます。

\\n\\n

Claude Code側の設定例は、Claude Codeのsettings.json完全ガイドで詳しく紹介しています。

\\n\\n

同名コマンドでも動作は同じとは限らない

\\n\\n
\\n \\n \\n \\n \\n \\n \\n \\n \\n \\n \\n \\n \\n
共通コマンドCodexClaude Code覚えておきたい差
/initAGENTS.mdを生成CLAUDE.mdを生成生成する指示ファイルが違う
/model現在のモデルと推論レベルを選択モデルを切り替え、通常は新規セッションの既定値にも保存Claude Codeでは保存範囲を確認する
/permissionsAutoやRead Onlyなど承認プリセットを変更allow・ask・denyルールや作業ディレクトリを管理設定画面の対象が異なる
/review主に現在の作業ツリーをレビュー現在の公式仕様ではGitHub PRの単発レビューClaude Codeでローカル差分を深く見るなら/code-reviewも候補
/mcp接続済みMCPツールや診断情報を確認接続一覧に加えて再接続・有効化・無効化・認証を管理管理機能の範囲が違う
/compact会話を要約して空きを作る会話を要約して空きを作る目的はほぼ同じ
/plan計画モードへ切り替える計画モードへ切り替える目的は近い
/statusセッション設定を確認バージョン・モデル・アカウント・接続を確認表示項目は異なる
\\n
\\n\\n

バージョンやプランによって表示されるコマンドは変わることがあります。暗記するより、セッション内で/を入力して候補を確認するのが確実です。

\\n\\n

権限管理の設計思想が違う

\\n\\n

Codexは、ファイルやネットワークへどこまでアクセスできるかを決めるサンドボックスと、サンドボックス外の操作をいつ確認するか決める承認ポリシーを分けて考えます。

\\n\\n

Claude Codeでは、permission modeとツール単位のallow・ask・denyルールが中心です。たとえば、テストコマンドは許可し、.envの読み取りや危険なコマンドは拒否する、といった指定ができます。

\\n\\n

どちらも「確認を減らせば便利」というだけではありません。対象リポジトリ、扱う秘密情報、コマンドの影響範囲を見て、必要最小限の権限にすることが基本です。

\\n\\n

CodexとClaude Codeをハイブリッドで使う方法

\\n\\n

共通ルールをAGENTS.mdにまとめる

\\n\\n

2つを併用するなら、同じルールをAGENTS.mdとCLAUDE.mdへ重複して書くより、共通部分を1か所にまとめる方が保守しやすくなります。

\\n\\n

おすすめは、AGENTS.mdを共通ルールの本体にして、Claude CodeのCLAUDE.mdから読み込む構成です。

\\n\\n
your-project/\\n├── AGENTS.md\\n├── CLAUDE.md\\n├── .codex/\\n│ └── config.toml\\n└── .claude/\\n ├── settings.json\\n └── settings.local.json
\\n\\n

AGENTS.mdには、両方のエージェントに守ってほしいルールを書きます。

\\n\\n 
# Repository Guidelines\\n\\n## Commands\\n- Install dependencies with `pnpm install`.\\n- Run `pnpm lint` and `pnpm test` after code changes.\\n\\n## Development rules\\n- Reuse existing components before adding a new one.\\n- Do not edit generated files directly.\\n- Never commit `.env` files or credentials.\\n\\n## Completion criteria\\n- Report changed files and verification results.\\n- Mention any test that could not be run.
\\n\\n

CLAUDE.mdでは最初に共通ルールを読み込み、その下へClaude Code固有の内容だけを追加します。

\\n\\n 
@AGENTS.md\\n\\n## Claude Code specific\\n- Use plan mode before changes spanning multiple packages.\\n- Put personal machine settings in `.claude/settings.local.json`.
\\n\\n

この方法はAnthropicの公式ドキュメントでも案内されています。シンボリックリンクも使えますが、Claude Code固有ルールを追加でき、Windowsでも扱いやすいインポート方式が実用的です。

\\n\\n

ツール固有の設定は混ぜない

\\n\\n

AGENTS.mdには「何を守るか」を書き、権限やMCPなどの機械的な設定は各ツールの設定ファイルへ分けます。

\\n\\n
\\n \\n \\n \\n \\n \\n \\n \\n \\n \\n
内容置き場所
テストコマンド、コード規約、完了条件AGENTS.md
Claude Codeだけに必要な補足CLAUDE.md
Codexのモデル、サンドボックス、承認.codex/config.toml
Claude Codeの権限、Hooks、プラグイン.claude/settings.json
自分のPCだけで使うClaude Code設定.claude/settings.local.json
\\n
\\n\\n

1つを実装担当、もう1つをレビュー担当にする

\\n\\n

最も始めやすい併用方法は、同じファイルを同時に編集させるのではなく、役割を分けることです。

\\n\\n
\\n

Claude CodeまたはCodexで実装する

片方だけにファイル編集を任せ、テストまで完了させます。

\\n

Git差分を確定する

git diffを確認し、必要ならコミットしてレビュー対象を固定します。

\\n

もう片方にレビューを依頼する

仕様漏れ、回帰、不足テスト、複雑化など、観点を指定して確認します。

\\n

指摘を採用するか人間が判断する

レビュー結果をそのまま適用せず、根拠と影響範囲を確認します。

\\n
\\n\\n
\\n

同時編集は避ける: CodexとClaude Codeを同じ作業ツリーで同時に動かすと、一方が読んだ直後にもう一方がファイルを書き換え、変更の上書きやテスト結果の食い違いが起きます。並列化するなら、別ブランチまたはGit worktreeで作業領域を分離してください。

\\n
\\n\\n

作業内容で使い分ける

\\n\\n

どちらが常に優れているかではなく、利用できるモデル、契約プラン、既存の設定、作業内容で選ぶのが現実的です。

\\n\\n
    \\n
  • 普段の実装: 対象プロジェクトで設定が整っている方を使う
    • \\n
  • 難しい設計: 両方に独立して案を出させ、前提とトレードオフを比較する
    • \\n
  • コードレビュー: 実装に使っていない方をセカンドレビューに使う
    • \\n
  • 自動処理: Codexはcodex exec、Claude Codeはclaude -pでスクリプトへ組み込む
    • \\n
  • MCP連携: 同じサーバーを使う場合も、接続設定と認証はそれぞれで確認する
    • \\n
\\n\\n

よくある質問

\\n\\n
\\n
\\n

CodexはCLAUDE.mdを自動で読みますか？

\\n

標準のプロジェクト指示ファイルはAGENTS.mdです。Codexのproject_doc_fallback_filenamesへCLAUDE.mdを追加する方法はありますが、両方を併用するなら、共通ルールをAGENTS.mdへ置く方が分かりやすいでしょう。

\\n
\\n
\\n

Claude CodeはAGENTS.mdを自動で読みますか？

\\n

自動では読みません。CLAUDE.mdに@AGENTS.mdと書いてインポートするか、必要に応じてシンボリックリンクを使います。

\\n
\\n
\\n

同じスラッシュコマンドなら動作も同じですか？

\\n

同じとは限りません。特に/init、/permissions、/review、/modelは対象や保存範囲に違いがあります。実行前に候補画面の説明を確認してください。

\\n
\\n
\\n

同じMCPサーバーを両方で使えますか？

\\n

サーバー側が対応する一般的なMCP接続であれば、両方から利用できる場合があります。ただし、CodexとClaude Codeでは設定の保存場所が異なるため、それぞれで接続・環境変数・OAuth認証を設定します。

\\n
\\n
\\n

どちらか1つに絞るべきですか？

\\n

必須ではありません。日常作業は1つに寄せつつ、難しい設計やレビューで別のモデルを使うと、設定管理を複雑にしすぎずに両方の強みを活かせます。

\\n
\\n
\\n\\n

まとめ

\\n\\n

Codexの基本的な使い方は、プロジェクトでcodexを起動し、自然言語で調査・編集・テストを依頼することです。Claude Codeと操作感は近く、/modelや/compactなど共通するコマンドも多いため、すでにClaude Codeを使っている人なら短時間で慣れられます。

\\n\\n

一方で、AGENTS.mdとCLAUDE.md、config.tomlとsettings.json、権限管理、同名コマンドの動作には違いがあります。名前が同じだから同じ設定だと思い込まないことが大切です。

\\n\\n

ハイブリッド運用では、共通ルールをAGENTS.mdへ集約し、Claude CodeのCLAUDE.mdから読み込む構成が管理しやすい方法です。実装とレビューで役割を分ければ、作業の衝突を避けながら異なるモデルの視点を活用できます。

\\n\\n
\\n

次は、Claude CodeのAuto Modeと権限設定や、Codexのサブエージェント活用ガイドもあわせて確認すると、より安全に自動化を進められます。

\\n
\\n\\n

参考にした公式情報

\\n \\n
\\n\n1114\tcodex%e3%81%a7%e8%87%aa%e5%8b%95%e6%89%bf%e8%aa%8d%ef%bc%88automode%ef%bc%89%e3%82%92%e8%a8%ad%e5%ae%9a%e3%81%99%e3%82%8b%e6%96%b9%e6%b3%95%ef%bd%9capproval_policy%e3%81%a8sandbox%e3%81%ae%e5%ae%89\t\\n
\\n\\n\\n\\n
\\n
\\nCodex 設定ガイド\\n

Codexで自動承認（automode）を設定する方法｜approval_policyとsandboxの安全な組み合わせ

\\n

Codexに毎回「実行していい？」と聞かれるのを止めたい——そんなときに使うのが承認ポリシー（approval_policy）とサンドボックス（sandbox_mode）の設定です。この記事では、2つの設定の関係、目的別の安全なレシピ、config.tomlへの恒久設定、そして「やってはいけない全解除」までを、2026年7月時点の公式リファレンスに基づいて解説します。

\\n
\\n
\\n\\n
\\n【2026年7月30日 追記】Auto-reviewが利用できます\\n

現在の公式ドキュメントでは、標準のAutoプリセットはworkspace-write＋on-requestです。さらにapprovals_reviewer = "auto_review"を設定すると、サンドボックス外の操作などに必要な承認を専用のレビューワーAIへ審査させられます。権限を広げずに承認待ちを減らしたい場合は、Codex Auto-reviewの設定方法とAuto Modeとの違いをご覧ください。

\\n
\\n\\n
\\n

関連記事

\\n\\n
\\n\\n
\\n

Codexの「自動承認」は2つの設定の組み合わせ

\\n

Claude Codeの「Auto Mode」のようなひとつのスイッチを探すと迷子になります。Codexの自動化は、役割の違う2つの設定を組み合わせて作ります。

\\n\\n\\n\\n\\n\\n\\n\\n\\n\\n
設定役割例えるなら
approval_policyCodexが作業前に人間に確認を取るかを決める「上司への確認の頻度」
sandbox_mode確認なしで動くとき、どこまでの操作を物理的に許すかを決める「渡す鍵の範囲」
\\n\\n

つまり「確認を減らす（approval）」と「動ける範囲を絞る（sandbox）」はセットで考えるものです。確認を切るならその分サンドボックスを狭くする——これがCodex自動化の基本原則です。

\\n
\\n\\n
\\n

approval_policy：3つの値と非推奨になった値

\\n\\n\\n\\n\\n\\n\\n\\n\\n\\n\\n
値動作向いている場面
untrusted安全と分かっている読み取り系のみ自動実行。状態を変更するコマンドは毎回承認を求める初めてのリポジトリ・信頼できないコード
on-requestサンドボックスの範囲内は自動実行し、範囲を超える操作（ワークスペース外の編集・ネットワークアクセス等）のときだけ承認を求める。Git管理下フォルダでのデフォルト日常の開発作業
never承認プロンプトを完全に無効化。ただしサンドボックス制限は生きたまま定型作業の自動化・CI・バッチ実行
\\n\\n
\\n⚠ 「on-failure」は非推奨になりました\\n

古い解説記事でよく見るapproval_policy = "on-failure"は、現在の公式リファレンスで非推奨（deprecated）とされています。対話利用ならon-request、非対話の自動実行ならneverに置き換えてください。codex exec --full-autoも非推奨の互換パスとして残っていますが警告が表示されるため、本記事では現行の指定方法（--ask-for-approval＋--sandbox）を使います。

\\n
\\n\\n

現在の公式ドキュメントで「Auto」と呼ばれる標準プリセットは、approval_policy = "on-request"＋sandbox_mode = "workspace-write"です。確認プロンプトを完全になくすnever＋workspace-writeは非対話向けの別設定です。承認依頼を専用AIに審査させる場合は、Auto-reviewを使います。

\\n
\\n\\n
\\n

sandbox_mode：動ける範囲を決める3つの値

\\n\\n\\n\\n\\n\\n\\n\\n\\n\\n\\n
値できることリスク
read-onlyファイルの読み取りのみ。書き込み・実行系は承認が必要最小
workspace-write作業ディレクトリ（ワークスペース）内の読み書き。外への書き込みやネットワークは原則ブロック小〜中
danger-full-accessサンドボックス制限なし。システム全体に書き込み可能大
\\n\\n

ネットワークアクセスは独立した設定になっており、workspace-writeのまま必要なときだけ開けられます。

\\n\\n
# ~/.codex/config.toml\\nsandbox_mode = "workspace-write"\\n\\n[sandbox_workspace_write]\\nnetwork_access = true   # npm install などが必要な場合のみ true
\\n
\\n\\n
\\n

目的別レシピ：この組み合わせを使えばいい

\\n\\n

レシピ①：日常開発の「ちょうどいい自動化」（推奨）

\\n
codex --ask-for-approval on-request --sandbox workspace-write
\\n

ワークスペース内の編集・実行は確認なしで進み、範囲を超える操作のときだけ聞いてきます。Git管理下ではこれがデフォルト相当なので、まずはこの挙動を基準にしましょう。

\\n\\n

レシピ②：確認プロンプトなしの非対話設定（Autoプリセットとは別）

\\n
codex --ask-for-approval never --sandbox workspace-write
\\n

承認プロンプトは出なくなりますが、サンドボックスが生きているため、範囲外の操作は自動承認ではなくブロックされます。人間の代わりに境界外操作を審査させたい場合は、on-requestとapprovals_reviewer = "auto_review"を組み合わせてください。

\\n\\n

レシピ③：調査専用の読み取りモード

\\n
codex --ask-for-approval never --sandbox read-only
\\n

コードベースの調査・レビュー・説明をさせるだけなら、書き込み権限自体を渡さないのが最も安全です。確認なしでもファイルは一切変更されません。

\\n\\n

レシピ④：CI・バッチでの非対話実行

\\n
codex exec --ask-for-approval never --sandbox workspace-write "テストを実行して失敗を修正して"
\\n

CIパイプラインなど人間が承認ボタンを押せない環境ではneverが前提になります。実行後は必ず差分をレビューしてからマージしてください。

\\n\\n
\\n✕ やってはいけない：全解除フラグ\\n

--dangerously-bypass-approvals-and-sandbox（別名--yolo）は、承認もサンドボックスも同時に無効化します。公式ドキュメント自身が「サンドボックスなし・承認なし（非推奨）」と明記している設定で、AIの誤操作がシステム全体に及びます。使い捨てのコンテナ・VM内など、壊れても困らない隔離環境以外では使わないでください。通常の自動化では、標準のAutoプリセットまたはAuto-reviewを使い、全解除は避けてください。

\\n
\\n
\\n\\n
\\n

config.tomlで恒久設定にする

\\n

毎回フラグを付けるのが面倒になったら、~/.codex/config.tomlに書いておきます。

\\n\\n
# ~/.codex/config.toml\\napproval_policy = "on-request"     # 日常のデフォルト\\nsandbox_mode = "workspace-write"\\n\\n[sandbox_workspace_write]\\nnetwork_access = false
\\n\\n

「普段は確認あり、自動化タスクのときだけ確認なし」を切り替えたい場合は、プロファイル（別ファイルの設定）を用意して--profileで切り替えるのが便利です。プロファイルは環境名（dev・ci など）で命名するのが定石です。

\\n\\n
# ~/.codex/auto.config.toml（自動化用プロファイル）\\napproval_policy = "never"\\nsandbox_mode = "workspace-write"\\n\\n# 実行時\\ncodex --profile auto "リンタ警告を全部直して"
\\n\\n

セッションの途中で切り替えたい場合は、対話画面（TUI）で/approvalsコマンドを使うと、その場で承認モードを変更できます。「最初は確認ありで様子を見て、信頼できたら残りは自動で」という運用ができます。

\\n
\\n\\n
\\n

安全に運用するための3原則

\\n
    \\n
  1. Git管理下でだけ自動承認を使う：何が変更されたかをgit diffで必ず確認でき、いつでも巻き戻せる状態が前提です。Git管理外のフォルダでneverを使うのはやめましょう
    2. \\n
  2. ネットワークはデフォルト閉じる：network_access = falseを基本にし、パッケージインストールが必要なタスクのときだけ開ける。自動実行中の意図しない外部通信を防げます
    3. \\n
  3. 自動実行の結果は人間がレビューする：承認を省略するのは「作業中の確認」であって「成果物の検収」ではありません。差分レビュー→コミットの流れは維持してください
    4. \\n
\\n\\n
\\nℹ Claude Codeユーザーの方へ\\n

Claude Codeの自動承認（Auto Mode・permission mode）に相当する仕組みの比較で言うと、Codexのon-requestがClaude Codeの通常モード＋acceptEdits的な立ち位置、never＋workspace-writeがAuto Mode相当、--yoloがbypassPermissions相当です。Claude Code側の設定はAuto Modeの設定ガイドをご覧ください。

\\n
\\n
\\n\\n
\\n

よくある質問

\\n\\n
\\n

Q. 設定しても承認を求められることがあるのはなぜですか？

\\n

on-requestはサンドボックスの範囲を超える操作（ワークスペース外への書き込み、ネットワークアクセスなど）のときに承認を求める設計です。確認を完全になくしたい場合はapproval_policy = "never"にしますが、その場合サンドボックス外の操作は承認ではなく「ブロック」になります。

\\n
\\n\\n
\\n

Q. 「–full-auto」や「on-failure」を紹介している記事を見ましたが使えますか？

\\n

on-failureは現在の公式リファレンスで非推奨とされており、on-request（対話）またはnever（非対話）への置き換えが案内されています。codex exec --full-autoも非推奨の互換パスとして残っていますが警告が表示されるため、本記事のレシピ（--ask-for-approval＋--sandboxの明示指定）を使うのが確実です。

\\n
\\n\\n
\\n

Q. –yoloを使えばいちばん速いのでは？

\\n

速さは変わりません。never＋workspace-writeでも承認プロンプトは一切出ないので、体感速度は同じです。違うのは事故ったときの被害範囲だけです（ワークスペース内 vs システム全体）。隔離されたコンテナ内でない限り、--yoloを選ぶ理由はほぼありません。

\\n
\\n\\n
\\n

Q. IDE拡張やCodex Cloudでも同じ設定ですか？

\\n

この記事はCodex CLI（ターミナル）の設定を扱っています。IDE拡張にも承認の概念はありますが、UIからモードを選択する形になります。クラウド実行（Codex Cloud）はそもそも隔離環境で動くため、承認まわりの考え方が異なります。

\\n
\\n
\\n\\n
\\n

手元のPCをスマホから操作したい場合は、専用の機能が用意されています。設定手順はCodex Remoteの使い方完全ガイドをご覧ください。

表計算の自動化から始めたい場合はCodexやClaudeでGoogleスプレッドシートを操作する方法をご覧ください。

まとめ

\\n
\\n✓ この記事のポイント\\n
    \\n
  • Codexの自動承認はapproval_policy（確認の頻度）×sandbox_mode（動ける範囲）の組み合わせで作る
    • \\n
  • 公式のAutoプリセットはon-request＋workspace-write。承認をAIへ任せる場合はapprovals_reviewer = "auto_review"を追加する
    • \\n
  • on-failureは非推奨。on-requestかneverに置き換える
    • \\n
  • --yolo（全解除）は隔離環境専用。速度はneverと変わらないのにリスクだけ増える
    • \\n
  • 恒久化はconfig.toml、使い分けはプロファイル、セッション中の変更は/approvals
    • \\n
\\n
\\n

まずはレシピ②（codex --ask-for-approval never --sandbox workspace-write）を、Git管理下の小さなタスクで試してみてください。「確認なしなのに安全」の感覚が掴めるはずです。

\\n
\\n\\n
\\n

本記事の情報は2026年7月時点のCodex公式ドキュメント（設定リファレンス・Agent approvals & security）に基づきます。仕様は変更される場合があるため、最新情報は公式ドキュメントをご確認ください。

\\n
\\n\\n\\n
\\n
タイトルとURLをコピーしました