【個人プラン】Plus / Pro で Codex を CI で動かす

2026.06.03
こんにちは　AI事業本部の市田拓馬です！
 はじめに前回の記事では、ChatGPT Business / Enterprise 向けに追加された Codex access tokens を、OpenAI 公式ドキュメントをもとに整理しました。Codex access tokens は、Codex local を ChatGPT ワークスペースのユーザ権限で、スクリプトや CI から自動実行するための認証情報です。
ただし Codex access tokens は ChatGPT Business / Enterprise ワークスペースが前提で、自分のような ChatGPT Plus / Pro 個人ユーザは発行できません。

なので今回は、個人ユーザが、契約プランの範囲内で使える認証方式を使いCIを動かしてみました。
まず、Codex CLI を CI / CD で動かす場合の認証方式は、大きく 3 種類に分類できます。
A: OpenAI APIキー方式：OpenAI Platform の API キーで認証する標準的なルート。公式 CI/CD ドキュメントでも推奨ですが、ChatGPT サブスクリプションとは別に、API 利用枠での課金になります
B: Codex access tokens 方式：ChatGPT Business / Enterprise ワークスペース専用の認証情報。前回の記事で扱いました
C: ChatGPT サブスク認証の auth.json 持ち込み方式：ローカルで codex login してできた auth.json を CI runner に持ち込む方式。Plus / Pro 個人ユーザが ChatGPT サブスクリプションの枠内で CI を動かせる唯一のルートで、OpenAI 公式ドキュメントでは Maintain Codex account auth in CI/CD (advanced) として案内されています
自分は Plus / Pro 個人ユーザなので、本記事では C の auth.json 持ち込み方式を、GitHub Actions の GitHub-hosted runner（GitHub が提供する、ジョブごとに破棄される runner）で実機検証しました。検証用のリポジトリは trusted private な GitHub repo を前提とします。
検証は段階的に進めました。まず手動起動（workflow_dispatch）で動作確認し、続いて push 自動起動を確認し、最後に公式 advanced ガイド（上の C で紹介した OpenAI 公式の Maintain Codex account auth in CI/CD (advanced)）が ephemeral runner（ジョブごとに破棄される runner。詳細は後の「前提知識」で解説）向けに示す round-trip パターンまで完成させました。
 やってみた要約以下が結論です。
GitHub-hosted runner（ubuntu-latest）で、self-hosted runner なしで、ChatGPT サブスク認証の枠内で動かせました
段階的に 3 パターンの動作確認に成功しています
Step A: 手動起動（workflow_dispatch）
Step B: push 自動起動（main への push トリガー）
Step C: round-trip 完成版（書き戻しで Secret 内の auth.json が連続更新される ephemeral runner 正規ルート）

ただし最初は 4 回連続で refresh_token_reused エラーで失敗しました
原因は「path mismatch」：codex login が auth.json を書いた場所と、GitHub Secret に push したファイルパスが不一致だったというものでした。詳細はアペンディックス A を参照してください
失敗中に立てた 3 つの仮説（VS Code 拡張の競合、Codex.app デスクトップアプリの競合、macOS keychain との競合）は、いずれも誤りでした。詳細はアペンディックス B を参照してください
 今回扱う内容本記事で実機検証する範囲です。
ローカルで codex login してサブスク認証の auth.json を作る
検証用 private リポジトリ に GitHub Actions workflow を追加・push する
auth.json の中身を GitHub Secret として登録する
段階的に workflow を完成させる（Step A: 手動起動 → Step B: push 自動起動 → Step C: round-trip 完成版）
各段階で artifact から成果物を取得する
失敗パターンを切り分けて、原因を突き止める確認テストを行う
 前提知識 codex exec とはcodex exec は、Codex を対話画面で開かず、1 回の指示として実行するコマンドです。OpenAI の Non-interactive mode ドキュメントでも、codex exec はスクリプトや CI から Codex を呼び出すためのモードとして説明されています。
