はじめに
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 を使えるようになります。