3行でいうと

  • 手元で使う入り方は、ChatGPTアカウント（既定はブラウザ。ブラウザが使えないときは、ベータのデバイスコード）と、APIキーです。CIなどの自動化には、公式が「APIキーを基本」と書いています。ChatGPTに結びついた認証を無人で使う道として、アクセストークン（BusinessとEnterpriseの機能）、サービスアカウント、ワークロードID（ベータ）が、別のページに用意されています。
  • 認証情報の保存場所は、設定 cli_auth_credentials_store で決まります。~/.codex/auth.json は平文のファイルで、公式は「パスワードと同じに扱う」と書いています。CIにこのファイルを置く方法も公式にありますが、条件が多く、公開リポジトリには使わないと明記されています。
  • 管理者向けには、ログイン方式やワークスペースを縛る設定、アクセストークンの作成を許す権限、有効期限の上限があります。方式が変わるときは、環境変数の優先順位、片方でのログアウトが両方に効くこと、ワークロードIDが他より先に使われることなど、「いつの間にか別の認証になっていた」が起きる場所に注意が要ります。

この記事は、公式ドキュメントを2026年10月24日に読んでまとめたものです。この記事は、実際に使って確かめた記録ではありません。運営者はCodexを入れていますが、使い心地はこの記事には書いていません。コマンド、設定名、環境変数、画面の項目名は公式の表記を写したもので、動作確認はしていません。公式の文章は要約の形で取得したため、長い引用はせず、ほとんどを言い換えています。権限や契約に関わる所は、公式が書いていることを伝えることを優先しました。セキュリティや契約の助言ではありません。

先に結論

前提：用語をそろえる

ログイン方式を並べる

公式のAuthenticationのページ、アクセストークンやサービスアカウントなどのページ、料金のページを合わせて、方式を並べました。「公式のどこに」の列は、僕らが読んだページです。

方式 使える場所 請求・権限の考え方 公式のどこに書かれているか
ChatGPTでサインイン（ブラウザ） デスクトップアプリ、CLI、IDE拡張。Codex cloudはこれが必須 サブスクリプション。ワークスペースの権限が効く Authentication
ChatGPTでサインイン（デバイスコード） CLI。ブラウザの使えない環境向け。公式はベータと書く 同上。事前に設定画面で有効にする必要がある Authentication
APIキー CLI、デスクトップアプリ、IDE拡張、SDK、codex exec API料金で従量課金。APIの組織の保持・データ共有の設定に従う Authentication、Pricing
アクセストークン（個人） CLIの codex exec、アプリサーバーなどの信頼できる自動化 作った人として動く。BusinessとEnterpriseのワークスペース向けと書かれている Codex access tokens
サービスアカウントのトークン 同上。CLI 0.142.0以降が必要と書かれている 人ではなくアカウントとして動く。サービスアカウントは従量課金のプランにある Service accounts
ワークロードID Codexの実行環境（環境変数とトークンのファイル） 一時的なトークンに交換される。ベータで、ワークスペースごとに有効化が必要 Workload identity federation
組織のゲートウェイ ローカルのクライアント。ゲートウェイのURLと資格情報を組織が配る ゲートウェイ側の管理。設定は後の節 Connect to a gateway
Amazon Bedrock CLI、アプリ、IDE、SDK、codex exec AWSの資格情報。ChatGPTサインインも OPENAI_API_KEY も使わない Use Codex with Amazon Bedrock

Codexのクラウド（Codex cloud）は、ChatGPTでのサインインが必須です。これは前のガイド（01）に書いたとおりで、今回読んだ認証のページにも同じ記載があります。

手元で使う：入り方の手順

画面ごとの入り方

公式のAuthenticationのページに、画面ごとの手順があります。

画面 ChatGPTで入る APIキーで入る ログアウト
Web chatgpt.comでサインインし、ワークスペースを選ぶ （ページには書かれていない） プロフィールのメニュー
デスクトップアプリ 「Continue to sign in」 「Sign in another way」 プロフィールのメニュー
CLI codex login（認証情報がなければ既定でこれが始まる） printenv OPENAI_API_KEY \| codex login --with-api-key codex logout
IDE拡張 「Sign in with ChatGPT」 「Use API Key」 プロフィールのメニュー

CLIのコマンド

公式の例は、次のとおりです。

# ブラウザでChatGPTにログイン（既定）
codex login

# APIキーでログイン（標準入力から渡す）
printenv OPENAI_API_KEY | codex login --with-api-key

