CodexをVS Codeで使う【2026年9月版】拡張機能の導入・設定・運用ガイド

VS CodeでCodexを使いたいとき、実際につまずくのは「インストールの手順」ではありません。拡張機能の検索結果に似た名前が並んでどれが公式か判断できない、入れたのにサイドバーに出てこない、設定を調べてもconfig.tomlの話とVS Codeの設定の話が混ざっていて噛み合わない、といった場所です。

本記事は、Codex VSCode拡張（正式名称は Codex IDE extension）を「VS Codeから使うときの導入・設定・日常運用」に絞って整理します。記載する拡張機能名・ID・動作要件・設定キー・コマンドは、2026年9月2日時点のOpenAI公式ドキュメントと、Marketplaceが配布している拡張機能そのもののマニフェストで確認しています。

この記事の要点（Key Takeaways）

• 拡張機能のIDは openai.chatgpt。表示名は「Codex – OpenAI’s coding agent」だが内部名は chatgpt で、発行元 OpenAI はドメイン認証済み。ここを確認すれば偽物を避けられる
• VS Code 1.96.2 以上が必須（拡張機能のマニフェストの engines.vscode が ^1.96.2）。「Marketplaceで見つからない」の原因はここにあることが多い
• Codex CLIを別途インストールする必要はない。拡張機能はCLIの実行ファイルを同梱している
• 設定は2層に分かれている。エディタ側の chatgpt.* が8キー、エージェント側が config.toml。この2つを混同すると「設定したのに効かない」が起きる
• 2026年8月31日にGPT-5.4とGPT-5.4 miniがCodexから引退した（ChatGPTサインイン時）。モデルの選択肢が最近変わったのはこのため
• 「Chat / Agent / Agent (Full Access)」という3段階の説明は古い。現在の権限はコンポーザー下のコントロールから切り替え、config.toml 側の語彙は read-only / workspace-write / danger-full-access

Codexという製品そのものの定義や、2021年の旧Codexとの違いについてはCodexとは何か（OpenAIのAIコーディングエージェント）で扱っています。本記事では繰り返しません。

導入前に確認する3つの前提

インストールの前に確認しておくと、後段のつまずきの大半を回避できます。

前提1: 入れるべき拡張機能の正体

VS Codeの拡張機能ビューで「Codex」と検索すると、名前の似た拡張が複数並びます。公式のものを見分ける手がかりは次の4点です。

出典: VS Code Marketplace の拡張機能ページ（2026年9月2日にMarketplaceのギャラリーAPIで取得）

注目すべきは、表示名は「Codex」なのに拡張機能IDは openai.chatgpt である点です。IDに codex という文字列は入っていません。これはCodexがChatGPTの一部として提供されている経緯によるもので、ID表記が openai.codex になっている解説を見かけたら、その記述は正確ではありません。判断に迷ったら、発行元が OpenAI でドメイン認証バッジが付いているかを確認してください。

規模の目安として、この拡張機能は2025年3月6日に初版が公開され、インストール数は約1,370万件です。なおギャラリーAPIが返す最新版は 26.5825.51511（2026年8月30日更新）ですが、これはプレリリースチャネルとして配布されているもので、Marketplaceのページで既定表示される安定版とは番号が異なる場合があります。

前提2: VS Code のバージョン要件

拡張機能のマニフェストは動作要件を engines.vscode: ^1.96.2 と宣言しています。つまり VS Code 1.96.2 以上が必要です。

この要件を満たさない場合、拡張機能ビューの検索結果に出てこない、あるいは互換性がない旨が表示されてインストールできないことがあります（このあたりの挙動はVS Code側の仕様です）。「Marketplaceで見つからない」という症状の原因がここにあることは珍しくありません。VS Codeのバージョンは、macOSなら Code → Visual Studio Codeについて、Windows / Linuxなら ヘルプ → バージョン情報で確認できます。

なお、公式ドキュメントが対応環境として挙げているエディタは、VS Code のほかに Cursor、Windsurf、VS Code Insiders です。Xcode と JetBrains 系IDEは同じ拡張機能ではなく、それぞれのIDE側の統合機能からCodexを呼び出す形になります。

前提3: Codex CLIを先に入れる必要はない

