Codexにログイン済みChromeを渡す前に：拡張機能・内蔵ブラウザ・Computer Useの使い分け

3行まとめ

In-app

ログイン不要のpreview。

Chrome

ログイン状態が必要な時。

Computer Use

OSアプリやGUI操作。

Approval

権限と承認を先に決める。

最初に使う入口を分けると、Codexへ見せる情報を狭くできます。

• CodexでWeb画面を見る時は、まず内蔵ブラウザ、Chrome extension、Computer Useを分けます。最初からログイン済みChromeを渡す必要はありません。
• localhost、file preview、public pageなら内蔵ブラウザで足ります。ログイン状態、cookie、既存Chrome拡張、既存tabが必要な時だけChrome extensionへ進みます。
• Computer Useはブラウザ検証の上位版ではなく、OSアプリやGUI操作のための入口です。domain、承認、機密情報、停止条件を決めてから使います。

本文の事実確認には、OpenAI DevelopersのCodex Chrome extension、In-app browser、Computer Use、Permissions、Agent approvals & security、Changelog、OpenAI Help、OpenAI公式ブログを使っています。Xで見かける「Codexがログイン済みブラウザアプリを扱える」話題は需要シグナルとして扱い、本文の根拠にはしていません。

この記事でわかること

入口

どのbrowser機能を使うか。

Domain

許可するhost。

Session

ログイン状態の扱い。

Report

報告形式と停止条件。

便利さではなく、必要な権限から入口を選びます。

• Codexの内蔵ブラウザ、Chrome extension、Computer Useをどう使い分けるか
• ログイン済みChromeを渡す前に決めるdomain、承認、報告形式
• localhostやpublic pageでは内蔵ブラウザを優先する理由
• Chrome extensionを使う時に、cookieや既存tabをどう説明するか
• Computer Useをブラウザ外のGUI作業へ分ける考え方
• チーム導入初週に、権限を広げすぎない手順

Codexのブラウザ関連機能は、画面確認を速くします。特にWebアプリ開発では、実装、表示確認、修正指示、再確認を同じスレッドで回せるため、PR前の手触りがかなり変わります。

ただし、画面を見られるということは、画面に出る情報も見えるということです。ログイン済み画面、管理画面、CRM、メール、社内ツールを扱うなら、便利さより先に権限の境界を決める必要があります。

前提知識

項目	内容	見方
In-app browser		thread内の共有preview。
Chrome extension		通常Chromeの状態を使う。
Computer Use		desktop GUIを操作。
Permissions		networkとapprovalを管理。

Codexの画面確認機能は、見える情報の広さが違います。

OpenAI DevelopersのIn-app browser docsでは、内蔵ブラウザはCodexとユーザーがスレッド内でレンダリング済みWebページを共有するための機能として説明されています。用途は、local development server、file-backed preview、ログイン不要のpublic pageです。

同じdocsでは、内蔵ブラウザはauthentication flow、signed-in pages、通常のChrome profile、cookies、extensions、existing tabsをsupportしないため、ログイン状態や拡張機能が必要な場合は通常ブラウザやCodex Chrome extensionを使うと説明されています。

Chrome extension docsでは、Codexが通常Chromeの状態を使う場面が扱われています。ログイン済みのbrowser stateが必要なLinkedIn、Salesforce、Gmail、社内toolsのようなページでは、内蔵ブラウザではなくChrome extensionが候補になります。

Computer Use docsでは、CodexがmacOSやWindowsのGUIを操作するための入口として説明されています。これはChrome extensionの置き換えではありません。ブラウザ外のアプリ、OSダイアログ、デスクトップ上の操作を扱うための別機能です。

この記事の扱う範囲

項目	役割
In-app browser	スレッド内でWebページをpreviewし、視覚的な確認やコメントを行う
Chrome extension	通常Chromeのログイン状態、cookie、拡張機能、既存tabが必要な時に使う
Computer Use	OS上のGUIアプリやブラウザ外の操作を扱う
Permissions	network、filesystem、sandbox、approvalの境界を決める
Allowlist / blocklist	Codexに扱わせるdomainと扱わせないdomainを分ける
報告形式	画面確認の結果を、証跡、影響、次の作業へ分けて残す

