3行でいうと

  • MCPは codex mcp add か、config.toml の [mcp_servers.<名前>] で足します。デスクトップアプリとIDE拡張にも、設定画面から足す入口があります。設定はCLI・アプリ・IDEで共有されます。
  • カスタムプロンプトは非推奨で、公式は「スキルを使う」よう書いています。スキルは SKILL.md を置いたフォルダで、$ か /skills で呼べます。
  • 自動化は、画面なしの codex exec、公式のGitHub Action（openai/codex-action@v1）、PRへの @codex review、予定を組む Scheduled（定期実行）、SDKなどがあります。APIキーの置き場所は、公式が繰り返し注意しています。

この記事は、公式ドキュメントを2026年10月22日に読んでまとめたものです。この記事は、実際に使って確かめた記録ではありません。運営者はCodexを入れていますが、使い心地はこの記事には書いていません。コマンドや設定名は公式の表記を写しただけで、動作確認はしていません。公式の文章は要約の形で取得したため、引用は最小限にして、ほとんど言い換えています。

先に結論

前提：用語をそろえる

指示ファイル：AGENTS.md

公式の「Custom instructions with AGENTS.md」によると、読み込みの順は次のとおりです。

  1. Codexのホーム（~/.codex、または CODEX_HOME）で、AGENTS.override.md があればそれ、なければ AGENTS.md。このレベルでは、最初の空でない1つだけが使われます。
  2. プロジェクトのルート（通常はGitのルート）から現在のフォルダまで、各フォルダで AGENTS.override.md、AGENTS.md、project_doc_fallback_filenames の順に探し、フォルダごとに最大1つ。
  3. ルートから近いほうへ順に連結されるので、現在のフォルダに近いファイルが後ろに来て、優先されます。

合計の上限は project_doc_max_bytes で、既定は32 KiBです。確認方法として、codex --ask-for-approval never "Summarize the current instructions." をルートで実行する例が載っています。/init で AGENTS.md の雛形を作る、という説明は、コマンド一覧のページ（スラッシュコマンド）にあります。

MCP：外の道具をつなぐ

公式の「Model Context Protocol」のページ（Extend）から整理します。

足し方

目的 公式の例
手元で起動するサーバー（STDIO）を足す codex mcp add context7 -- npx -y @upstash/context7-mcp
URLのサーバー（Streamable HTTP）をOAuthクライアントつきで足す codex mcp add example --url https://mcp.example.com --oauth-client-id my-client
一覧 codex mcp list
OAuthでログイン codex mcp login <サーバー名>
会話の中で見る /mcp（/mcp verbose でサーバーの詳細、/mcp login <名前> でログイン。後ろ2つはコマンド一覧のページの記載）

デスクトップアプリは Settings → MCP servers → Add server、IDE拡張は歯車のメニュー → MCP servers → Add server で、STDIOかStreamable HTTPを選び、保存して再起動します。

設定ファイルでの書き方

設定は ~/.codex/config.toml、またはプロジェクトの .codex/config.toml（信頼したプロジェクトのみ）の [mcp_servers.<名前>] に書きます。

[mcp_servers.context7]
command = "npx"
args = ["-y", "@upstash/context7-mcp"]

URLのサーバーは url が必須で、bearer_token_env_var（トークンを入れた環境変数の名前）、http_headers、env_http_headers が使えます。ほかの主な項目は次のとおりです。

項目 既定 用途（公式の説明）
startup_timeout_sec 10 サーバーの起動を待つ秒数
tool_timeout_sec 60 ツール1回の実行を待つ秒数
enabled 記載なし false で、消さずに無効化
required 記載なし true で、起動に失敗したらCodexごと失敗
enabled_tools / disabled_tools 記載なし ツールの許可リスト／拒否リスト（拒否は許可のあとに適用）
default_tools_approval_mode 記載なし auto、prompt、writes、approve

安全面の注意（公式の記載）

スキル：手順を覚えさせる

公式の「Build skills」によると、スキルは SKILL.md（必須）を置いたフォルダです。先頭のYAMLに name と description が必須で、description が「いつ使うか」の判断材料になります。任意で scripts/、references/、assets/、agents/openai.yaml を置けます。

置き場所（Codex、公式の表）。

範囲 場所
リポジトリ 起動したフォルダの .agents/skills、親フォルダの .agents/skills、リポジトリのルートの .agents/skills
ユーザー $HOME/.agents/skills
管理者 /etc/codex/skills
システム OpenAI同梱（skill-creatorなど）

呼び方。 明示的には、CLIとIDEで /skills か $ です。暗黙的には、依頼が description に合うとCodexが選びます。agents/openai.yaml の policy.allow_implicit_invocation を false にすると暗黙の呼び出しを止められ、明示的な $スキル名 は使えます。

作り方。 $skill-creator に聞く、フォルダに SKILL.md を作る、Record & Replay（操作を見せて下書きを作らせる）の3通りが書かれています。公式は、スクリプトより指示を優先すること、1つのスキルは1つの仕事に絞ることを勧めています。