たとえば、以下のようにシェルからでも一発で実行できます。
codex exec "このリポジトリの構成を要約してください"
 auth.json とはauth.json は、Codex CLI が codex login 時に作成・更新する認証ファイルです。ChatGPT サインインを使った場合、ここには ChatGPT 管理の access token と refresh token が含まれます。
auth.json の中身は ChatGPT セッションを操作できる認証情報なので、パスワード相当として扱う必要があります。公式ドキュメントでも、リポジトリへのコミット禁止、チャットやチケットへの貼り付け禁止、public リポジトリでの利用禁止が明示されています。
 CODEX_HOME とはCODEX_HOME は、Codex CLI が認証情報や設定を置く作業ディレクトリの場所を指す環境変数です。デフォルトは ~/.codex で、auth.json や config.toml がここに置かれます。
 access token と refresh token のしくみauth.json の中には、2 種類のトークンが入っています。
access token：短命なトークン（数十分〜1 時間）で、API リクエストの認証に使います
refresh token：長命なトークン（数十日〜数ヶ月）で、access token の期限が切れたときに新しい access token を取得するための鍵です
codex exec を呼ぶたびに、Codex CLI は access token の期限を確認し、切れていれば refresh token を使って新しい access token を取得しに行きます。このとき、新しい access token と新しい refresh token のペアが返ってきて、auth.json は新しい値で上書きされます。
OAuth 2.0 の標準的な動作として、refresh token は使うたびに古いものが無効化され、新しいペアに置き換わる仕組み（refresh token rotation）です。古い refresh token を再利用しようとすると、サーバ側から refresh_token_reused というエラーが返ります。
 runner の種類GitHub Actions のジョブを実行するマシンを runner と呼びます。runner には大きく 2 つのカテゴリがあります。
GitHub-hosted runner：GitHub が用意するクラウド上の runner（ubuntu-latest など）。ジョブごとに新しい仮想マシンが立ち上がり、ジョブが終わると破棄される
self-hosted runner：自分で用意したマシンに runner エージェントをインストールしたもの。デフォルトではジョブをまたいで状態が残る
「ephemeral runner」という言葉は、「ジョブごとに破棄される」という性質を表します。GitHub-hosted runner は常に ephemeral 性質を持ち、self-hosted runner も --ephemeral オプションで ephemeral として動かせます。
OpenAI 公式の Codex CI/CD ガイドが「ephemeral runner」と呼ぶ対象には、GitHub-hosted runner と self-hosted ephemeral runner の両方が含まれます。本記事では GitHub-hosted runner（ephemeral 性質を持つ）を使います。
 公式ドキュメントが示す 2 ルートOpenAI 公式の Maintain Codex account auth in CI/CD (advanced) では、auth.json を CI で維持する方法として 2 つのルートが示されています。
ルート 1：self-hosted runner + persistent CODEX_HOME

原文の "The simplest fully automated setup is a self-hosted GitHub Actions runner with a persistent CODEX_HOME" のとおり、自分で用意したマシンの永続ディスクに auth.json を置き続ける構成です。Codex がリフレッシュしたあとの auth.json はそのまま次回ジョブに引き継がれます
ルート 2：ephemeral runner + round-trip

原文の "Ephemeral runners: restore, run Codex, persist the updated file" として、GitHub-hosted runner のようなジョブごとに破棄される環境では、ジョブ開始時に Secret から auth.json を復元し、ジョブ終了時にリフレッシュ後の auth.json を Secret に書き戻す（round-trip）構成が示されています
本記事では GitHub-hosted runner（ephemeral）を使うので、ルート 2 の round-trip パターンを Step C で完成させます。
 動かす手順 Step A: 手動起動版（workflow_dispatch のみ） A-1: ローカルで codex login して auth.json を作るまず、手元のマシンで Codex CLI をインストールし、ChatGPT サインインします。インストール手順は Codex CLI 公式ドキュメントを参照してください。