2026年6月1日時点で公開されているOpenAI公式情報を確認しています。導入時には、利用中のCodex app、Chrome extension、ChatGPT plan、組織のmanaged configuration、permissions profileを改めて確認してください。

注意点

この記事は、ログイン済みChromeを無条件にCodexへ渡すための記事ではありません。むしろ逆です。内蔵ブラウザで足りる作業を先に済ませ、どうしてもログイン状態が必要な時だけChrome extensionへ進むための判断材料として書いています。

まず3つの入口を分ける

項目	内容	見方
In-app		publicやlocalhost。
Chrome extension		signed-in page。
Computer Use		browser外の操作。
Shell		codeとtest確認。

画面確認とコード実行を分けると、依頼範囲がぶれません。

最初に決めるのは、「Codexに何を見せるか」です。Web画面を確認したいだけなら、入口は大きく3つあります。

入口	使う場面	渡る情報の広さ
In-app browser	localhost、file preview、public page	ログイン不要のページ内容
Chrome extension	ログイン済みページ、通常Chromeの状態が必要なページ	cookie、既存profile、対象tab周辺の状態
Computer Use	ブラウザ外のアプリ、OS GUI、file picker	desktop上で見える操作対象

この3つを混ぜると、依頼文が曖昧になります。「画面を見て直して」と頼むと、Codexがどのブラウザを使うのか、どのsessionを見てよいのか、どのdomainに入ってよいのかが分かりません。

最初の判断

まずは内蔵ブラウザで足りるかを見ます。開発中のlocalhost、Storybook、静的HTML、public landing page、ログイン不要のエラー画面なら、通常Chromeのprofileを渡す理由は薄いです。

次に、ログイン状態が必要かを見ます。管理画面、SaaSの設定画面、OAuth後の画面、Chrome拡張が入っている前提の画面なら、Chrome extensionを検討します。ただし、その時点でCodexへ見える情報は広がります。

最後に、ブラウザの外かどうかを見ます。macOSのシステム設定、デスクトップアプリ、ファイル選択ダイアログ、IDEのGUI設定を扱うなら、Chrome extensionではなくComputer Useの領域です。

混ぜると起きる問題

入口を決めないまま使うと、レビューしにくい差分が残ります。たとえば「ログインして設定を見て」とだけ頼むと、どのaccount、どのdomain、どのtab、どの範囲まで見てよいかが曖昧です。

チーム導入では、依頼文に入口を書きます。「内蔵ブラウザでlocalhostだけ確認する」「Chrome extensionでこのdomainだけを見る」「Computer Useはこの設定画面だけ操作する」のように、作業前に境界を固定します。

内蔵ブラウザはログイン不要の確認に使う

Localhost

開発server確認。

File preview

静的preview。

Public page

ログイン不要。

Comment

視覚的な指摘。

内蔵ブラウザで足りるなら、通常Chromeの状態を渡す必要はありません。

内蔵ブラウザは、最初に使う入口として扱いやすいです。OpenAIのdocsでも、local development servers、file-backed previews、sign-in不要のpublic pagesに向いていると説明されています。

Webアプリ開発なら、次のような場面に合います。

場面	依頼例
localhost確認	http://localhost:3000/settings を開き、フォームの意図しない見え方とconsole errorを確認する
file preview	作成したページを開き、見出しと表が読めるか確認する
public page	公開URLを開き、主要CTAと画像読み込みを確認する
visual comment	画面上の該当箇所にコメントし、修正対象を示す

内蔵ブラウザのよい点は、通常Chromeの状態を使わないことです。つまり、普段のcookie、ログインsession、拡張機能、既存tabを持ち込まずに確認できます。

向いている場面

内蔵ブラウザは、表示確認、軽い導線確認、レスポンス確認、public URLの見た目確認に向いています。ログイン不要の範囲なら、Codexがページを開き、見た目や文言を確認し、修正案を出せます。