無効化。 ~/.codex/config.toml に [[skills.config]] を書き、path と enabled = false を指定し、Codexを再起動します。

注意。 スキルが多いと、説明が短くされ、一部が最初の一覧から外れて警告が出ます。同じ name のスキルは統合されず、両方が選択肢に出ます。スキルの一覧に使う予算は、既定でコンテキストの2%で、skills.max_context_tokens で上限10,000トークンまで変えられます。

カスタムプロンプト：非推奨、スキルへ

公式の「Custom Prompts」のページは、冒頭で「非推奨」と書き、再利用する指示にはスキルを使うよう案内しています。参考までに、書かれている仕様を挙げます。

「カスタムコマンド」をこれから作るなら、公式の案内はスキルです。スラッシュコマンドそのもの（/model、/status など）は組み込みで、一覧は公式の「Slash commands in Codex CLI」にあります。

フック：動きの途中で割り込む

公式の「Hooks」によると、イベントは PreToolUse、PermissionRequest、PostToolUse、UserPromptSubmit、Stop、SessionStart などです。設定は hooks.json か、config.toml の [hooks] で、~/.codex/ とプロジェクトの .codex/ の両方に置けます。ハンドラーの種類は command と mcp_tool が使え、prompt と agent は読み込まれても飛ばされる、と書かれています。

プラグイン

公式の「Plugins」と「Skills & Plugins」によると、プラグインは、スキル、MCPサーバー、ブラウザ拡張、フックをまとめて配るための束です。CLIでは /plugins で一覧を開いて入れます。インストール後は新しいセッションが必要です。IDE拡張ではプラグインに対応していません。ほかに、codex plugin と codex plugin marketplace（導入、一覧、削除、更新）がコマンド一覧に載っています。APIキーでのサインインでは、一部のプラグインが使えません。「Sign in with ChatGPT」は、一部の提携先向けにベータとして展開中、と書かれています。公式の注意は、プラグインのフックはレビューして信頼してから動かすこと、です。

非対話の使い方：codex exec

公式の「Non-interactive mode」から整理します。codex exec は、スクリプトやCI向けに、TUIなしで実行します。進捗は標準エラーに流れ、最後のメッセージだけが標準出力に出ます。

目的 書き方（公式の例または記載）
基本 codex exec "generate release notes for the last 10 commits"
最後の返答をファイルへ --output-last-message（-o <パス>）
JSONの形で受け取る --output-schema <ファイル>
全イベントをJSON Linesで --json
セッションを残さない --ephemeral
前回の続き codex exec resume --last "..."、または codex exec resume <SESSION_ID>
標準入力から読む プロンプトに加えて標準入力に渡した内容は、追加の文脈として使われます。標準入力をプロンプト全体にするなら codex exec -
モデル -m gpt-6.1-sol

権限の既定。 既定のサンドボックスは読み取り専用（read-only）、と書かれています。編集を許すには --sandbox workspace-write です。--full-auto はもうサポートされていません。代わりに --sandbox workspace-write を使うか、承認を自動レビューに回す --approve-for-me を使う、とあります。exec の承認ポリシーの既定は、読んだページには書かれていませんでした。

認証。 保存済みのCLIの認証を再利用します。1回だけAPIキーを渡すなら、CODEX_API_KEY=<キー> codex exec --json "..." の形です。

公式の警告。 - リポジトリが管理するコードを動かすワークフローで、OPENAI_API_KEY や CODEX_API_KEY をジョブ全体の環境変数に置かない。ビルドのスクリプト、テスト、ライフサイクルフックから読まれうるため。 - ChatGPT管理の認証を使うのは、信頼できる実行環境に限る。~/.codex/auth.json はパスワードとして扱い、公開リポジトリやオープンソースでは使わない。 - --skip-git-repo-check は、環境が安全と分かっているときだけ。 - required = true のMCPサーバーが初期化に失敗すると、codex exec はエラーで終了する。 - danger-full-access は、隔離したCIランナーやコンテナのような、制御された環境だけ。

CIでの自動修正の例として、公式は「Codexのジョブは contents: read だけで、パッチを成果物として出す。別のジョブがPRを開く。そのジョブにはAPIキーを渡さない」という分離のパターンを挙げています。

GitHubとの連携

GitHub Action

公式の「Codex GitHub Action」は openai/codex-action@v1 です。CLIを入れ、APIキーを渡したときはResponses APIのプロキシを起動し、codex exec を指定の権限で動かします。主な入力は openai-api-key、prompt か prompt-file、sandbox（workspace-write、read-only、danger-full-access）、model、effort、output-file、safety-strategy などです。

