Codex CLIの認証情報をauth.jsonの平文保存からmacOS Keychainに切り替える

Codex CLIの認証情報をauth.jsonの平文保存からmacOS Keychainに切り替える

2026.04.27

どうも!オペ部の西村祐二です!

Codex CLI は、現在時点(codex-cli 0.125.0)ではデフォルトで認証トークンを ~/.codex/auth.json に平文で保存します。Issue #14704 でも扱いが議論されており、自分の業務PCでこのままで良いか気になっていました。

調べたところ、codex には cli_auth_credentials_store という設定があり、保存先をOSのキーリング(macOSならKeychain)に切り替えられると分かりました。本記事では、macOS環境で auth.json 平文保存からKeychain保存に切り替える手順をまとめます。

結論

~/.codex/config.toml のトップレベルに次の1行を追加し、codex login で再ログインします。これで以後の認証情報は macOS Keychain に保存され、auth.json は使われなくなります。

~/.codex/config.toml
cli_auth_credentials_store = "keyring"

この記事で分かること:

  • cli_auth_credentials_store が取りうる4つの値(file / keyring / auto / ephemeral)の挙動
  • なぜ auto ではなく keyring を選ぶのが安全側か
  • macOS で実際に切り替える手順と、状態確認のコマンド

前提条件

動作環境:

  • macOS(Apple Silicon環境で確認)
  • Codex CLI(codex-cli 0.125.0 で動作確認)

背景: デフォルトでは何が起きているか

2026-04-27時点(codex-cli 0.125.0)では、cli_auth_credentials_store を指定していない既定状態で codex login を済ませると、~/.codex/auth.json が作られます。手元の環境で中身のキーを確認すると次のようになっていました。

$ ls -la ~/.codex/auth.json
.rw-------@ 4.4k <USER> 23 Apr 16:45 /Users/<USER>/.codex/auth.json

$ jq -r 'keys' ~/.codex/auth.json
[
  "OPENAI_API_KEY",
  "auth_mode",
  "last_refresh",
  "tokens"
]

パーミッションは 0o600 でユーザー本人しか読めない状態にはなっています。ただし OPENAI_API_KEYtokens(id_token / refresh_token を含むJSON)は平文で入っていました。

昨今、npmやVS Code拡張などを経由したサプライチェーン攻撃の話題を目にする機会が増えたこともあり、同じユーザー権限で動くプロセスから読める平文ファイルがホームディレクトリに残っていると、こうした経路で巻き込まれるリスクは無視できないと感じます。

Issue #14704 でも、auto モードでキーリングが使えなかったときにユーザーに気付かれないままファイル保存にフォールバックする挙動が、バグとして報告されています(2026-04-27時点では未解決)。

cli_auth_credentials_store の4つの値

設定値は codex-rs/config/src/types.rsAuthCredentialsStoreMode enum で定義されています。

保存先 キーリング失敗時のフォールバック こんなときに
file(デフォルト) $CODEX_HOME/auth.json に平文JSON -(最初からファイル保存) 何も設定していないときの既定
keyring OSキーリングのみ しない(エラー) 平文ファイルを作りたくない
auto キーリング → ダメならファイル する(auth.jsonに書く) キーリングが使える環境/使えない環境を行き来する
ephemeral プロセス内メモリのみ -(永続化しない) ワンショット利用、CIなど

$CODEX_HOME は環境変数で上書きできますが、未設定なら ~/.codex です。

auto は便利そうに見えますが、キーリングへの保存に失敗するとユーザーに警告を出さずに auth.json 側に書き込みます。「平文ファイルを作りたくない」が今回の目的なので、フォールバックしない keyring を選ぶのが安全な選択になります。

OS別のキーリング実装は codex-rs/keyring-store/Cargo.toml で次のように分岐しています。

  • macOS: Apple Keychain(Security framework)
  • Linux: Secret Service(GNOME Keyring / KWallet 等のD-Bus API)
  • Windows: Credential Manager

設定手順

1. config.toml に1行追加

~/.codex/config.toml のトップレベルに以下を追加します。テーブルセクション([xxx] の下)ではなく、ファイル先頭に置けば確実です。

~/.codex/config.toml
cli_auth_credentials_store = "keyring"

2. 設定変更だけでは認証情報は移行されないことを確認

設定を書き換えても、既存の auth.json の中身がKeychainにコピーされるわけではありません。手元の環境で --config オプションで値を切り替えながら codex login status を実行すると、状態の違いが見えます。

$ codex login status --config cli_auth_credentials_store=file
Logged in using ChatGPT

$ codex login status --config cli_auth_credentials_store=auto
Logged in using ChatGPT

$ codex login status --config cli_auth_credentials_store=keyring
Not logged in

fileauto ではログイン済みと表示されているのに、keyring だけ Not logged in になっています。これは現状の認証情報が auth.json 側にしかないためです。Keychainにはまだ保存されていません。

念のためKeychainを直接見てみても、Codex Auth というサービス名のエントリは存在しません。

$ security find-generic-password -s "Codex Auth"
security: SecKeychainSearchCopyNext: The specified item could not be found in the keychain.

3. codex login で再ログイン

keyring 設定にした上でログインし直します。

codex login

完了後に codex login status を実行すると、keyring 経由でも Logged in を返すようになりました。

$ codex login status
Logged in using ChatGPT

$ codex login status --config cli_auth_credentials_store=keyring
Logged in using ChatGPT

security find-generic-password でKeychainを直接覗いてみると、svce="Codex Auth" のエントリが実際に作られています。

$ security find-generic-password -s "Codex Auth"
keychain: "/Users/<USER>/Library/Keychains/login.keychain-db"
version: 512
class: "genp"
attributes:
    0x00000007 <blob>="Codex Auth"
    0x00000008 <blob>=<NULL>
    "acct"<blob>="cli|xxxxxxxxxxxxxxxx"
    ...
    "svce"<blob>="Codex Auth"
    "type"<uint32>=<NULL>

acctcli|<sha256ハッシュの先頭16桁> 形式で、$CODEX_HOME のパスから生成されます。実装は codex-rs/login/src/auth/storage.rscompute_store_key を参照してください。GUIで確認したい場合は、Keychain Access.app で「Codex Auth」を検索しても同じ項目が表示されます。

4. auth.json の確認

keyringcodex login に成功すると、内部的に auth.json の削除も試みられます(storage.rsKeyringAuthStorage::save)。手元でも実際に再ログイン後は auth.json が消えていました。

$ ls -la ~/.codex/auth.json
"/Users/<USER>/.codex/auth.json": No such file or directory (os error 2)

ただし設定変更だけして再ログインしていない場合は古いファイルが残ります。気になる場合は、明示的に削除しておくと確実です。

rm ~/.codex/auth.json

まとめ

  • Codex CLIの認証情報はデフォルトで ~/.codex/auth.json に平文保存される
  • cli_auth_credentials_store = "keyring" を設定し、再ログインすればmacOS Keychainに移せる
  • auto はキーリング保存に失敗するとファイル保存に戻るため、平文保存を避けたい場合は keyring を選ぶのが良さそう
  • auth.json は、再ログイン後に残ってないか確認し、残っていれば手動で削除するのが確実

Codex CLIを使う場合は、検討する価値がありそうです。

誰かの参考になれば幸いです。


参考リンク:

この記事をシェアする

関連記事