# アクセストークンでログイン（標準入力から渡す）
printenv CODEX_ACCESS_TOKEN | codex login --with-access-token

# デバイスコードでログイン
codex login --device-auth

# 今の方法を確かめる / 保存した認証情報を消す
codex login status
codex logout

最初の10分（公式に書かれている範囲）

  1. codex login status で、すでにログインしているかを見る。
  2. していなければ codex login を実行し、ブラウザでサインインする。
  3. 請求や機能の都合でAPIキーを使うなら、printenv OPENAI_API_KEY | codex login --with-api-key。
  4. 入れたら、CLIの中の /status で、今のモデルや設定を見る（01で書いたコマンドです）。
  5. ログアウトは codex logout。CLIとIDE拡張は同じ保存済み認証情報を共有するので、片方でログアウトすると、もう片方でも入り直しになります。
  6. 思った方式で入れていないとき（ここは僕らの整理です）：ログイン画面の前に、環境変数を見ます。公式には、非対話で CODEX_API_KEY や CODEX_ACCESS_TOKEN が使われること、ワークロードIDの変数（OPENAI_FEDERATION_RULE_ID、OPENAI_IDENTITY_TOKEN_FILE）を置くとAPIキーや保存済みのログインより先に使われること、が書かれています。たとえば printenv | grep -E 'CODEX_API_KEY|CODEX_ACCESS_TOKEN|OPENAI_FEDERATION_RULE_ID|OPENAI_IDENTITY_TOKEN_FILE' で、残っているものがないかを探し、そのうえで codex login status と /status を見ます。

APIキーで入ると何が変わるか

公式の料金ページ（日付の記載なし）の機能の一覧表から、APIキーの列を読みました。表は、Plus、Pro、Business、Enterprise/Edu、APIキーの列があります。

区分 公式の表の内容（APIキーの列）
使える（available） Codex CLI、IDE拡張、SDKと codex exec とスクリプト、デスクトップアプリのローカルのチャット、Fastモード、Ultrafast、画像の生成と編集、Web検索、ローカルの /review、自動レビュー、サンドボックス、スケジュールされたタスク、worktree、AGENTS.md、スキル、MCP、サブエージェント、requirements.toml など
一部だけ（limited） ブラウザでのComputer Use、Chromeのブラウザ操作、Memories、プラグイン（一部の公式プラグインは使えない）など
使えない（unavailable） Codex cloud、クラウドのチャット、クラウド環境、インターネットの制御、GitHubへの委任（@codex）、GitHubのPRレビュー、Slack連携、Linear連携、ChatGPT Workのウェブ版、コネクタ、プラグインの共有、音声入力、モバイルからの遠隔操作。管理、セキュリティ、分析の行は、requirements.toml と「APIや業務データを既定で学習に使わない」の行が使え、「SAML SSO、MFA、ユーザー管理」「クラウドのポリシー」「RBACとカスタムロール」「SCIM、EKM、ドメイン認証」「保持と居住地の制御」「分析（ダッシュボードとAPI）」「Compliance APIと監査ログ」の行は使えない

保存場所と取り扱い

ログイン情報はどこに置かれるか

Authenticationのページによると、ログインはキャッシュされて再利用され、トークンは使用中に自動で更新されます。置き場所は次のとおりです。

設定 cli_auth_credentials_store の値 意味（公式の説明）
file CODEX_HOME（既定は ~/.codex）の auth.json。平文のファイル
keyring OSの認証情報の保管庫。使えないと失敗する
auto 保管庫が使えれば保管庫、なければファイル
ephemeral そのプロセスの間だけメモリに置く

公式が書いている取り扱いの注意

ほかに知っておく設定

ブラウザが使えない場所で入る

Authenticationのページの「Headless login」の節に、3つの方法が書かれています。前のガイド（01）では、この点は「認証のページには書かれていませんでした」と書きましたが、今回の確認で、記載があることが分かりました。

  1. デバイスコード（ベータ）。 公式が優先する方法です。使うには、個人なら ChatGPT のセキュリティ設定、管理者ならワークスペースの権限で、デバイスコードでのログインを有効にしておく必要があります。CLIでは codex login --device-auth、対話の画面では「Sign in with Device Code」を選びます。
  2. ブラウザのあるマシンでログインして、auth.json をコピーする。 ページには、ssh、scp、cat を使う例と docker cp の例があります。認証情報がOSの保管庫にある場合は当てはまらないかもしれない、とも書かれています。
  3. コールバックの転送。 ssh -L 1455:localhost:1455 user@remote で、既定のポート1455を手元に転送し、そのセッションで codex login を実行します。