たとえば、PR前に「このページを内蔵ブラウザで開き、見出し、主ボタン、フォーム、エラー表示を確認して。修正が必要ならファイル名と理由を分けて報告して」と頼めます。

向かない場面

内蔵ブラウザは、ログインが必要なページには向きません。OpenAI docsでは、authentication flow、signed-in pages、regular browser profile、cookies、extensions、existing tabsをsupportしないと説明されています。

ここを無理に突破しようとしない方が安全です。ログイン情報を貼り付けたり、認証済み画面を再現しようとしたりするより、Chrome extensionが必要か、人間が該当画面を説明するだけで足りるかを判断します。

Chrome extensionはログイン状態が必要な時だけ使う

Cookie

通常Chromeのsession。

Extension

既存拡張が必要。

Tab

既存tabを扱う。

Domain

hostごとに確認。

Chrome extensionは強力なので、必要なhostと操作だけに絞ります。

Chrome extensionは、通常Chromeの状態が必要な時に使います。たとえば、ログイン済みSaaS、社内ツール、CRM、メール、特定Chrome拡張が入った画面、既存tabを前提にした調査です。

ここで大事なのは、「使えるから使う」ではなく「内蔵ブラウザでは足りないから使う」です。Chrome extensionは便利ですが、通常Chromeの状態を使う分、扱う情報の範囲が広がります。

使う前に決めること

Chrome extensionを使う前に、次の項目を決めます。

項目	決めること
対象domain	どのhostだけを見てよいか
対象account	個人accountか検証用accountか
操作範囲	read-only確認か、保存や送信を許すか
取得してよい情報	画面文言、error、URL、network情報のどこまでか
停止条件	個人情報、秘密情報、予期しないdomainが出たら止める

OpenAIのChrome extension docsでは、allowlistとblocklistの管理にも触れられています。allowlistはCodexが再確認なしに使えるdomain、blocklistはCodexが使うべきでないdomainとして扱います。チームでは、この設定を個人任せにしない方がよいです。

チームでの説明責任

ログイン済みChromeを使う場合、レビュー時に「Codexが何を見たか」を説明できる必要があります。少なくとも、対象URL、対象domain、操作内容、保存や送信の有無、出力した証跡を残します。

管理画面や顧客情報が出る画面では、Codexに全文を要約させるより、必要なエラー箇所だけを人間が切り出す方が安全な場合もあります。Chrome extensionは万能の調査担当ではなく、ログイン状態が必要な画面確認のための強い道具として扱います。

Computer Useはブラウザ外のGUI操作に寄せる

項目	内容	見方
Desktop		OS上のapp操作。
Dialog		file pickerなど。
Browser外		IDEや設定画面。
制約		OSと地域条件を確認。

Computer Useはbrowser検証ではなく、GUI作業の入口として考えます。

Computer Useは、ブラウザ操作の延長ではありません。ブラウザの外にあるGUIを操作する時の入口です。OpenAI Developersでは、Codex appからmacOSやWindowsのGUI操作に進む文脈で説明されています。

たとえば、次のような場面です。

場面	考え方
desktop app	ブラウザではなくアプリそのものを操作する
file picker	OSのfile dialogで選択が必要
IDE GUI	設定画面やplugin画面を触る
system settings	権限や環境設定を確認する

Webアプリの画面確認なら、まず内蔵ブラウザかChrome extensionを検討します。Computer Useへ進むのは、ブラウザだけでは目的を達成できない時です。

使いどころ

Computer Useが効くのは、手元のGUI操作が作業の一部になっている場合です。たとえば、アプリの設定画面を開く、ファイルを選ぶ、ウィンドウを切り替える、ブラウザ外のpreviewを確認する、といった操作です。

ただし、GUI操作は再現性が落ちやすいです。コマンドで済む作業、設定ファイルで済む作業、テストで確認できる作業は、先にそちらへ寄せます。

制約を先に見る

Computer Useには、OS権限や利用条件があります。導入時には、使える環境、macOSやWindows側の権限、組織の管理設定、対象region、操作ログの扱いを確認します。