日本語の解説記事には「まずHomebrewでCodex CLIをインストールし、そのあとVS Code拡張を入れる」という手順を載せているものがあります。現在この前段は不要です。

根拠は公式の設定リファレンスです。chatgpt.cliExecutable という設定について、公式ドキュメントは「開発用途限定。Codex CLIそのものを開発しているのでなければこの設定は不要で、同梱された実行ファイル（the bundled executable）を手動で上書きすると拡張機能の一部が動作しなくなることがある」と説明しています。「同梱された実行ファイル」という記述が、拡張機能がCodex CLIの実行ファイルを内包していることを示しています。

これは配布形態からも裏付けられます。この拡張機能は darwin-arm64 / darwin-x64 / win32-x64 / win32-arm64 / linux-x64 / linux-arm64 / alpine-x64 / alpine-arm64 の8種類のプラットフォーム別ビルドで配布されています。純粋にJavaScriptだけで動く拡張機能はプラットフォームを区別する必要がないため、これはネイティブの実行ファイルを同梱していることの現れです。

ターミナルから codex コマンドを直接叩きたい場合はCLIを別途入れる意味がありますが、その使い方はCodex CLIの導入と活用ガイドの範囲です。VS Codeから使うだけなら拡張機能ひとつで完結します。

導入手順 — 最初のチャットまで

公式ドキュメントが示す手順は3ステップです。

ステップ1: 拡張機能をインストールする

VS Codeの拡張機能ビュー（macOS: Cmd+Shift+X / Windows・Linux: Ctrl+Shift+X）を開き、検索欄に openai.chatgpt とIDをそのまま入力します。名前で検索するより確実です。表示された「Codex – OpenAI’s coding agent」をインストールします。

ステップ2: サインインする

インストール後、サインイン画面が表示されます。公式ドキュメントによれば、IDE拡張の選択肢は2つです。

• Sign in with ChatGPT を選ぶ — ブラウザが開き、サインイン後に認証情報がCodexへ返されます。ChatGPTのPlus / Pro / Business / Edu / Enterpriseプランで利用できます
• Use API Key を選ぶ — APIキーを入力して OK を選びます。課金はOpenAI Platformアカウント側のAPI従量課金になります

この選択は課金経路だけの問題ではありません。公式ドキュメントは、サインイン方法によって適用される管理者制御とデータ取り扱いポリシーが変わると明記しています。ChatGPTサインインならChatGPTワークスペースの権限・RBAC・ChatGPT Enterpriseの保持および所在地（residency）設定に従い、APIキーならAPI組織側の保持設定と共有設定に従います。業務で使う場合、ここは情報システム部門と合意しておくべき分岐です。

プラン別に何がどこまで含まれるかはCodexの料金プラン比較で整理しています。

ステップ3: Codexサイドバーを開いて最初のチャットを送る

サイドバーのCodexアイコンを選びます。アイコンが見当たらない場合は、コマンドパレット（macOS: Cmd+Shift+P / Windows・Linux: Ctrl+Shift+P）を開いて Codex: Open Codex Sidebar を実行します。これは公式ドキュメントが明示している対処です。

プロジェクトフォルダを開いた状態で、コードベースの説明、限定的な変更、デバッグの相談などを依頼します。公式ドキュメントはここでタスクの前後にGitのチェックポイントを作っておくことを勧めています。変更を元に戻せる状態を保つためで、エージェントに編集させる以上これは実務上の必須手順と考えてください。

エディタの文脈をCodexに渡す

VS Code拡張を選ぶ意味は、すでにエディタで開いているものをそのまま文脈として渡せる点にあります。開いているファイル、選択したコード、最近のチャットをコンポーザー（チャットの入力欄）から参照でき、問題を説明し直す手間が減ります。変更は要約と、変更箇所に絞った差分の形で提示され、同じチャットのまま追加依頼を出せます。

文脈の渡し方には専用のコマンドが用意されています。選択範囲を渡す chatgpt.addToThread（パレット表示は Add to Codex Thread）と、ファイル全体を渡す chatgpt.addFileToThread（Add File to Codex Thread）です。どちらも既定のキーバインドは未割り当てなので、よく使うなら後述の手順で自分で割り当てるのが実用的です。