安全に関する公式の記載です。 - safety-strategy の既定は drop-sudo。Codexを動かす前に sudo を外し、ジョブの中では元に戻せません。ほかに unprivileged-user、read-only、unsafe があります。read-only だけで秘密を守ることに頼ってはいけない、とあります。Windowsでは unsafe が必要で、マルチテナントのランナーでは使わない、と書かれています。 - 既定では、書き込み権限のあるユーザーだけが起動できます。 - PR、コミット、Issueの外部入力はプロンプトインジェクションの危険があるので、整えること。Codexはジョブの最後のステップにする。秘密が漏れたかもしれないときは、キーを入れ替える。

GitHubでのコードレビュー

「Review GitHub pull requests with Codex」によると、Codexの設定の「Personal preferences」で「Automatic review」をオンにし、「Review trigger」で実行のタイミングを選びます（リポジトリをつなぐ手順の詳細は読めていません）。手動なら、PRのコメントに @codex review と書きます。Codexは👀で反応し、レビューを投稿します。報告するのはP0とP1の問題だけ、とあります。レビューの方針は AGENTS.md の ## Code Review Rules の節に書けます。公式は「ルールはテストやブランチ保護の代わりにならない」と書いています。

@codex の後ろに「review」以外を書くと、「旧（legacy）のクラウドチャット」が始まります（例：@codex fix the CI failures）。セキュリティレビュー（@codex security review）は、GitHubのページで研究プレビュー（research preview）と書かれている別機能です。Security Reviewのページには、設定の「Auto security review」で自動実行にでき、Enterprise、Business、Edu、Proが対象でPlusは対象外、とあります。

GitLabのマージリクエスト、Slack、Linearとの連携も、公式の一覧にページがありますが、この記事では読んでいません。

Web（クラウド）のCodex

公式の「Codex Cloud」によると、クラウドは、ブラウザ、モバイル、デスクトップアプリから、クラウド上の作業場でタスクを動かします。パソコンがスリープしていても動き続けます。始め方は、ChatGPTにサインインし、環境（environment）を作るか選び、GitHubをつなぎ、リポジトリを選び、公開（Publish）して、タスクを始める、の流れです。

「Cloud environments」のページには、次のことが書かれています。 - 環境の設定は、インストール用スクリプト（Install script）と、サービスの起動と確認用の「Start skill」に記録されます。作ったばかりの環境は「Unpublished」と表示され、公開するまでタスクに使えません。 - インターネットは、環境の設定で「Allow Codex to access internet」をオンにし、許可するドメインを「Package managers」「Custom domains only」「All (unrestricted)」から選びます。ドメインを許可しても、認証情報や権限は与えられません。 - 環境変数はそのままプログラムに渡され、ネットワークのシークレットは、許可したHTTPS先にだけプロキシが実際の値に置き換えます。 - 制限として、コンピューター／ブラウザ操作は非対応、GitLabと自己ホストのGitHub Enterprise Serverも非対応、個人のローカルのスキルは同期されない（リポジトリ内のスキルは使える）、と書かれています。 - タスクはVMで動きます。仮想CPUなどの大きさはプランで違います（PlusとEdu Plusは2 vCPU・8 GiB、Pro、Business、Enterpriseは4 vCPU・16 GiB など）。保存された状態は、最後の操作から7日間まで復元できます。

CLIからは codex cloud（選択画面）、codex cloud exec（タスクの投入）、codex cloud list、最新のクラウド差分を手元に当てる codex apply が、コマンド一覧に載っています。クラウドはChatGPTでのサインインが必要で、APIキーでは使えません（認証のページ）。

予定を組む：Scheduled（スケジュール）

公式の「Scheduled tasks」によると、定期またはイベントで動くタスクを、ChatGPTのWeb・モバイル・デスクトップアプリの「Scheduled」で作って管理します。CLIとIDE拡張には管理画面がなく、プロンプトやスキルを試す場所として使います。時刻指定は、毎日、毎週、RRULE（例：RRULE:FREQ=MONTHLY;BYMONTHDAY=1;BYHOUR=9;BYMINUTE=0）です。イベント起点（Gmail、Slack、GitHubのPR）は、Webとモバイルの対象プランだけで、時刻指定とは併用できません。

安全面では、無人で動くので、いちばん狭い権限から始めること、と公式が書いています。フルアクセスは、確認なしでファイル変更、コマンド実行、ネットワークができるため、リスクが高い、とあります。デスクトップのローカルモードは、編集中のファイルを書き換えうる、とも注意されています。

SDKとアプリサーバー

「Codex SDK」によると、TypeScriptは npm install @openai/codex-sdk（Node.js 18以上）、Pythonは pip install openai-codex（Python 3.10以上）です。PythonのSDKは、ローカルのCodexアプリサーバーをJSON-RPCで制御します。TypeScriptでは codex.startThread() から thread.run(...) で動かし、resumeThread で前のスレッドに戻れます。公式は、独自のクライアントを作るなら、アプリサーバーを勧めています。codex mcp-server は削除済みと書かれ、アプリサーバーに移るよう案内されています。

気をつけること

出典