チームの初期運用では、「Computer Useを使ってよい作業」を少なく始めるのが現実的です。ブラウザ確認、shell、テスト、PRレビューで足りる作業をComputer Useへ寄せない方が、レビューしやすくなります。

チームで最初に決める権限

項目	内容	見方
Allowlist		許可するdomain。
Blocklist		扱わないdomain。
Approval		承認が必要な操作。
Secrets		入力しない情報。

権限は作業中に広げるのではなく、依頼前に固定します。

Codexの権限設計は、ブラウザ機能だけで完結しません。network、filesystem、sandbox、approval、MCP、Computer Use、Chrome extensionが重なると、どこまで自動で進めてよいかが見えにくくなります。

OpenAI DevelopersのPermissions docsでは、network domainのallow/deny、local/private network、Unix socket、workspace writeなどの設定が説明されています。Agent approvals & security docsでは、approval policy、sandboxとの組み合わせ、auto-reviewなどが整理されています。

domain allowlist

最初に決めるのはdomainです。内蔵ブラウザでもChrome extensionでも、Codexが見るURLを広げすぎると、不要な情報まで見える可能性があります。

例として、PR確認なら次のように分けます。

目的	許可する範囲
localhost確認	localhost、127.0.0.1、対象port
public preview	preview domainだけ
staging確認	staging hostだけ
SaaS確認	検証用accountの対象domainだけ

OpenAIのPermissions docsでは、local/private network guardや、localhost、127.0.0.1の明示的allowlistにも触れられています。ローカル確認でも、何でも開ける前提にはしません。

sandboxとapproval

ブラウザ確認とコード変更を同じ依頼にすると、承認の境界が曖昧になります。画面を見て、原因を推測し、コードを変更し、テストを実行し、保存操作まで行う場合、それぞれリスクが違います。

最初の運用では、調査と変更を分けます。

1. 画面確認だけを頼む
2. 原因候補を報告させる
3. 人間が修正方針を承認する
4. 小さな差分を作らせる
5. testやlintの結果を残す

Agent approvals & security docsでは、approval promptsを無効化できる一方で、sandboxの範囲は別に制御する考え方が示されています。非対話実行や自動実行では、便利さだけでapprovalを外さない方がよいです。

secretsとbrowser content

OpenAI公式ブログ「Running Codex safely at OpenAI」では、identity and credentials、workspace-level controls、compliance logsなどの話が出ています。企業利用では、誰の権限でCodexを使い、どの活動がログに残るかも重要です。

Chrome extensionを使う時は、browser contentをuntrusted contextとして扱います。画面にsecret、personal data、customer dataが出るなら、Codexに丸ごと読ませる前に、人間が必要部分だけを切り出す判断も必要です。

失敗しやすい依頼

対象URL

見る画面を1つにする。

操作

許可する動きを書く。

証跡

根拠を残す。

停止

迷ったら止める条件。

画面を見て直して、ではなく、調査と変更を分けて頼みます。

ブラウザ操作で失敗しやすいのは、依頼が広すぎる時です。

悪い依頼はこうです。

この管理画面を見て、問題があれば直して。

この依頼では、Codexがどの画面を見てよいのか、保存してよいのか、どの情報を報告してよいのかが分かりません。ログイン済みChromeを使う場合、特に危険です。

よい依頼

よい依頼は、対象、入口、操作、報告、停止条件を分けます。

Codex Chrome extensionを使って、検証用accountで開いている
https://staging.example.com/settings/billing だけを確認してください。

やってよいこと:
- 表示されているplan名、error banner、console errorの有無を確認する
- 保存、送信、削除、inviteはしない
- 別domainへ遷移したら止める

報告形式:
- 見たURL
- 発生している問題
- 根拠
- 次に人間が確認すること

この形なら、Codexが迷いにくく、人間もレビューしやすくなります。変更作業へ進む場合も、画面確認の報告を見てから、別の依頼として小さく渡せます。

報告を実装に接続する

報告には「見たもの」と「推測」を分けて残します。たとえば、error bannerが出ていることは見た事実です。API認証が原因らしい、というのは推測です。この2つを混ぜると、修正PRの根拠が弱くなります。