codex --version
codex login
ブラウザが開いて ChatGPT サインインを求められるので、Plus / Pro アカウントでログインします。完了すると ~/.codex/auth.json が作成されます。
中身が ChatGPT 管理の認証情報になっていることを確認します。
jq '{auth_mode, has_tokens: (.tokens != null)}' ~/.codex/auth.json
auth_mode が "chatgpt"、has_tokens が true であれば OK です。
 A-2: 検証用 private リポジトリ に workflow YAML を作るGitHub に private リポジトリ を 1 つ用意します。public リポジトリで auth.json を Secret に入れると、fork からの PR で漏えいするリスクがあるため、必ず private にします。
リポジトリのルートで .github/workflows/codex-review.yml を以下の内容で作成します。
name: Codex Review (auth.json bring-in)

on:
  workflow_dispatch:

jobs:
  codex-review:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'

      - name: Install Codex CLI
        run: npm install -g @openai/codex@latest

      - name: Prepare CODEX_HOME with auth.json
        env:
          CODEX_AUTH_JSON: ${{ secrets.CODEX_AUTH_JSON }}
        run: |
          CODEX_HOME="$RUNNER_TEMP/codex-home"
          mkdir -p "$CODEX_HOME"
          chmod 700 "$CODEX_HOME"
          printf '%s' "$CODEX_AUTH_JSON" > "$CODEX_HOME/auth.json"
          chmod 600 "$CODEX_HOME/auth.json"
          cat > "$CODEX_HOME/config.toml" <<'TOML'
          cli_auth_credentials_store = "file"
          model = "gpt-5.5"
          TOML
          echo "CODEX_HOME=$CODEX_HOME" >> "$GITHUB_ENV"

      - name: Run codex exec
        run: |
          codex exec \
            "このリポジトリをレビューし、リスクと改善案を Markdown でまとめてください" \
            -o codex-review.md

      - name: Upload review as artifact
        uses: actions/upload-artifact@v4
        with:
          name: codex-review
          path: codex-review.md
          if-no-files-found: warn
CODEX_HOME を $RUNNER_TEMP/codex-home に切っているのは、runner がジョブごとに破棄される性質で、ユーザのホームと混ぜずにジョブごとに独立した作業領域を確保するためです。
このファイルを リポジトリ に commit して push します。
 A-3: auth.json を GitHub Secret として登録ローカルの auth.json の中身を、GitHub Secret として登録します。
gh secret set CODEX_AUTH_JSON --repo OWNER/REPO < ~/.codex/auth.json
< ファイル の入力リダイレクトでファイルの中身を標準入力に流し込んでいるので、auth.json の内容がコマンドライン引数にも環境変数にも、シェル履歴にも残りません。
 A-4: workflow を手動起動gh workflow run codex-review.yml --repo OWNER/REPO
このコマンドは workflow YAML の on: workflow_dispatch を発火させます。
 A-5: artifact をダウンロードして結果を確認実行の結果を確認します。
# 起動コマンドの出力に表示される URL の最後の数字が RUN_ID
# 完了するまで待つ
gh run watch <RUN_ID> --repo OWNER/REPO

# artifact（codex-review.md）をダウンロード
gh run download <RUN_ID> --repo OWNER/REPO --dir ./output

# Codex が生成したレビューを見る
cat ./output/codex-review/codex-review.md
これで Step A は完了です。手動起動で codex exec を CI 上で 1 回動かせることが確認できました。
 Step B: push 自動起動版（push トリガー追加） B-1: YAML の on: に push トリガーを追加Step A の YAML の on: セクションに、push: branches: [main] を追加します。
on:
  workflow_dispatch:
  push:
    branches: [main]
これを commit して push します。
 B-2: push で workflow が自動起動することを確認何か変更を main に push すると、workflow が自動で起動するようになります。
date >> README.md
git add README.md
git commit -m "Trigger CI for verification"
git push
この push をトリガーに、GitHub Actions が codex-review.yml を起動します。これで「本物の CI として動く」ことが確認できました。
 Step C: round-trip 完成版（書き戻し追加で公式ルートに乗る） C-1: なぜ書き戻しが必要かStep B までの構成では、CI ジョブの中で auth.json がリフレッシュ（access token と refresh token が新しいペアに更新される）されても、その更新後の auth.json はジョブ終了時に runner ごと破棄されます。次回ジョブは、毎回 GitHub Secret に入っている「最初に登録した auth.json」から始まります。
