対象のTopic

Codex（OpenAIのコーディング・エージェント）をdevcontainer（開発用コンテナ）の中に閉じ込めて動かすのは、 セキュリティの確保もできて、なかなか良いアイデアなのではと思いました。 ところが、vscodeで実際に試してみたところ、Codexのセキュリティの仕組みと絡んで、不都合な挙動があったので、 このやり方は公式にサポートされるまでは様子見が良いかなと今は思っています。

確認したこと

まずvscodeでdevcontainerを起動しました。 設定ファイル.devcontainer/devcontainer.jsonの中身は以下の通りです。

{
        "name": "Ruby",
        "image": "mcr.microsoft.com/devcontainers/ruby:3-3.4"
}

次に、Codex拡張をインストールしました。 その次に、Codexにソースファイルの一部を変更する指示を出したところ、 apply_patchが上手くいかないのでsedなどを代わりに使うという返答で、 変更前後のdiffが見づらい形になりました。

なお、devcontainerの設定で指定するimageは以下の2つも試しましたが、 同じ現象に遭遇しましたので、特定のイメージでのみ発生する現象ではありません。

• ruby:3.4（Rubyの公式イメージ）
• ghcr.io/openai/codex-universal:latest（OpenAIが公開している参考Dockerイメージ）

apply_patchが失敗する背景

Codexが言うには、apply_patchはbwrapという一種のコンテナの中で動かす仕組みらしく、 devcontainerというコンテナの中でbwrapというコンテナを動かす、 つまり、コンテナの中でコンテナを動かすのに失敗しているらしいです。 具体的には、devcontainerの中でbwrapのコンテナのために新しいnamespaceを作ろうとして、 permissionの問題に遭遇しているとのこと。

Codexがbwrapを使うのはセキュリティを高めるためだと思いますので、 安易な設定変更などでapply_patchを出来るようにするのは、 セキュリティ上のリスクがあると見ています。

2026年9月現在では、以下のようにdev containers内でcodexを動かす方法についてドキュメントが存在しています。 ですので、vscodeのdevcontainerでCodexを使うのは、現在では現実的な選択肢のようです。

https://learn.chatgpt.com/docs/agent-approvals-security#run-codex-in-dev-containers

AIエージェント用の安全な開発環境について調べた結果を記事に整理しましたので、ご参考まで。

https://note.com/picolab/n/nd7dbc78548df

なお、この記事の内容のポイントとしては、以下の通りです。

• 人間のcredentialを見せない
• 人間とAIのworkspaceを分ける
• AIの変更は人間が確認して取り込む
• まずはDocker Sandboxes等の既製品
• 自作するなら「つなぎ」として小さく