Codex CLIで2つのアカウントを使い分ける：仕事用と個人用のログインを分離する方法

個人プロジェクトと仕事のタスクでCodex CLIを併用する場合、環境やアカウントを確実に分離する方法が必要です。しかし、--profileフラグはアカウントの切り替えを用途として設計されていません。基本設定のドキュメントによると、プロファイルはメイン設定の上に$CODEX_HOME/<name>.config.tomlを重ね合わせる（使用モデル、サンドボックスレベル、MCPサーバーなどのパラメータを調整する）だけであり、アクティブな認証情報を変更するものではないからです。

異なるアカウントを利用するには、環境変数CODEX_HOMEを使って独立したディレクトリを定義し、それぞれのディレクトリに対して個別にログイン手順（codex login）を実行する必要があります。

セッションファイルの手動コピーに伴うリスク

Habrの記事では、あるユーザーによる自動化の実践例が紹介されています。その著者は、Bashスクリプトで認証ファイルを差し替えてアカウントを切り替え、未公開のWebインターフェースエンドポイント経由で残りのクォータを取得していました。しかし著者自身も指摘している通り、この構成の最大の欠点は、いつでも変更される可能性がある内部の非公開バックエンドAPIに依存している点です。

セッションファイルを直接操作することは、トークンのライフサイクルを破壊するリスクも孕んでいます。ある場所でリフレッシュトークンが更新（ローテーション）された場合、別のディレクトリにコピーした複製が無効化される可能性があります。ファイルコピー後に認証エラーが発生した同様の事例は、issue #15410にも報告されています。単一の報告だけで「コピーしたセッションファイルが必ず破損する」と断定できるわけではありませんが、手動でのファイルコピーは不要な運用リスクを生み出します。auth.jsonを直接閲覧・コピーしたり、非公開のバックエンドAPIを呼び出したりするべきではありません。標準的かつ安全な方法は、分離されたディレクトリごとにCLI自身にセッションを管理させることです。

認証情報の保存先とポリシーによる制約

ディレクトリの分離を設定する前に、認証データがどこにどのように保存されるかを理解しておくことが重要です。認証に関するドキュメントによると、設定項目cli_auth_credentials_storeでは以下のモードがサポートされています。

• file — 認証情報はCODEX_HOMEディレクトリ内のローカルファイルauth.jsonに保存されます。
• keyring — 認証情報はシステムキーリング（macOSのKeychain、LinuxのSecret Service）に保存されます。
• auto — CLIはまずシステムキーリングの使用を試み、キーリングが利用できない場合にファイルストレージへフォールバックします。
• ephemeral — セッションは実行中のプロセスメモリ上にのみ保持されます。

環境の分離を計画する際は、以下の注意点と制約を念頭に置いておく必要があります。

• 端末に組織の集中管理ポリシー（管理対象設定 / requirements.toml）が適用されている場合、CODEX_HOMEディレクトリを分けるだけでは完全な分離が保証されません。管理者が特定の認証方式やストレージタイプを強制している場合、それらのルールがローカル設定よりも優先されます。
• CLIのソースコードでは、キーリングサービスはCODEX_HOMEパスのハッシュ値によってディレクトリを識別しています（storage.rsを参照）。したがって、異なるディレクトリが自動的に単一のキーリングエントリを共有してしまうという前提は誤りです。しかし、それでもあらゆる環境で完全な分離が保証されるわけではありません。実際のストレージの挙動はプラットフォームやOSの設定に依存するため、使用する実機上で挙動を確認する必要があります。
• アクティブなストレージモードを確認するまでは、トークンがディレクトリ内のみに排他的に存在していると決めつけることはできません。

2つの環境を構築するステップ

ここでは、$HOME/.codex-personalと$HOME/.codex-workという2つの明示的なディレクトリをセットアップします。既存の~/.codexディレクトリは変更されず、そのまま保持されます。

ステップ1：ディレクトリの準備

現在のユーザーのみにアクセス権を制限したディレクトリを作成します。

mkdir -p "$HOME/.codex-personal" "$HOME/.codex-work"
chmod 700 "$HOME/.codex-personal" "$HOME/.codex-work"