これは refresh token の有効期間内であれば動きますが、いずれ refresh token が長期間使用されず無効化されると、ローカルで codex login をやり直して Secret を入れ直す手作業が必要になります。
公式 advanced ガイドが ephemeral runner 向けに示す round-trip パターンは、ジョブ終了時にリフレッシュ後の auth.json を Secret に書き戻すことで、次回ジョブも最新の auth.json から始められるようにするものです。これで、refresh token は CI が動き続ける限り自動更新され続けます。
 C-2: Secret 書き換え用の PAT を発行GitHub Secret を書き換えるには、ジョブ内で gh secret set を実行する必要があります。GitHub Actions が自動発行する GITHUB_TOKEN には Secret 書き換え権限が含まれていないため、Secret 書き換え権限を持つ Personal Access Token（PAT）を別途用意します。
GitHub の PAT 発行画面（https://github.com/settings/personal-access-tokens/new）を開いて、以下の設定で fine-grained PAT を発行します。
Repository access：Only select repositories で、対象の private repo を指定
Repository permissions：Secrets を Read and write に設定
Expiration：短めに設定（30 days 程度）
 C-3: PAT を別の Secret として登録発行した PAT を、GH_PAT_FOR_SECRET_WRITE という名前で Secret に登録します。対話モードを使うと、PAT 文字列をシェル履歴に残さずに登録できます。
gh secret set GH_PAT_FOR_SECRET_WRITE --repo OWNER/REPO
# プロンプトが出るので、PAT 文字列を貼り付けて Enter
 C-4: YAML に書き戻しステップを追加Step B の YAML の Run codex exec の後ろに、Secret に書き戻すステップを追加します。
      - name: Persist refreshed auth.json back to Secret
        if: always()
        env:
          GH_TOKEN: ${{ secrets.GH_PAT_FOR_SECRET_WRITE }}
        run: |
          gh secret set CODEX_AUTH_JSON \
            --repo "${{ github.repository }}" \
            < "$CODEX_HOME/auth.json"
ポイントは 3 点です。
if: always()：codex exec が失敗してもこのステップを必ず実行します。codex exec の中で auth.json が既にリフレッシュされている可能性があるので、たとえジョブが失敗していてもリフレッシュ後の auth.json を救う必要があります
env: GH_TOKEN：gh CLI は GH_TOKEN 環境変数を見て認証します。Secret 書き換え権限を持つ PAT をここで渡します
< "$CODEX_HOME/auth.json"：ファイルの中身を標準入力で gh secret set に流し込みます。auth.json の内容がコマンドラインにも環境変数にも、GitHub Actions のログにも残りません
これを commit して push します。
 C-5: 動作確認push をトリガーに workflow が動きます。完了したら、Secret の更新時刻を確認します。
gh api repos/OWNER/REPO/actions/secrets/CODEX_AUTH_JSON --jq '{name, updated_at}'
push する前の updated_at と比較して、ジョブ実行後に時刻が更新されていれば、書き戻しが成功しています。
今回の検証では、


時刻(UTC)
できごと


2026-06-02 09:52:30Z
ローカルから auth.json を Secret に初回登録

2026-06-02 15:07:03Z
round-trip 1 回目成功（CI が書き戻し）

2026-06-02 15:17:40Z
round-trip 2 回目成功（前回書き戻された Secret からスタートし、また書き戻し）

という形で、Secret 内の auth.json が連続して更新されることを確認できました。
これで公式 advanced ガイドが ephemeral runner 向けに示す round-trip パターンが、Plus / Pro 個人ユーザ + GitHub-hosted runner でも完成しました。
 まとめ本記事では、ChatGPT Plus / Pro 個人ユーザが Codex CLI を GitHub Actions の CI / CD で動かす方法として、ChatGPT サブスク認証の auth.json 持ち込み方式を実機検証しました。
