Codex の保存と履歴管理：生成したコードを確実に残す方法
Codex が書いてくれたコードが「どこに保存されたのか分からない」「承認したはずの変更が見当たらない」という戸惑いは、使い始めの段階でよく起きる。Codex はサンドボックス内でコードを書き、ユーザーが承認したタイミングで初めてファイルシステムに反映される仕組みだ。生成したコードがどこへ行くのか、設定や会話履歴がどこに残るのかを把握しておくだけで、作業ファイルの紛失や設定の再入力といった無駄を防げる。本記事では Codex の保存先と履歴管理の仕組みを、承認フローから ~/.codex ディレクトリの構造まで順に整理する。
Codex が生成したコードの「保存」は、承認(approval)のタイミングで初めてファイルシステムに書き込まれる点が特徴だ。Codex は隔離されたサンドボックス環境でコードを編集し、差分をユーザーに提示する。ユーザーが承認を出すまで変更は手元のワーキングディレクトリに反映されないため、承認前にセッションを閉じると変更が消えることがある。approval_policy を on-request に設定しておけば、変更を提示するたびに確認を求めてくるため、意図せず変更が消える事故を防げる（出典: https://developers.openai.com/codex/sandbox ）。
Codex の内部データは ~/.codex/ ディレクトリにまとまっており、セッション履歴・認証情報・設定ファイルがここに保存される。CODEX_HOME 環境変数でパスを差し替えれば、マシン間で設定を持ち運んだり、プロジェクトごとに設定一式を分けたりできる。git と連携して Codex が生成したコードをコミット単位で管理するのが、変更を確実に残す最も安全な方法だ（出典: https://developers.openai.com/codex/auth ）。
セッション会話の記録は ~/.codex/sessions/ に保存され、codex resume で呼び出せる。ただし無制限には保存されないため、重要な指示や生成コードはgit やドキュメントに別途記録しておくことで、後からセッションが読めなくなっても再現できる状態を維持できる。設定ファイル config.toml も同じディレクトリに置かれ、バックアップしておけば再セットアップの手間を省ける（出典: https://developers.openai.com/codex/config-basic ）。
目次 (8)
Codex の承認フローとコードが保存される仕組み
Codex が出力するコードは、生成された瞬間にファイルに書き込まれるわけではない。Codex はサンドボックス内で変更を生成し、差分(diff)をユーザーに提示する。ユーザーが「承認(approve)」を選択した時点で、変更がワーキングディレクトリに反映される仕組みだ。この承認フローは config.toml の approval_policy で制御でき、on-request（都度確認）・on-failure（失敗時のみ確認）・never（自動承認）の三段階がある（出典: https://developers.openai.com/codex/sandbox ）。
承認前の差分は「保留中」の状態であり、Codex を終了したり別のタスクを始めたりすると、未承認の変更は破棄されることがある。「Codex が書いたコードを保存できていない」という状況の多くは、承認前にセッションが閉じられたケースだ。approval_policy を on-request に設定しておけば、Codex が変更を提示するたびに確認を求めてくるため、意図せずコードが消える事故を防げる。特にエージェントモードで長時間タスクを委ねる際は、途中の確認ポイントを設けておくことが大切だ。
承認した変更はワーキングディレクトリに直接書かれ、git で管理されているリポジトリならそのまま git diff で確認できる。git status で変更ファイルを確認し、問題なければ git add && git commit でコミットするのが基本の流れだ。エラーが起きて変更をすべて取り消したい場合は、git restore . で承認前の状態に戻せる。Codex を v0.142 stable（2026年6月22日安定版）以降で使うと、トークン予算の追跡機能が追加されており、長時間タスクでも意図しない過剰消費を防ぎやすくなった（出典: https://github.com/openai/codex/releases ）。
~/.codex ディレクトリに保存されているもの
Codex が内部的に扱うデータは、既定で ~/.codex/ ディレクトリに集約される。このディレクトリには認証情報・設定ファイル・セッション履歴の三種類が格納されており、それぞれが Codex の利用体験に直結する。ディレクトリの構造を理解しておくことで、設定の移行やセッションの管理がスムーズになる。マシン交換やチームへの展開を想定している場合は、このディレクトリを把握することが出発点になる。
認証情報（auth.json）
~/.codex/auth.json には、ChatGPT アカウントのトークンや API キーが保存されている。codex logout を実行するとこのファイルから資格情報が削除され、次回起動時に再認証が必要になる。バックアップしても認証トークンには有効期限があるため、そのままコピーして別マシンに使い回すことは推奨されない。アカウントを切り替えたい場合は codex logout の後に codex login で入り直すのが正しい手順であり、codex login status で現在の認証状態をいつでも確認できる（出典: https://developers.openai.com/codex/auth ）。
設定ファイル（config.toml）
~/.codex/config.toml は Codex の動作を規定する設定ファイルだ。使用するモデル・承認ポリシー・サンドボックスの範囲などを記述でき、起動のたびに読み込まれる。この設定ファイルを git で管理しておけば、マシンを移行した際も同じ設定を素早く再現できる。IDE 拡張の歯車アイコンからも同じファイルを開けるため、CLI と拡張で設定が共有される点も覚えておくと便利だ。設定の詳細は別記事Codex の設定ファイル config.toml の書き方と推奨設定で扱っている（出典: https://developers.openai.com/codex/config-basic ）。
セッション履歴（sessions/）
セッションの会話記録は ~/.codex/sessions/ に保存され、codex resume で呼び出せる。セッションファイルには会話のやり取りと各種メタデータが含まれており、後から指示内容を確認できる。ただし保存容量や保持期間には上限があり、古いセッションは削除されることがある。重要なプロンプトや生成結果は、セッション消失に備えてドキュメントや git コミットメッセージに別途記録しておくのが賢明だ。セッション再開の操作手順については別記事Codex のセッション再開｜resume で前回の続きからを参照してほしい（出典: https://developers.openai.com/codex/cli/features ）。
CODEX_HOME で設定と履歴を使い分ける
CODEX_HOME 環境変数を設定すると、Codex が参照するホームディレクトリを ~/.codex/ 以外のパスに変更できる。この仕組みを使うと、複数の設定プロファイルを切り替えたり、プロジェクトごとにセッション履歴を分離したりするのが容易になる。チームメンバーが共通の設定を使いたい場合も、CODEX_HOME を揃えるかベース設定を共有リポジトリに置く形で対応できる。
仕事用と個人用の設定を分けたい場合を例にすると、仕事用の作業を始める前に export CODEX_HOME=~/.codex-work をシェルで実行してから codex を起動すると、~/.codex-work/config.toml が読み込まれ、仕事用の設定一式が適用される。個人の作業に戻るときは unset CODEX_HOME でデフォルトに戻せる。シェルプロファイル（.bashrc や .zshrc）に別名(alias)を定義して切り替えを簡略化するパターンも効果的だ。なお、CODEX_HOME の変更はアカウント切り替えとセットで使うと特に有効で、複数アカウントの設定をパスで分けることができる（出典: https://developers.openai.com/codex/auth ）。
CODEX_HOME 配下のディレクトリを定期的にバックアップしておくと、マシン交換や再セットアップ後も設定・セッション履歴を復元しやすい。特に config.toml は設定に手間をかけているなら必ず管理対象にしておきたい。~/.codex/config.toml を git リポジトリとして管理し、複数のマシンやチームメンバー間で同期する運用は、プロジェクト全体で一貫した Codex の動作を保つ有効な手段だ。
Codex 生成コードを git で管理するパターン
Codex が生成した変更を確実に残す最も実用的な方法は、git でリポジトリを管理しながら Codex を使うことだ。Codex はサンドボックス内でテストやコマンドを実行し、最終的な変更をワーキングディレクトリに書き出す。git で追跡されていれば、どの時点でどんな変更が加えられたかを記録として残せる。Codex が自律的に複数ファイルを書き換えた場合も、git の diff で全体像を把握しやすくなる（出典: https://developers.openai.com/codex/cli/features ）。
Codex と git を組み合わせる基本のパターンは次のとおりだ。
- タスクを始める前に
git statusで変更がクリーンな状態であることを確認する。 - Codex にタスクを投入し、差分が提示されたら内容を確認してから承認する。
- 承認後に
git diffで実際に加えられた変更を確認する。 - 問題がなければ
git addでステージングし、git commitでコミットする。
この流れを守ることで、Codex が行った変更と自分が手動で行った変更を区別して管理できる。コミットメッセージに「Generated by Codex」などの注記を添えておくと、後から変更の由来を追跡しやすい。エラーが起きて変更をすべて取り消したい場合は、git restore . で未コミットの変更を破棄できる。
Codex のエージェントモードで長時間タスクを実行する場合、タスク完了後にまとめて変更をレビューしてからコミットするのが安全な手順だ。codex resume で前回セッションを継続しながら作業を積み重ね、区切りのいいところでコミットするリズムを身につけると、生成コードの管理がシンプルになる。Codex が書いたコードを一時保存したい場合は git stash で変更を一時退避させ、確認が済んだら git stash pop で復元するという使い方も有効だ（出典: https://developers.openai.com/codex/sandbox ）。
まとめ — 「保存された」を当たり前にする習慣
Codex の保存に関するトラブルの多くは、承認フローを理解していないか、git による追跡ができていないかのどちらかだ。承認ポリシーを on-request に設定し、変更を都度確認してから受け入れる習慣をつければ、意図しない消失はほぼ防げる。設定ファイル config.toml は ~/.codex/ に一ファイルで保存されており、バックアップするのは容易だ。
Codex が生成したコードを確実に手元に残すためのポイントをまとめると次のとおりだ。
approval_policyをon-requestに設定して変更を確認しながら進める（出典: https://developers.openai.com/codex/sandbox ）。- git 管理されたリポジトリの中で Codex を使い、変更を適宜コミットする。
config.tomlを定期的にバックアップし、マシン移行に備える。CODEX_HOMEで設定プロファイルを分けてプロジェクトごとの設定を管理する（出典: https://developers.openai.com/codex/auth ）。- 重要なプロンプトや指示は、セッションが古くなる前にドキュメントや git コミットメッセージに写しておく。
Codex を使い込むほど、保存と追跡の仕組みへの理解が重要になる。承認フローと git の組み合わせを日常のフローに組み込んでしまえば、「生成したコードが消えた」という状況は起きなくなる。v0.142 stable 以降のトークン予算追跡と組み合わせれば、長時間の自律タスクもコストと成果の両面で管理できる（出典: https://developers.openai.com/codex/cli/features ）。