組織のポリシーでファイルベースのストレージが許可されている場合は、ログインを実行する前に、各ディレクトリのconfig.tomlでcli_auth_credentials_store = "file"を明示的に指定できます。

cat << 'EOF' > "$HOME/.codex-personal/config.toml"
cli_auth_credentials_store = "file"
EOF

cat << 'EOF' > "$HOME/.codex-work/config.toml"
cli_auth_credentials_store = "file"
EOF

端末に必須の企業認証要件が適用されている場合は、管理者が承認したクレデンシャルストアモードを使用してください。

ステップ2：独立したログイン認証

ブラウザ経由の認証は、現在chatgpt.comでアクティブになっているセッションに紐づきます。ブラウザのプロフィールメニューに表示されるのは現在のWebセッションに過ぎず、特定のCODEX_HOMEにどの認証情報が保存されたかを証明するものではありません。各ブラウザログイン時には、目的のアカウントおよびWorkspaceを必ず確認する必要があります。

• 個人用環境へログインする前に、ブラウザ側で個人用アカウントに切り替えます。
• 仕事用環境へログインする前に、ブラウザ側で対応する企業アカウントまたはWorkspaceを選択します。

各環境について、個別にログイン手順を実行します。

env CODEX_HOME="$HOME/.codex-personal" codex login

env CODEX_HOME="$HOME/.codex-work" codex login

それぞれの場合で、開いたブラウザウィンドウに表示される認証要求を承認します。少しでも疑わしい点がある場合は、標準のenv CODEX_HOME="..." codex logoutを実行し、ブラウザのアクティブなアカウントを再確認した上で、対象ディレクトリに対して再度ログインを行ってください（トークンファイルを直接確認したり、手動でコピーしたりしてはいけません）。

ステップ3：ログイン状態の確認

両方のディレクトリで認証状態を確認します。

env CODEX_HOME="$HOME/.codex-personal" codex login status
env CODEX_HOME="$HOME/.codex-work" codex login status

codex login statusコマンドは認証方式を表示するだけであり、特定のユーザーの身元（アイデンティティ）を証明するものではありません。課金元の違いにも留意してください。ChatGPTログインは関連付けられたプランやWorkspaceのサブスクリプションまたは付与された上限枠を利用しますが、APIキーによるログインはOpenAI Platform側で別途課金されます。

本手順では、2つの異なるアカウントに対するChatGPTログインを想定しています。もしstatusにAPIキーが表示されている場合は目的の構成が満たされていませんので、そのディレクトリのログイン手順を見直してください。

ステップ4：テストタスクの実行

仕事用環境を検証するために、権限をread-onlyサンドボックスに制限した状態で、テスト用の作業リポジトリで実際のタスクを実行します。

cd /path/to/work-project
env CODEX_HOME="$HOME/.codex-work" codex exec --sandbox read-only "README.mdを読み、このプロジェクトの目的を説明してください。ファイルは変更しないでください"

短い読み取り専用（read-only）テストにより、セッションとサンドボックスが正常に動作していることを確認できます。テスト実行後にアカウントやWorkspaceの利用状況（Usage）画面を確認することは、反映の遅延を伴う間接的なシグナルに過ぎず、厳密な身元証明にはなりません。不安が残る場合は、env CODEX_HOME="$HOME/.codex-work" codex logoutを実行し、ブラウザでアクティブなアカウントを慎重に確認しながらログイン手順をやり直してください。

日常での利用方法

日常の開発作業では、コマンド実行時にCODEX_HOMEを直接指定するか、シェル設定ファイル（~/.zshrcまたは~/.bashrc）にヘルパー関数を定義しておくと便利です。

codex-personal() {
  env CODEX_HOME="$HOME/.codex-personal" codex "$@"
}

codex-work() {
  env CODEX_HOME="$HOME/.codex-work" codex "$@"
}

引数を"$@"経由で渡す呼び出し例：

codex-work login status

cd /path/to/work-project
codex-work exec --sandbox read-only "README.mdを読み、このプロジェクトの目的を説明してください。ファイルは変更しないでください"

codex-personal