ブラウザでのログインが失敗しうる場面として、公式は、遠隔やヘッドレスのホスト、localhostのコールバックが塞がれている場合を挙げています。

CIや自動化での認証

まず方式を選ぶ

公式は、APIキーで足りるなら、そちらを使うよう繰り返しています。Authenticationのページは、CI/CDにはAPIキーを勧めると書き、CI/CDの認証のページも、ほとんどのジョブはAPIキー、と書いています。アクセストークンのページにも、Platformのキーで動く自動化には、APIキーを使うよう書かれています。ChatGPTのアカウントに結びついた認証が必要なときだけ、以下の3つ（auth.json の持ち回し、アクセストークンやサービスアカウント、ワークロードID）に進みます。選び方の整理は、後の節にまとめました。

APIキーを渡す（基本形）

非対話モードのページの書き方です。1回の実行にだけキーを渡します。

CODEX_API_KEY=<api-key> codex exec --json "triage open bug reports"

auth.json を持ち回す（ChatGPTのアカウントで動かす上級の方法）

「Maintain Codex account auth in CI/CD」のページは、公式が上級（advanced）と位置づけるものです。要点は次のとおりです。

AUTH_FILE="${CODEX_HOME:-$HOME/.codex}/auth.json"

jq '{
  auth_mode,
  has_tokens: (.tokens != null),
  has_refresh_token: ((.tokens.refresh_token // "") != ""),
  last_refresh
}' "$AUTH_FILE"

auth_mode が "chatgpt" で、has_refresh_token が true のときだけ進めます。そのファイルの中身を、CIの秘密情報の保管先に入れるか、信頼できる常設のランナーにコピーします。

方式A：常設のセルフホストランナー

ランナーが CODEX_HOME をジョブの間で保つ方式です。公式の例は、毎週月曜に動くワークフローです。ファイルがないときだけ秘密情報から作る、という点が重要で、毎回上書きすると、Codexが更新したトークンを捨ててしまう、と公式は書いています。

name: Keep Codex auth fresh

on:
  schedule:
    - cron: "0 9 * * 1"
  workflow_dispatch:

jobs:
  keep-codex-auth-fresh:
    runs-on: self-hosted
    steps:
      - name: Bootstrap auth.json if needed
        shell: bash
        env:
          CODEX_AUTH_JSON: ${{ secrets.CODEX_AUTH_JSON }}
        run: |
          export CODEX_HOME="${CODEX_HOME:-$HOME/.codex}"
          mkdir -p "$CODEX_HOME"
          chmod 700 "$CODEX_HOME"

          if [ ! -f "$CODEX_HOME/auth.json" ]; then
            printf '%s' "$CODEX_AUTH_JSON" > "$CODEX_HOME/auth.json"
            chmod 600 "$CODEX_HOME/auth.json"
          fi

      - name: Run Codex
        shell: bash
        run: |
          codex exec --json "Reply with the single word OK." >/dev/null

方式B：使い捨てのランナー

GitHubのホストランナーのように、ジョブごとにファイルが消える環境では、「戻す、動かす、書き戻す」の往復にします。公式の例では、my-secret-cli は、自分の秘密情報管理の道具に置き換える仮の名前です。

name: Run Codex with managed auth

on:
  workflow_dispatch:

jobs:
  codex-job:
    runs-on: ubuntu-latest
    steps:
      - name: Restore auth.json
        shell: bash
        run: |
          export CODEX_HOME="${CODEX_HOME:-$HOME/.codex}"
          mkdir -p "$CODEX_HOME"
          chmod 700 "$CODEX_HOME"

          # Replace this with your secret manager or secure storage command.
          my-secret-cli read codex-auth-json > "$CODEX_HOME/auth.json"
          chmod 600 "$CODEX_HOME/auth.json"

      - name: Run Codex
        shell: bash
        run: |
          codex exec --json "summarize the failing tests"

      - name: Persist refreshed auth.json
        if: always()
        shell: bash
        run: |
          # Replace this with your secret manager or secure storage command.
          my-secret-cli write codex-auth-json < "$CODEX_HOME/auth.json"

書き戻すのは、種のファイルではなく、実行中にCodexが作ったファイルです。書き戻しの手順に if: always() が付いているのは、Codexが失敗しても書き戻すためです。

運用のルールと、やり直し（公式の記載）

アクセストークンを使う（BusinessとEnterprise）

「Codex access tokens」のページの内容です。

export CODEX_ACCESS_TOKEN="<access-token>"
codex exec --json "review this repository and summarize the top risks"

保存したいときは、標準入力から渡します。この場合、エージェントの身元の資格情報がCLIの認証の保存先に保存されます。公式は、マシンに資格情報を残したくないなら環境変数を使うよう書いています。

printf '%s' "$CODEX_ACCESS_TOKEN" | codex login --with-access-token
codex exec "summarize the last release diff"

サービスアカウント（人に紐づけない身元）

「Service accounts」のページの内容です。

ワークロードID（ベータ）

OpenAIのWorkload identity federationのページと、環境変数のページ、フェデレーションルールの参照ページを読みました。

読めていない所：提供元ごとの手順（GitHub Actions、Kubernetes、AWS、Azure、Google Cloudなど）のページと、トークン交換のAPIの細部です。また、ワークロードIDのCodex向けの案内ページ（learn.chatgpt.comの「workload-identity」）は、取得に失敗しました。

チーム・管理者向けの設定

権限：誰が何をできるか

「Roles and workspace permissions」と「Admin setup」のページから、認証に関わる所を整理します。

アクセストークンを許可する手順（公式の書き方）

ownerが https://chatgpt.com/admin/permissions（Workspace settings > Permissions & roles）で行います。

  1. 「Access tokens」の節が出ていれば、「Allow users to create personal access tokens」をオンにする。
  2. 出ていなければ、「Codex and Work Local」または「Codex Local」の下の「Allow members to use Codex access tokens」をオンにする。
  3. ワークフローの持ち主に、ローカルのCodexの権限（「Allow members to use Codex and Work Locally」か「Allow members to use Codex locally」）を与える。「Use Work locally」はWork用で、Codexのトークンには要らない。

注意点は3つです。アクセストークンの権限だけでは、アプリ、CLI、IDEの利用は許可されません。トークンで動かすには、トークンの権限とローカルのCodexの権限の両方が要ります。ローカルのCodexの権限を無効にすると、そのメンバーの有効なトークンは停止（一時的）されますが、取り消されません。権限を戻すと再開します。完全に終わらせるには、取り消します。

有効期限の上限。 同じ権限の画面にある「Access token expiration limit」で、メンバーが選べる最長の有効期間を決めます。すでにあるトークンには効かず、新しく作るものだけが対象です。

トークンの作成。 https://chatgpt.com/admin/access-tokens で「Create」を選び、わかりやすい名前（例：release-ci、nightly-docs-check）を付けます。「Scopes」が出れば「Codex」を選びます。有効期間は、7、30、60、90日から選び、いちばん短い任意の期間は1日です。スコープ付きのトークンは必ず期限が要ります。以前のCodexだけのダイアログには「No expiration」が出ることがあり、公式は、組織が承認し、決まった周期で更新する場合以外は避けるよう書いています。コピーできるのは作成直後の1回だけです。

取り消し。 ownerと管理者は、ワークスペースのどのトークンも取り消せます。アクセストークンの権限を持つメンバーは、自分で作ったものだけを取り消せます。期限切れや取り消し済みのトークンでは、新しい認証つきの実行を始められません。

できること owner・admin トークンの権限を持つメンバー 持たないメンバー
アクセストークンのページを開く できる できる できない
トークンを作る できる（自分の身元で） できる（自分の身元で） できない
トークンの一覧 ワークスペース全体（作成者つき） 自分のものだけ できない
取り消し どのトークンも 自分のものだけ ページに入れない
トークンの権限を与える・外す ownerのみ できない できない

ログイン方式やワークスペースを縛る

ここは、公式のページの間で書き方が分かれている所なので、分けて書きます。

Managed configurationのページ。 管理者がローカルのシステムの requirements.toml、またはmacOSのMDMの要件に置くと、認証情報が読み込まれる前、クラウドのポリシーを取得する前に効く4つのキーがあります。

キー 役割
allowed_login_methods chatgpt、api、またはその両方。api にはAmazon Bedrockが含まれる。省略すると制限なし。設定するなら少なくとも1つが必要
allowed_chatgpt_workspaces ChatGPTのログインを、挙げたワークスペースIDに制限する。Codexのアクセストークンにも効く
cli_auth_credentials_store 認証情報の保存方式（例：keyring）
chatgpt_base_url サービスのURL 
allowed_login_methods = ["chatgpt"]
allowed_chatgpt_workspaces = ["00000000-0000-0000-0000-000000000000"]
cli_auth_credentials_store = "keyring"

Authenticationのページ。 ユーザー側の設定として forced_login_method（"chatgpt" か "api"）と forced_chatgpt_workspace_id が書かれており、認証情報が合わないとCodexはログアウトして終了する、とあります。管理者は、cli_auth_credentials_store と chatgpt_base_url を、ローカルの認証の要件で強制でき、ユーザーは上書きできません。

ページ間の違い（僕らの読み）。 Managed configurationのページは、forced_login_method と forced_chatgpt_workspace_id を、管理者が強制できる要件のキーとしては挙げていません。ユーザーがこれらを自分で設定した場合は、要件に従う必要がある、と書いています。管理者が「縛る」目的で書くなら、allowed_login_methods と allowed_chatgpt_workspaces が、このページで挙がっているキーです。前のガイド（01）は、Authenticationのページの forced_* の記述をもとに書いたもので、今回、管理設定のページを読んで、こちらを補います。どちらのページが新しいかは、日付がなく分かりません。

SSOとMFA

組織のゲートウェイやクラウドを経由する

自分のOpenAIのアカウントを使わず、組織が用意した入口を通る使い方です。

組織のモデルゲートウェイ

「Connect to a gateway」のページは、ゲートウェイのURL、モデル名、資格情報（またはトークンを返す仕組み）を組織が用意する形を説明しています。

「Sign in with ChatGPT through a gateway」のページは、ゲートウェイを残したまま、ユーザーはChatGPTのワークスペースでサインインする構成です。ChatGPTのトークンは Authorization: Bearer で、ゲートウェイ用の資格情報は別の道で送ります。方式Aは、既存の資格情報のコマンドの出力を起動時に GATEWAY_KEY として渡す形で、Codexは更新しないので、期限が切れたら取得し直して再起動します。方式Bは、Codexがゲートウェイへのサインインと更新を管理する形で、ゲートウェイ側にOAuthの認可サーバーが要ります。方式Bはブラウザが必要で、デバイスコードの代わりはない、と書かれています。どのプランが対象か、ベータかどうかは、ページに書かれていませんでした。

Amazon Bedrock

「Use Codex with Amazon Bedrock」のページによると、Bedrockは、ChatGPTサインインも OPENAI_API_KEY も使わない唯一のプロバイダーです。認証は次の順で調べられます。

  1. Bedrockのキー（ベアラートークン）。 AWS_BEARER_TOKEN_BEDROCK と AWS_REGION の両方を設定します。公式は、この順で調べると書き、意図しないキーが別の経路を選ばないよう確認することを勧めています。僕らの読みでは、順序から、古い AWS_BEARER_TOKEN_BEDROCK が残っているとSDKの資格情報より先に使われます。SDKの資格情報を使いたいときは、その変数を外して確かめてください。
  2. AWS SDKの資格情報の連鎖。 aws configure、環境変数（AWS_ACCESS_KEY_ID など）、aws login、aws sso login --profile ... と AWS_PROFILE、会社のSSOやOIDCは AWSプロファイルの credential_process ヘルパーで扱う、という書き方です。

Bedrockでは、Codex cloud、コネクタ、GitHub・Slack・Linearのクラウド連携、管理・RBAC・SCIM・分析などが使えません。ローカルのCLI、アプリ、IDE、SDK、requirements.toml は使えます。プロバイダーの名前は、amazon-bedrock-runtime（新しい設定向けに推奨）と、amazon-bedrock です。クライアントを再起動したあと、/status でプロバイダーを確かめるよう書かれています。

認証が変わるときの注意

僕らの整理：選び方

ここからは僕らの整理です。公式の記載から組み立てたもので、公式の推奨そのものではありません。

選び方。

  1. 自分のパソコンで、人が使う：ChatGPTアカウントでサインイン。
  2. ブラウザの使えないサーバーで、人が使う：まずデバイスコード（ベータ。事前に有効化が必要）。だめなら、ポートの転送。auth.json のコピーは最後の手段にする。
  3. CIで、リポジトリのコードを動かす：APIキーを、Codexのステップにだけ渡す。ジョブ全体には置かない。
  4. 組織で、ワークスペースの履歴や監査に載せたい自動化：アクセストークン（BusinessとEnterprise）か、サービスアカウント。
  5. 長期の鍵を置きたくない管理された環境：ワークロードIDを、担当者に相談する。ベータなので、有効化の依頼から始まる。
  6. ChatGPTのアカウントで、ランナーで codex login できず、他の方法がない：auth.json の持ち回し。条件5つを全部確かめ、公開リポジトリでは使わない。

気をつけること

出典