実装へ進む時は、既存のAIエージェントPRテンプレートと相性がよいです。たとえば、AIエージェントPRテンプレートの記事のように、Summary、Tests run、Not run、Risksを固定しておくと、ブラウザ確認の結果もレビューへ乗せやすくなります。

導入初週の進め方

1. 1日目

   内蔵ブラウザでlocalhost確認。

2. 2日目

   public pageで報告形式を固定。

3. 3日目

   Chrome extensionの対象domainを1つに限定。

4. 5日目

   承認とblocklistを見直す。

5. 7日目

   Computer Useの要否を判断。

最初からログイン済み画面を広く渡さず、小さく始めます。

初週は、いきなりログイン済みChromeを広く渡さない方がよいです。小さく始め、報告形式と停止条件を作ってから広げます。

日	やること
1日目	内蔵ブラウザでlocalhostとpublic previewだけ確認する
2日目	見たURL、問題、根拠、次の作業を報告形式として固定する
3日目	Chrome extensionを検証用account、対象domain 1つに限定して試す
4日目	allowlist、blocklist、保存禁止操作、停止条件を明文化する
5日目	sandbox、approval、network permissionsと合わせて見直す
7日目	Computer Useが本当に必要なGUI作業だけを候補にする

この順番なら、便利さを試しつつ、権限を広げる前に止まれます。特にチームでは、最初の成功体験より「どこで止めるか」の方が大事です。

Codex全体の導入ルールを整えるなら、Codex 101の記事と合わせて、AGENTS.md、permissions、review条件を先に固定します。network allowlistの考え方は、Codexにインターネットアクセスを許可する前の記事も近いです。

FAQ

Login?

必要ならChrome extension。

Localhost?

まず内蔵ブラウザ。

Desktop?

Computer Useを検討。

Secrets?

browser flowに入れない。

迷ったら、Codexへ見せる情報が最も少ない入口を選びます。

Chrome extensionを入れたら、内蔵ブラウザは不要ですか？

不要ではありません。ログイン不要のページ、localhost、file preview、public pageは内蔵ブラウザから始める方が扱いやすいです。Chrome extensionは、通常Chromeの状態が必要な時だけ使います。

ログイン済みSaaSを確認させてもよいですか？

検証用account、対象domain、操作範囲、保存禁止、停止条件を決めた上で検討します。顧客情報や個人情報が出る画面では、Codexに丸ごと見せない選択も必要です。

Computer Useを使えば何でも操作できますか？

そう考えない方がよいです。Computer UseはGUI操作向けですが、再現性、OS権限、対象環境、組織ポリシーの制約があります。コマンドやテストで確認できることは、先にそちらへ寄せます。

Chrome DevTools MCPやPlaywright MCPとはどう違いますか？

Chrome DevTools MCPはPerformance、Network、Console、Lighthouseなどの調査に向いています。Playwright MCPはブラウザ操作や検証の自動化に寄せやすいです。Codex Chrome extensionは、通常Chromeのログイン状態や既存環境が必要な画面確認で使いどころがあります。

次に読むなら

参照した主な情報源

• https://developers.openai.com/codex/app/chrome-extension
• https://developers.openai.com/codex/app/browser
• https://developers.openai.com/codex/app/computer-use
• https://developers.openai.com/codex/agent-approvals-security
• https://developers.openai.com/codex/permissions
• https://developers.openai.com/codex/changelog
• https://help.openai.com/en/articles/11369540-using-codex-with-your-chatgpt-plan
• https://openai.com/index/running-codex-safely/

更新履歴

1. 2026年6月1日

   OpenAI DevelopersのCodex app、permissions、security、changelogを確認して初版を作成しました。

導入時には利用中のCodex app、Chrome extension、権限設定を確認してください。

• 2026年6月1日: OpenAI DevelopersのCodex app、Chrome extension、In-app browser、Computer Use、Permissions、Agent approvals & security、Changelog、OpenAI Help、OpenAI公式ブログを確認して初版を作成しました。