秘密を置かない作業環境 ＋ 読み取りを拒否する設定。まず、この二つを組み合わせます。

読み取り専用・承認・学習オフは、それぞれ役割が違います。秘密ファイルへのアクセスを止められるか、別々に確認しましょう。

「読む」「実行する」「送る」を別々に確認

読む範囲

不要な秘密を作業環境から外す。対象ファイルには読み取り拒否の deny を検討。

境界を越える操作

承認先を確認。Full accessや、サンドボックス外での実行許可で境界を広げない。

通信と別のツール

コマンドの通信、モデルへの送信、ブラウザ・MCPなどをそれぞれ確認。

一つのスイッチで、すべての読み取り・通信・学習利用を止める仕組みではありません。

2026年10月8日にOpenAIのPermissions、Sandbox、承認・セキュリティ、設定資料を確認。以下はローカルのサンドボックス内コマンドを中心とする解説です。設定例の実機適用・拒否動作は未検証で、端末やアカウントの設定は変更していません。

目次

1. 読み取り専用・承認・学習設定の違い

「ファイルを変更できない」と「ファイルを読めない」は別です。

read-only

書き込みを制限するモード。読めるファイルの内容を秘密として遮断する機能ではありません。

workspace-write

編集できる範囲の指定。読み取り範囲も同じ場所だけになるとは限りません。

制御主に決めることこれだけでは保証しないこと
読み取り専用ファイルを変更できるかアクセス可能な秘密ファイルを読まないこと
承認の方針境界を越える操作を誰が審査するか許可範囲内の読み取りでも毎回人が確認すること
ファイルのdeny対象パスへの読み書きを拒否すること貼り付け済みの内容や、別のツール経由のアクセスまで消すこと
コマンドの通信制限サンドボックス内コマンドの通信先モデル・認証・ブラウザ・MCP等の全通信を止めること
学習設定処理されたデータをモデル改善に使うか処理や送信そのものをしないこと

on-requestでも、許可範囲内のコマンドは追加承認なしで実行できます。人による確認を求めるなら、承認の方針と審査先の両方を見ます。

AIによる自動審査との違い

approvals_reviewer = "auto_review"は対象の審査をAIに回す設定です。人による確認ではなく、もともと許可された操作すべてに審査を追加する設定でもありません。

出典：OpenAI：承認とサンドボックスの境界。学習についてはChatGPT・Codexの学習設定と機密情報で別に整理しています。

2. まず秘密を作業環境から分ける

画面の修正なら、ソースと架空のデータで足りる場合があります。本番のAPIキー、顧客データ、家族の書類まで同じ環境へ置く必要はありません。

別フォルダへ移すだけでは不十分です。広い読み取り権限が残れば、移したファイルにも到達できる場合があります。

作業用コピーには、必要なものだけ

1
ソースと架空データを用意

本番データの代わりに、問題を再現できる小さな入力を使う。

2
秘密の値を持ち込まない

環境設定の例は項目名だけにする。ログ・バックアップ・履歴も確認する。

3
その環境への権限を確認

別フォルダやホーム、共有領域、接続アプリへ到達できないかを見る。

作業コピー、別ユーザー、コンテナなどでも、共有フォルダや渡した認証情報があれば、その範囲は別に確認します。
Gitの無視設定で読み取りを止められる？

.gitignoreはGitが無視する未追跡ファイルの指定です。OSの読み取り権限をなくす仕組みではありません。検索ツールが普段は無視する場合でも、直接パスを指定した読み取りまで拒否する保証にはなりません。すでにGitで追跡されたファイルにも、後から追加した無視設定だけでは効きません。Git公式：gitignoreの対象。

作業指示と技術的な拒否の違い

AGENTS.mdに「秘密を読まない」と書くことは、作業指示として役立ちます。ただし、それ自体でOSのアクセス制限を作るわけではありません。指示と技術的な拒否を重ねるのが基本です。入力を匿名化する具体例はAIに入力するときの注意点も参考にしてください。

3. 読み取りを拒否する設定例

Permission profilesはベータ機能です。対応環境と、今のセッションで選ばれている設定を確認してから使います。

read：読み取り

対象を読む権限

write：編集

対象への書き込みを許可

deny：拒否

対象の読み取りと書き込みを拒否

旧sandbox設定との併用に注意
旧設定が残ると、Permission profilesが使われない場合があります。

競合する設定と管理者制御を確認する

旧設定と混ぜない：default_permissionsと[permissions]は、旧来のsandbox_mode・[sandbox_workspace_write]と併用する方式ではありません。通常は読み込まれる設定にsandbox_modeがあるか、起動時に--sandboxを渡すと旧方式が使われます。管理者のallowed_permission_profilesによる制御は別の条件です。

以下は、公式の作業範囲限定の例に、秘密ファイルの拒否と人による承認を組み合わせた説明用の設定案です。既存設定を丸ごと置き換えず、対応版・組織の制約・必要な実行パスを確認し、ダミーの環境で検査してください。

設定を書く場所：ユーザー用とプロジェクト用
ユーザー設定

~/.codex/config.toml

