はじめに

Codex CLIをDevContainer 環境で使っていると、コンテナ再構築のたびにログイン状態やカスタムプロンプトが消えてしまい、毎回設定し直す必要があることに気づきました。
この記事では、Codex CLI を DevContainer 環境で安定して使い続けるために行った設定永続化の方法を注意点とあわせてまとめます。

Codex の設定とDevContainer 環境での挙動

Codex CLI は、次のような情報を ユーザーのホームディレクトリ配下(~/.codex/)に保存します。

認証情報
セッション情報
カスタムプロンプト

一方、DevContainer では、

ワークスペース外のディレクトリはコンテナ再構築時に破棄される
そのため ~/.codex/ も再構築のたびに消える

という挙動になります。
結果として、DevContainer を使う場合は

毎回 Codex にログインし直す必要がある
プロンプトや設定を都度再作成する必要がある

という状態になってしまいます。

bind mount による設定の永続化

この問題を避けるために、ホスト側の ~/.codex をコンテナに bind mount する方法を取りました。
DevContainer の設定に、次のように mount を追加します。

{
  "mounts": [
    "source=${localEnv:HOME}/.codex,target=/home/node/.codex,type=bind"
  ]
}

(/home/node については各ユーザー名に合わせて変更してください)

この構成により、DevContainer を再構築してもホスト側に保存された Codex の設定を参照するため、Codex のログイン状態やカスタムプロンプトは保持されます。

bind mountについて

ここで使っている bind mount はホスト側のディレクトリをコンテナ内に「コピー」するものではなく、同じディレクトリを両方から参照できるようにする仕組みです。
そのため、コンテナ内で ~/.codex を変更するとホスト側の ~/.codex にも即座に反映されます。
逆に、ホスト側でファイルを編集した場合もコンテナ内からその変更が見える状態になります。
このように、bind mount は「コンテナを削除・再構築してもデータはホストに残る」という用途に向いています。

注意点

bind mount を使う場合、いくつか注意点があります。

bind mount では source 側のディレクトリが事前に存在している必要がある
mount の評価は postCreateCommand より前に行われる
そのため、postCreateCommand でディレクトリを作成しても間に合わない

あらかじめホスト側で、次のようにディレクトリを作成しておきます。

mkdir -p ~/.codex

これを忘れると、DevContainer起動時にエラーが発生します。

まとめ

Codex CLI の設定は ~/.codex/ 以下に保存される
DevContainer を再構築すると、このディレクトリは失われる
bind mount を使うことで設定を永続化できる
source 側のディレクトリは 事前に作成しておく必要がある

Codex を DevContainer 環境で継続的に使う場合、設定の永続化はほぼ必須です。
最初に一度だけ mount を設定しておけば、以降は再構築を気にせず Codex を使えるようになります。