また、拡張機能のマニフェストには chatgpt.implementTodo（Implement with Codex）というコマンドが含まれています。これは後述する chatgpt.commentCodeLensEnabled 設定と対応していて、TODO コメントの上に表示されるCodeLens（コード行の上に小さく出る操作リンク）からCodexに実装を依頼する導線です。既定で有効になっています。

モデルとreasoning effortの選び方

reasoning effort とは、回答を出す前にモデルにどれだけ考えさせるかの度合いです。上げるほど深く検討しますが、待ち時間と消費する枠も増えます。モデルの選択とは独立に、チャットごとに切り替えられます。

2026年8月31日にモデルの選択肢が変わった

まず時点の話をします。公式ドキュメントは、2026年8月31日にGPT-5.4とGPT-5.4 miniがCodexから引退したと明記しています（ChatGPTサインインの場合）。移行先は次のとおりです。

• gpt-5.4 → gpt-5.6-terra
• gpt-5.4-mini → gpt-5.6-luna

ワークスペース既定、保存済みのモデル設定、管理された構成、カスタムエージェント、スケジュール実行のタスクに古いモデル名が残っている場合は差し替えが必要です。なお gpt-5.2 と gpt-5.3-codex はそれ以前から非推奨です。自分のAPIキーで認証している場合、この引退の影響は受けませんとドキュメントは補足しています。

「最近モデルの選択肢が変わった」と感じているなら、原因はこれです。

IDE拡張から選べるモデル

コンポーザー下のモデルスイッチャーから選びます。2026年9月2日時点で公式が推奨モデルとして挙げているのは次の3つで、いずれもIDE拡張に対応しています。

このほか gpt-5.3-codex-spark がIDE拡張に対応しています。ほぼ即応の反復開発に最適化されたテキスト専用のリサーチプレビューで、ChatGPT Proユーザー向けです。

表の右列に注意してください。Terra と Luna は Codex cloud では使えません。 ローカルで使っていたモデルがクラウドに委譲した途端に選べない、という食い違いはここから来ます。公式ドキュメントは、Codex cloudの既定モデルは「現時点では」変更できないとも明記しています。

reasoning effortの呼称はIDEとCLIで違う

細かいようですが実務で混乱する点です。公式ドキュメントによれば、最も低いreasoning effortの呼称はIDE拡張・ChatGPTデスクトップアプリ・ChatGPT Work（Web版）では「Light」、CLIでは「Low」です。以降は Medium / High / Extra High が共通します。

CLIの記事を読みながらIDE拡張を操作していると「Lowという選択肢がない」と混乱しますが、同じものを指しています。

原則は「必要な結果が出る範囲で最も低いreasoning effortを使う」ことです。公式ドキュメントは、GPT-5.5からGPT-5.6へのreasoning effortの厳密な対応関係は存在しないため、慣れたタスクを低めの設定で試して調整するよう勧めています。

この4段階とは別に、単一タスクにより多くの時間をかける Max と、作業を分割してサブエージェントで並列処理する Ultra があります。ただし公式は「ほとんどのタスクはMaxもUltraも必要としない」と述べています。なおMaxやUltraが選択肢に出ない場合は、アプリ設定側での有効化が必要なことがあります。

設定は2層 — chatgpt.* と config.toml を混同しない

公式ドキュメントは、Codex IDE拡張の設定が2つの層に分かれていると明示しています。

公式ドキュメントは、後述する chatgpt.* キーについて「IDE拡張のものであり、config.tomlには書きません」と明記しています。逆に、モデルやサンドボックスを chatgpt.* に書いても認識されません。拡張機能が定義するキーは8個だけで、その中にモデルもサンドボックスも含まれないからです（全数は次節の表）。「設定したのに反映されない」の多くはこの取り違えです。

Codex設定を開くには、Codexサイドバーの歯車アイコンから Codex Settings を選びます。設定パネルで主要な項目を操作するか、Open config.toml で有効な設定ファイルを直接編集します。

エディタ設定を変えるには、VS Codeの設定を開き、@ext:openai.chatgpt または Codex あるいは設定名で検索して値を更新します。

エディタ設定の全数表

公式ドキュメントが挙げるエディタ設定は次のとおりです。ここに載っている chatgpt.* キー8個は、Marketplaceが配布している拡張機能のマニフェストが実際に定義しているキー8個と完全に一致しており、既定値・列挙値も一致することを確認しています（2026年9月2日照合）。