プロジェクト設定

.codex/config.toml

適用範囲と読み込み条件が異なります。プロジェクト設定は、信頼したプロジェクトでのみ読み込まれます。

設定例｜秘密ファイルを拒否し、コマンドの通信をオフに
default_permissions = "project-private"
approval_policy = "on-request"
approvals_reviewer = "user"

[permissions.project-private]
extends = ":workspace"

[permissions.project-private.filesystem]
":root" = "deny"
":minimal" = "read"

[permissions.project-private.filesystem.":workspace_roots"]
".env" = "deny"
".env.production" = "deny"
"secrets" = "deny"

[permissions.project-private.network]
enabled = false

この設定例で、どこが対象になる？

現在の作業領域と、追加した作業領域ごとに適用

.env拒否の対象
.env.production拒否の対象
secrets/ 以下拒否の対象
子フォルダ/.envこの例では別確認
別名の秘密・ログへの複製この例では別確認
拒否指定の範囲を示す概念図です。実機で拒否された結果ではありません。
作業領域の外

:rootで読み取りを拒否。ただし実行に必要な:minimalと、継承元が許可する一時ディレクトリは例外です。

作業領域の中

:workspaceを継承して編集を許可し、上の特定パスを拒否します。出力に埋め込まれる秘密まで捕まえる例ではありません。

設定名・複数領域・一時ファイルの補足

project-privateは、この例で付けた名前です。:workspace_rootsは現在の作業領域と追加した領域へ適用され、それぞれの直下の対象パスを指定します。secretsは同名のファイルまたはサブツリーが対象です。

作業領域の外を一切読めない構成ではありません。一時領域へ秘密をコピーしない運用も必要です。

出典：OpenAI：Permission profilesの設定・拒否・対象範囲。この例を実機で実行し、隔離が成立したことを確認した記事ではありません。

4. .envのパターンと見落としやすい範囲

対象の名前を正確に指定する方法は、場所が決まった秘密に向いています。パターンを使う場合は、*.envと.env.*が別物である点に注意します。公式の**/*.envという例だけを見て、.env.productionまで同じ条件で拒否できると思い込まないでください。

指定の例意図する対象別に確認するもの
.env作業領域直下の同名ファイル子フォルダや、名前の後ろに接尾辞が付くファイル
.env.production直下の本番設定ファイル別名の本番設定やコピー
secrets直下の同名パス以下ログやバックアップなど、別の場所への複製
**/*.env複数階層で、名前が.envで終わるファイル接尾辞付きの名前、探索深度と起動後の変更

階層の深さと、起動後の追加を確認