やれたことは以下です。
Plus / Pro 個人ユーザでも、self-hosted runner を用意せず GitHub-hosted runner で Codex を CI 実行できた
公式 advanced ガイドが ephemeral runner 向けに示す round-trip パターンまで完成した
手動起動・push 自動起動の両方で動作確認済み
制約と注意点も改めて整理します。
auth.json はパスワード相当の認証情報。public リポジトリ や fork PR では使えない
同じ auth.json を複数 runner で同時に使うと、refresh token rotation が競合して失敗する
refresh token が長期間使われないと無効化される（公式ドキュメントでは 8-day rule として言及）
多くの CI / CD 用途では OpenAI API キー方式が標準推奨ルートで、本記事の方式は公式に "advanced" と位置づけられている
 アペンディックス以下では、今回の検証で、個人的な事情で起こってしまった問題などを取り上げていきます。
 A. パス取り違えが refresh_token_reused の原因だった本記事の検証で、最初に起こった問題がrefresh_token_reused エラーでした。4 回連続で同じエラーが出続け、真因がしばらく見えませんでした。
 起きたことGitHub Actions の Run codex exec ステップで、毎回次のエラーが出ました。
... refresh_token_reused ...
refresh_token_reused というエラー文字列を文字どおりに読むと、「すでに使われた refresh token を再使用しようとした」という意味です。
 原因の正体自分は事前に、ローカルで「CI runner 相当の環境」を再現する練習として、export CODEX_HOME=~/codex-ci-home を設定して別ディレクトリで codex login を試していました。
その後、GitHub Actions 本番の検証に移行したとき、シェルに残った export CODEX_HOME=~/codex-ci-home の存在を忘れていました。codex login をやり直したつもりでも、書き込み先は ~/codex-ci-home/auth.json だったのです。
一方、GitHub Secret には ~/.codex/auth.json（古いまま、リハーサル前にできた auth.json）を渡し続けていました。
つまり、
ローカルの最新 auth.json（refresh token B）は ~/codex-ci-home/auth.json にあった
Secret には古い auth.json（refresh token A）が入っていた
古い refresh token A は、ローカルの codex login でリフレッシュ済み ＝ 既に無効化済み
CI が refresh token A を使おうとして、サーバから「もう使われている」と拒否された
これが refresh_token_reused の正体でした。
 なぜこれで refresh_token_reused になるかOAuth refresh token rotation のしくみとして、refresh token は 1 回使うと無効化され、新しいペアに置き換わる動作になっています。codex login をやり直した時点で、それまでの auth.json に入っていた refresh token はもう使えません。
そのため「古い auth.json を Secret に入れ続けている」状態は、CI が動き始めた瞬間に必ず refresh_token_reused を引き起こします。
 同じ事故を避けるためのチェック観点refresh_token_reused が出たら、以下を確認します。
echo $CODEX_HOME で、いまのシェルがどこを CODEX_HOME と認識しているか
ls -la ~/.codex/auth.json と ls -la $CODEX_HOME/auth.json のタイムスタンプを比較
Secret に入れた auth.json と、いま codex login で更新された auth.json が同じファイルか
並列実行や競合を疑うと同時に、まずパスを確認するのも大切かもしれません。
 B. 競合仮説はすべて誤りだった原因にたどり着くまで、自分は「ローカルで何かがトークンを取り合っているのではないか」と疑って、3 つの仮説を検証しました。結果はすべて誤りでした。
仮説 B-1: VS Code 拡張競合

VS Code の Codex 拡張がローカルで auth.json をリフレッシュしてしまい、CI 側のトークンが先に無効化されている、という仮説。pkill で拡張プロセスを止めても再現したため、誤りでした
仮説 B-2: Codex.app デスクトップアプリ競合

macOS のデスクトップアプリ Codex.app がバックグラウンドで動いている、という仮説。osascript で終了しても再現したため、誤りでした
仮説 B-3: macOS keychain 競合