加えて、チャット表示に関わる2つはVS Code組み込みの設定を拡張機能が尊重する形になっています。chat.fontSize がCodexサイドバーのチャット本文とコンポーザー、chat.editor.fontSize がコードスニペットや差分の表示を制御します。これらは拡張機能が定義するキーではないため、上の8キーとは別枠です。

実務でまず触る価値があるのは次の3つです。

• chatgpt.composerEnterBehavior — 日本語入力では変換確定の Enter で意図せず送信してしまう事故が起きます。cmdIfMultiline にすると複数行のときだけ修飾キーが必要になり、この事故を減らせます
• chatgpt.followUpQueueMode — 走らせている最中に「やっぱりこうして」と割り込みたいなら steer。なお Cmd・Ctrl+Shift+Enter を押すと、そのメッセージ1回だけ挙動を反転できます
• chatgpt.openOnStartup — 毎回サイドバーを開くのが手間なら true

なお chatgpt.cliExecutable と chatgpt.localeOverride は、マニフェスト上 scope: application が指定されています。VS Codeの仕様上この2つはユーザー設定専用で、ワークスペース設定（.vscode/settings.json）には書けません。チームで設定を配る際の落とし穴になります。

コマンドとスラッシュコマンド

コマンドパレットとキーバインド

公式ドキュメントが挙げるコマンドは次の6つです。

パレット表示名はいずれも Codex: の接頭辞付きで表示されます。ドキュメントの説明文とパレット上の表示が一致しないものがある（chatgpt.newCodexPanel は説明が「新しいCodexパネルを作成」、表示は New Codex Agent）ため、名前で探すときは注意してください。なお chatgpt.newChat の Cmd+N はマニフェスト上 chatgpt.supportsNewChatKeyShortcut という条件付きで登録されており、常に有効とは限りません。

キーバインドを割り当てるには、コマンドパレットから Preferences: Open Keyboard Shortcuts を実行し、Codex またはコマンドID（例: chatgpt.newChat）で検索して鉛筆アイコンから設定します。

スラッシュコマンド22個

コンポーザーで / を入力すると候補が出ます。公式が挙げるIDE拡張のスラッシュコマンドは22個です。日常運用でまず覚える価値がある4つ（未コミット変更のレビュー、文脈の使用量確認、文脈の圧縮、計画）を太字にしています。

CLIとの差 — IDE拡張にあるもの、無いもの

同じCodexでも、入口によって使えるスラッシュコマンドは違います。公式のリファレンスを突き合わせると、CLI側は表の行数で50個（/agent と /subagents のように1行に2つの名義があるものを分けて数えると53個）、IDE拡張側は22個です。

IDE拡張にあってCLIの一覧には無いものは、実行場所と文脈に関わる7個です。/cloud、/cloud-environment、/local、/worktree、/project、/reasoning、/ide-context（CLIには挙動の異なる /ide があります）。エディタから実行場所を切り替えるという、IDE拡張ならではの役割を反映しています。

逆にCLIにあってIDE拡張の一覧には無いものには /permissions、/sandbox-add-read-dir、/setup-default-sandbox、/skills、/subagents、/usage、/diff、/resume などがあります。

とくに /permissions は要注意です。権限とサンドボックスの解説記事はCLI前提で書かれていることが多く、「/permissions で読み取り専用に切り替える」といった説明が出てきます。IDE拡張の公式スラッシュコマンド一覧に /permissions は含まれていません（該当ドキュメントを検索して0件であることを確認済み、2026年9月2日）。IDE拡張での切り替え方は次章のとおりです。

権限とサンドボックス — 現在の語彙を確認する

既定の挙動とOSごとのサンドボックス実装

公式ドキュメントは、Codex CLIとIDE拡張について「OSレベルの仕組みがサンドボックスポリシーを強制する。既定はネットワークアクセスなし、書き込みはアクティブなワークスペースに限定」と説明しています。

つまり初期状態は比較的安全側に倒れています。ネットワークを使わせたい場合は設定で明示的に有効化します。

[sandbox_workspace_write]
network_access = true

サンドボックスの実装はOSごとに違い、macOSはSeatbelt、Linuxは bwrap と seccomp を使います。