Linux・WSL・ネイティブWindowsでは、無制限の**を含む拒否パターンに、起動前の範囲を限定した展開が必要になる場合があります。公式はglob_scan_max_depthに1以上を指定する方法、または*.env・*/*.env・*/*/*.envのように深さを明示する方法を説明しています。深い階層を使うなら、その深さまで確認が必要です。

起動前に一致するパスを収集する経路があるため、後から作ったファイルまで拒否されるかは、使うOS・版・実行環境で確認してください。拒否パターンを「将来できる秘密も必ず守る万能の規則」とは扱いません。

権限が重なった場合、どちらが優先される？

より具体的なパス指定は広い指定を上書きできます。同じパスならdenyが優先しますが、広い拒否の中に狭い許可を作ることも可能です。追加の設定階層や、親プロファイルからの継承も確認します。

出典：OpenAI：パス・パターンによる読み取り拒否、設定の読み込み順序。プロジェクトの.codex/config.tomlは、信頼したプロジェクトでのみ読み込まれます。ファイルに書いたことと、今のセッションで有効なことを分けて確認してください。

5. 通信オフで止まるもの・止まらないもの

コマンドの通信をオフにすると、対象のサンドボックス内で実行するプログラムのネットワーク利用を制限できます。しかしCodexクライアントのモデル・認証リクエストは、コマンド用ネットワーク制御とは別です。読んだコードがモデルの文脈に渡される経路を、「コマンドの通信がオフだから送信されない」とは判断できません。

コマンド用の通信制限が届く範囲

対象：サンドボックス内

コマンド、スクリプト、その子プロセスが行う通信。

別管理：他の経路

モデル・認証、Web検索、接続アプリ、MCP、ブラウザ・Computer Use、クラウドタスク。

別管理のツールは、それぞれの接続・権限・環境の制御で確認します。

通信を許可しつつ送信先を限定する場合は、ドメインの規則に加えて、ネットワークプロキシの有効化が必要です。プロファイルに許可ドメインを書くだけでは、有効になりません。

コマンドの通信プロキシ結果
オフどちらでもコマンドの通信は許可されない
オンオフ直接通信が可能で、プロファイルのドメイン規則は適用されない
オンオンプロキシによるドメイン規則の適用、許可項目がなければ外部宛先を拒否

許可した送信先にも秘密を渡す余地はあります。ドメインを限定することは、送信内容の検査と同じではありません。サンドボックス外への実行を承認する場合も、今の拒否設定がそのまま保護するとは考えず、何を広げる承認なのか確認してください。OpenAI：通信許可とプロキシの条件。

6. 環境変数・OS・クラウドの違い

秘密はファイルだけにあるとは限りません。シェルにAPIキーが入っていれば、ファイルを拒否しても、子プロセスへ渡された環境変数から値が使われる場合があります。環境変数の引き継ぎはshell_environment_policyで別に管理します。

環境変数の自動除外：trueとfalse

true｜既定値

KEY・SECRET・TOKENを名前に含む変数の自動除外を行わない

false

その自動除外を適用する

ignore_default_excludesの設定値を比較しています。ファイルのdenyとは別の制御で、変数名による除外のため、すべての秘密を検出する仕組みではありません。

別名の変数や、プログラムが別の場所から取得する値までは守れません。setは除外処理の後に適用され、除外した変数を復活させる場合があります。OpenAI：環境変数の引き継ぎと優先順位。

Windows：サンドボックスの方式も確認

ローカルのPermission profilesはmacOS・Linux・WSL・ネイティブWindowsで案内されていますが、実装は同じではありません。Windowsではelevatedのサンドボックスがより強い方式として案内され、unelevatedは通信分離が弱く、一部の読み書きの分離設定を適用できません。対応できないポリシーは実行を拒否する説明であり、エラーが出たからFull accessへ切り替えてよい、という意味ではありません。OpenAI：OSごとの適用方法。

Cloud：手元の設定をそのまま流用しない

Codex Cloudは、そのクラウド環境の設定を別に確認します。手元のプロファイルがクラウド全体やdotのクラウド側にも自動適用されるとは考えません。この記事のローカル設定案を、そのままクラウド用の設定として流用しないでください。実行場所の違いはCodexのRemote・Cloud・PCの接続条件で整理しています。

7. ダミーファイルで確認する手順

「読まないように指示した」「設定を保存した」「実際に拒否された」は別の証拠です。実際の秘密を試し読みさせる必要はありません。以下は本人または管理者が行う確認計画で、この端末で実施した結果ではありません。

  1. 対象を記録する：Codexの版、OS、実行場所、選択中の権限を記録。CLIでは/statusで作業範囲を確認し、/permissionsで選択状態を確認する。
  2. 設定の競合を確認する：ユーザー設定、信頼したプロジェクト設定、選択したプロファイル、起動フラグ、管理者の制約を確認する。診断のために設定ファイル全体や秘密の値を会話へ貼らない。
  3. ダミーを用意する：秘密を含まない独立した作業領域で、許可するファイルと拒否するファイルを作る。内容は架空の目印にする。
  4. 許可と拒否の両方を確認する：同じ実行経路で許可対象を読めることと、拒否対象への読み取りがエラーになることを確認。Codexが自主的に読まなかっただけでは、技術的な拒否の証拠にしない。
  5. 配置の違いを検査する：直下・子フォルダ・接尾辞付き・起動後に作ったダミーを確認。拒否を越える承認は与えず、予想外に読めたらその環境の利用を止めて原因を調べる。
  6. 出力の経路も確認する：テストやビルドが秘密をログへ出さないか、別のMCP・ブラウザ・接続アプリに同じ情報が渡らないかを確認する。

CLIの版や表示によって確認できる項目は異なるため、コマンド名だけでなく実際の表示を見ます。公式CLIにはOS別のcodex sandboxによる確認方法もあります。ただし、補助コマンドで通した設定と、普段使うデスクトップやIDEのセッションで有効な設定は、同じだと確認してから扱ってください。OpenAI：サンドボックスの検査方法。

すでに読ませた内容は、後からdenyを追加しても取り消せません。過去の会話・ログ・ファイルの保存や学習設定を別に確認します。ファイルが読めたことだけで第三者へ漏れたとは断定せず、何を読んだか、どこへ渡ったか、認証情報に対応が必要かを分けて判断してください。

秘密ファイルの除外は、利用者からもCodexの公開Issueで要望されています。これは困りごとの実例で、現在の機能が未対応だと証明するものではありません。本記事では古い投稿より現在の公式Permissionsを仕様の根拠としています。

FAQ

読み取り専用なら、.envは送られませんか？

保証できません。読み取り専用は変更の制限です。読める範囲の.envをモデルの文脈へ渡さないようにするには、対象の読み取り拒否と、秘密を含まない作業環境を別に確認します。

.gitignoreやAGENTS.mdだけで十分ですか？

技術的な読み取り拒否の代わりにはなりません。Gitの無視設定、作業の指示、OSで適用する権限は別の仕組みです。現在の実行環境でdenyが効くかをダミーで確かめます。

通信をオフにすると、Codexは完全に端末内で動きますか？

いいえ。コマンドの通信制限は、モデル・認証への通信を止める設定ではありません。ブラウザ、MCP、接続アプリ、クラウドの設定も別です。

この設定例で、Windowsでも秘密を完全に守れますか？

完全な保護は保証していません。ベータ機能の対応、OSのサンドボックス方式、実際の設定階層、パス、実行するツールを確認する必要があります。本記事の例を実機で適用・検証したわけではありません。