macOS の keychain に古い認証情報が残っていて、ファイル方式と競合している、という仮説。security find-generic-password で OpenAI / Codex 系のエントリを検索したところ、そもそも keychain にエントリが存在しなかったため、誤りでした
「ファイル方式（cli_auth_credentials_store = "file"）に切り替えると keychain 方式と取り合うのではないか」という直感は、少なくとも今回の環境では成立しませんでした。
 C. 公式ドキュメントが示す 2 ルートの整理OpenAI 公式の Maintain Codex account auth in CI/CD (advanced) では、auth.json を CI で維持する方法として 2 つのルートが示されています。両ルートの構造を整理します。
 達成したいこと両ルートとも、目的は共通で、「Codex がリフレッシュした最新の auth.json を、次のジョブでも使い続けたい」です。
refresh token rotation の前提により、毎回のジョブで auth.json は新しいペアに更新されます。この最新値を次のジョブまで引き継げるかどうかが、運用の肝になります。
 ルート 1: self-hosted runner + persistent CODEX_HOME公式原文 "The simplest fully automated setup is a self-hosted GitHub Actions runner with a persistent CODEX_HOME" として推奨されているルートです。
自分で用意したマシン（自宅サーバ、AWS EC2、社内サーバなど）に GitHub Actions の runner エージェントをインストールし、そのマシン内に永続化された CODEX_HOME（例：/var/lib/codex/home/）を作って、そこに auth.json を置き続けます。マシンは自分の所有物なので、ジョブが終わってもファイルが残り続けます。
立ち上げコスト：高い（マシン準備 + runner エージェント設定 + OS / セキュリティ運用）
運用コスト：低い（一度立ち上げてしまえば、auth.json はずっとディスク上に居続ける）
壊れやすさ：runner が生きている限り安定
 ルート 2: ephemeral runner + round-trip公式原文 "Ephemeral runners: restore, run Codex, persist the updated file" として、GitHub-hosted runner のような ephemeral 環境向けに示されているルートです。
GitHub Secret を「永続ストレージ」として使い、ジョブの中で次の流れを回します。
ジョブ開始時：Secret から auth.json を $CODEX_HOME/auth.json に復元
codex exec 実行：Codex CLI が必要に応じて refresh token をリフレッシュし、$CODEX_HOME/auth.json を更新
ジョブ終了直前：更新後の auth.json を Secret に書き戻す（上書きする）
次回ジョブ：書き戻し後の Secret から復元 → また同じループ
立ち上げコスト：低い（runner を自分で運用する必要がない）
運用コスト：中（書き戻しが失敗すると次回ジョブが正常に動かなくなる）
壊れやすさ：書き戻し失敗で、次回 refresh_token_reused
本記事の Step C は、このルート 2 を完成させたものです。
 D. round-trip 実装の動作証跡Step C で完成させた round-trip 構成の、実装と動作証跡を整理しておきます。
 書き戻しステップの完全版 YAML- name: Persist refreshed auth.json back to Secret
  if: always()
  env:
    GH_TOKEN: ${{ secrets.GH_PAT_FOR_SECRET_WRITE }}
  run: |
    gh secret set CODEX_AUTH_JSON \
      --repo "${{ github.repository }}" \
      < "$CODEX_HOME/auth.json"
 PAT 発行と Secret 登録の手順GitHub の fine-grained PAT 発行画面で、対象リポジトリ限定 + Secrets: Read and write の権限で PAT を発行
gh secret set GH_PAT_FOR_SECRET_WRITE --repo OWNER/REPO の対話モードで PAT を Secret に登録
 動作証跡：Secret の updated_at 連続更新筆者の検証では、次のタイムスタンプで Secret の更新が連続的に行われたことを確認できました。


時刻(UTC)
できごと


2026-06-02 09:52:30Z
ローカルから auth.json を Secret に初回登録

2026-06-02 15:07:03Z
round-trip 1 回目成功（CI が書き戻し）