Windowsの場合は2経路あります。WSL2内で動かすとLinux実装が、ネイティブWindowsで動かすとWindowsサンドボックス実装が使われます。公式の推奨はWSL2で、IDE拡張はこれを直接サポートしています。VS Codeの設定に次を入れると、WSLが利用可能なときは常にWSL内でエージェントを実行し、コマンド・承認・ファイルシステムアクセスについてLinuxのサンドボックス意味論を継承します。

{
  "chatgpt.runCodexInWindowsSubsystemForLinux": true
}

なおWSL1はCodex 0.114 までのサポートで、0.115 以降はLinuxサンドボックスが bwrap に移行したため非対応です。Windows固有の導入とつまずきはCodexをWindowsで使う導入ガイドで詳しく扱っています。

IDE拡張での権限の切り替え方

公式ドキュメントは、IDE拡張について「コンポーザー下の権限コントロールを使う」と説明しています。メニューに何が並ぶかは構成によって変わり、Ask for approval、対象となる承認要求に対する Approve for me、Full access、および名前付き・カスタムの権限プロファイルが含まれうる、とされています。恒久的な既定値を決めたい場合は、前述の Codex Settings 画面または config.toml で設定します。

古いのは「Chat / Agent / Agent (Full Access)」という3段階の組み立て

日本語の解説記事では、承認モードを「Chat（読み取りのみ）/ Agent（編集可）/ Agent (Full Access)（無制限）」の3段階として説明しているものを今も見かけます。この組み立ては現行の公式ドキュメントにありません。2026年9月2日時点の公式ドキュメント全文（llms-full.txt、約176万字）を検索したところ、「Agent (Full Access)」「Agent Full Access」「agent-full-access」はいずれも0件でした。

ただし、古いのは3段階という組み立てと Agent という接頭辞であって、「Full access」単体は現役です。 前項のとおり、コンポーザー下メニューの選択肢として公式に記載されています。

config.toml 側の語彙は次のとおりです。

• サンドボックスモード: read-only / workspace-write / danger-full-access
• 権限プロファイル（Beta）: :read-only / :workspace / :danger-full-access

権限プロファイルは公式が「Beta。活発に開発中で変更の可能性がある」と注記している新しい仕組みです。重要な制約として、権限プロファイルと従来のサンドボックス設定は併用できません。default_permissions と [permissions] を使うか、sandbox_mode と [sandbox_workspace_write] を使うかのどちらかで、混在させると従来設定が優先されます。ただし管理配布の allowed_permission_profiles が存在する場合は例外で、権限プロファイル側が使われます。

古い語彙の記事を参照して設定を書こうとすると噛み合わないので、この点は押さえておいてください。

実行場所を選ぶ — Local / Worktree / Cloud

Codexのチャットは、開始時に実行場所を選べます。区分は3つです。

• Local — 現在のプロジェクトディレクトリで直接作業する
• Worktree — Git worktreeに変更を隔離する
• Cloud — 設定済みのクラウド環境でリモート実行する

公式は「LocalとWorktreeはどちらも自分のコンピュータ上で動く」と明記しています（この3区分の整理は、公式ではChatGPTデスクトップアプリの新規チャット画面を例に説明されています）。Worktreeはリモート実行ではなく、あくまでローカルでの隔離です。同じリポジトリに複数の作業を並行させても互いの変更が衝突しないため、実験的な変更を本流と分けたいときに向きます。

IDE拡張でも /local、/worktree、/cloud、/cloud-environment で同じ切り替えができます。時間のかかる作業をクラウドに投げて、エディタに戻って結果をレビューできます。ただしCodex cloudはChatGPTサインインが必須で、APIキー認証では使えません。また前述のとおりTerraとLunaはcloudでは選べません。

クラウドとCLIのどちらに寄せるかという選択そのものはCodex CloudとCLIの使い分けガイドで10軸の比較表を用意しているので、そちらを参照してください。本記事はVS Codeから使う場合に閉じます。

他の入口との使い分け — VS Code拡張をどこに置くか

Codexには複数の入口があります。VS Code拡張をどこに位置づけるかを整理します。