2026-06-02 15:17:40Z
round-trip 2 回目成功（前回書き戻された Secret からスタートし、また書き戻し）

 意味するもの公式 advanced ガイドが ephemeral runner 向けに示す round-trip パターンが、ChatGPT Plus / Pro のサブスク認証 + GitHub-hosted runner（GitHub が用意する使い捨ての ubuntu-latest）で実際に成立することを、実機で確認できました。
self-hosted runner を用意する必要はなく、GitHub Actions の標準機能と PAT 1 つで、公式の正規ルート 2 に乗せられます。
 E. 並列・連続実行の観測検証中、同じ Secret を使って連続実行したり、手動起動と push トリガーを近い時刻に走らせたりしました。少なくともこの範囲では、refresh token rotation の競合に相当するエラーは出ませんでした。
ただし、これは挙動を保証するものではありません。サンプル数が少なく、本当に同時刻に複数ジョブが auth.json を読みに行ったわけでもありません。本格的に並列ジョブを組む場合は、公式ドキュメントの注意通り、ワークフロー側で concurrency を設定して同時実行を直列化するのが安全です。「小規模な利用範囲では問題が出なかった」程度の話として読んでください。
 参考リンクMaintain Codex account auth in CI/CD (advanced): https://developers.openai.com/codex/auth/ci-cd-auth
Codex Authentication: https://developers.openai.com/codex/auth
Codex Non-interactive mode: https://developers.openai.com/codex/noninteractive
Codex CLI: https://developers.openai.com/codex/cli
ーーーーーーー

市田拓馬
時刻(UTC)	できごと
2026-06-02 09:52:30Z	ローカルから auth.json を Secret に初回登録
2026-06-02 15:07:03Z	round-trip 1 回目成功（CI が書き戻し）
2026-06-02 15:17:40Z	round-trip 2 回目成功（前回書き戻された Secret からスタートし、また書き戻し）
はじめに

やってみた要約

今回扱う内容

前提知識

codex exec とは

auth.json とは

CODEX_HOME とは

access token と refresh token のしくみ

runner の種類

公式ドキュメントが示す 2 ルート

動かす手順

Step A: 手動起動版（workflow_dispatch のみ）

A-1: ローカルで codex login して auth.json を作る

A-2: 検証用 private リポジトリ に workflow YAML を作る

A-3: auth.json を GitHub Secret として登録

A-4: workflow を手動起動

A-5: artifact をダウンロードして結果を確認

Step B: push 自動起動版（push トリガー追加）

B-1: YAML の on: に push トリガーを追加

B-2: push で workflow が自動起動することを確認

Step C: round-trip 完成版（書き戻し追加で公式ルートに乗る）

C-1: なぜ書き戻しが必要か

C-2: Secret 書き換え用の PAT を発行

C-3: PAT を別の Secret として登録

C-4: YAML に書き戻しステップを追加

C-5: 動作確認

まとめ

アペンディックス

A. パス取り違えが refresh_token_reused の原因だった

起きたこと

原因の正体

なぜこれで refresh_token_reused になるか

同じ事故を避けるためのチェック観点

B. 競合仮説はすべて誤りだった

C. 公式ドキュメントが示す 2 ルートの整理

達成したいこと

ルート 1: self-hosted runner + persistent CODEX_HOME

ルート 2: ephemeral runner + round-trip

D. round-trip 実装の動作証跡

書き戻しステップの完全版 YAML

PAT 発行と Secret 登録の手順

動作証跡：Secret の updated_at 連続更新

意味するもの

E. 並列・連続実行の観測

参考リンク

関連記事

EVENTS

`codex exec` とは

`auth.json` とは

`CODEX_HOME` とは

A-1: ローカルで `codex login` して auth.json を作る

A-2: 検証用 private リポジトリに workflow YAML を作る

B-1: YAML の `on:` に push トリガーを追加

A. パス取り違えが `refresh_token_reused` の原因だった

なぜこれで `refresh_token_reused` になるか

ルート 1: self-hosted runner + persistent `CODEX_HOME`

動作証跡：Secret の `updated_at` 連続更新