VS Code拡張を選ぶ判断基準はシンプルです。すでにエディタでそのコードを見ているなら拡張機能が最短です。文脈を説明し直す必要がなく、差分をその場で確認できます。逆に、エディタを開いていない状態から始まる作業、複数を並行させる作業、時間のかかる作業は、それぞれ他の入口のほうが素直です。

なお、macOSに限っては、ChatGPTのmacOSアプリ側から「Work with VS Code」を選ぶことで、ChatGPTがVS Codeの内容について回答したり簡単な編集を行ったりする連携もあります（拡張機能のREADMEに記載）。

入口を移動しても作業は続けられます。設定の中核である config.toml は、ChatGPTデスクトップアプリ・Codex CLI・IDE拡張で共通だからです。既定モデルを固定したい場合、公式は次の書き方を例示しています。

model = "gpt-5.6"

上の表に挙げた gpt-5.6-sol などのバリアントを固定したい場合は、モデルスイッチャーに表示される識別子をそのまま書きます。

外部ツール連携（MCP）の設定も config.toml 側なので、IDE拡張から /mcp で状態を確認できます。設定の書き方はCodexのMCP設定ガイドにまとめています。

なお、Claude Codeと比較検討している場合はClaude CodeとCodexの比較を、両方を併用する運用はClaude CodeとCodexのハイブリッド運用を参照してください。

つまずき対処

症状から引ける形で整理します。既出の項目は原因だけ示し、詳細は該当章へ戻ってください。

チーム導入で決めておくこと

個人で試す分には拡張機能を入れてサインインすれば終わりですが、チームで使うなら事前に決めておくべき点があります。

サインイン方法を統一する。 ステップ2で触れたとおり、この選択で適用される管理者制御とデータ保持の前提が変わります。個人の裁量に任せると、同じリポジトリを扱っていてもデータの扱いが人によって違う状態になります。情報システム部門と合意したうえで、どちらかに寄せてください。

サンドボックスを緩める条件を決める。 既定は「ネットワークなし・書き込みはワークスペース内」です。network_access = true や danger-full-access、コンポーザー下メニューの Full access は、選んだ瞬間に既定の保護が外れます。誰がどういう場合に緩めてよいかを先に決めてください。

設定の配り方を決める。 モデル、reasoning effort、権限、MCPサーバーは config.toml に集約されます。エディタ設定（chatgpt.*）は原則VS Codeのワークスペース設定として共有できますが、cliExecutable と localeOverride の2つは scope: application のためユーザー設定専用です。ここを取り違えると「配ったのに効かない」が起きます。

レビュー体制を先に用意する。 エージェントが書く量が増えるほど、ボトルネックは生成ではなくレビューに移ります。/review で未コミット変更をレビューさせる運用は有効ですが、エージェントのレビューは人のレビューの代わりではありません。誰が最終的に責任を持つかは変わらない前提で設計してください。

VS Codeのバージョンを揃える。 1.96.2 未満の端末では拡張機能が入りません。「自分の環境だけ動かない」の原因になります。

よくある質問

まとめ — 導入初日にやること

1. サインイン方法をチームで決める。ChatGPTサインインかAPIキーかで、適用される管理者制御とデータ保持の前提が変わる
2. 拡張機能ビューで openai.chatgpt とIDで検索し、発行元のドメイン認証バッジを確認して入れる。見つからなければVS Codeが 1.96.2 以上か確認する
3. config.toml を開き、モデルと権限をリポジトリの方針に合わせる。chatgpt.* は別物なので触らない
4. chatgpt.composerEnterBehavior を cmdIfMultiline にする。日本語入力なら初日に必ず踏む事故を防げる
5. タスクの前後にGitのチェックポイントを作る習慣をつける

そして、もうひとつ習慣をお勧めします。Codexの設定記事を読むときは、公開日と、参照している公式ドキュメントの時点を先に確認してください。 本記事公開のわずか2日前にモデルが入れ替わり、「Chat / Agent / Agent (Full Access)」のように現行ドキュメントには存在しない3段階の呼び方が、日本語記事には残り続けています。時点の合わない手順は、正しく実行しても動きません。

AI協働開発をチームにどう組み込むか、レビュー体制をどう設計するかについて具体的に相談したい場合は、お問い合わせからご連絡ください。開発の内製化をどこから始めるべきかを含めてご相談に応じています。