先に答え：承認なしのフルアクセスは速く回りますが、安全を決める場所がそこしか残りません
自分もこの設定で試すべきか：私のPCでは、5,285ターンのうち 4,284 ターン（81.1%）がフルアクセス・承認なしでした。workspace-write で動かした 932 ターンでは、承認を求める要求が 1,281 回出ていました（1ターンあたり 1.37 回）。
承認が頻繁に出る手間と、承認なしで進む速さの間で、フルアクセス側に寄せた結果が81%です。寄せる場合は、作業フォルダの外に大事なものを置かない、変更前の退避を取る、といった手順を先に決めます。
記録の条件
| 項目 | 内容 |
|---|---|
| 数えた日 | 2026年11月1日 |
| CLI の版 | 履歴の中の版は 0.137 から 0.147 まで。今回数えるのに使った CLI は codex-cli 0.162.0-alpha.17.2（Windows） |
| 環境 | Windows 11 の自分のPCに残る Codex の履歴（ChatGPT デスクトップアプリで使った分） |
| 期間 | 最初のセッション 2026年6月8日 〜 最後のセッション開始 2026年8月11日（履歴の中の最後の記録は10月13日） |
| 数え方の単位 | セッション＝履歴ファイル1本。この面のターン＝turn_context（承認とサンドボックスの設定が依頼ごとに書かれる記録）1件。task_started の記録数（4,493）とは一致しないが、理由は調べていない |
課題とコマンド
課題：依頼ごとの承認設定・サンドボックスの種類と、承認要求の回数を数える。
node aggregate.js
node aggregate2.js
node aggregate3.js
# 画面には件数と分類名だけを出し、本文は出さない数え方
数え方：対象は、Codex が PC に残している履歴ファイル 215 本のうち、読めた 214 本（2026年6月8日〜8月11日に始まった作業）。1本は大きすぎて読み込みに失敗したため含めていません。数えたのは Node で書いた集計スクリプト（aggregate.js）で、画面にも記録にも本文やコマンドの中身は出していません。出したのは件数と分類名だけです。ターンの数は、履歴の turn_context の記録の数です（5,285）。承認要求は、コマンド実行の引数に sandbox_permissions: require_escalated が付いたものです。
出力（集計の結果・抜粋）
{
"承認設定_ターン数": {
"on-request": 932,
"never": 4353
},
"サンドボックス_ターン数": {
"workspace-write": 932,
"danger-full-access": 4284,
"read-only": 69
},
"承認要求_require_escalated": 1281,
"理由文つき": 1281,
"prefix_rule 付き": 765,
"承認要求が出たときのサンドボックス": {
"workspace-write": 1281
}
}{
"承認要求の出力": {
"全体": 1281,
"終了コード付き_実行された": 1275,
"reject・denied などの語を含み実行されなかった": 0,
"その他_判定できず": 6
},
"上限100に達した日_tokenCountの記録数": {
"primary": {
"2026-07-12": 46,
"2026-07-14": 29,
"2026-07-13": 55,
"2026-07-30": 106,
"2026-07-25": 64
},
"secondary": {
"2026-06-09": 23
},
"primary_dayCount": 5,
"secondary_dayCount": 1
}
}計測した時間
| 集計スクリプト | かかった時間（実測） |
|---|---|
aggregate.js（種類・ターン・パッチ・承認・モデルなどを一度に数える） | 15.9 秒 |
aggregate2.js（承認要求の行方・上限100の日・8月2日と3日の呼び出し） | 15.1 秒 |
aggregate3.js（種類別の失敗・月別の権限・8月2日と3日の詳細） | 17.1 秒 |
最初に aggregate.js を回した時は18.6秒でした。上の表は、集計を作り直して回した時の値です。履歴は圧縮された状態で215ファイル・約2.5GBあります。各1回の実行です。
結果：月別の権限と、承認要求の行き先
| 月 | ターン数 | danger-full-access | workspace-write | read-only |
|---|---|---|---|---|
| 2026年6月 | 2,242 | 1,864（83%） | 378 | 0 |
| 2026年7月 | 2,521 | 1,990（79%） | 473 | 58 |
| 2026年8月 | 463 | 371（80%） | 81 | 11 |
| 2026年10月 | 59 | 59（100%） | 0 | 0 |
10月の59ターンは、8月までに始まったセッションの続きです（セッションの開始は8月11日までしかありません）。
承認の設定は never（承認を求めない）が 4,353 ターン（82.4%）、on-request（必要な時に聞く）が 932 ターンでした。on-request の932ターンは、workspace-write の932ターンと件数が一致しています（1件ずつの突き合わせはしていません）。
承認要求 1,281 回のうち 1,275 回は、そのあとコマンドが実行されて終了コードが出ていました。拒否や取り消しを示す語を含む出力は、文字で探した範囲では0回です。誰が承認したか（自分で押したか、自動の見直しか）は、ログからは数えていません。
モデルと推論の深さ（ターン数）は、モデルが gpt-5.5 2,692・gpt-5.6-sol 2,028・gpt-5.6-terra 285・gpt-5.6-luna 133、推論が medium 4,177・ultra 768・high 207・xhigh 64・low 69 でした。
利用上限に当たった日
履歴の rate_limits には primary と secondary の2つの枠の使用率が残っています。使用率が100に達した記録のある日は、primary が 7月12日・13日・14日・25日・30日の5日、secondary が 6月9日の1日でした。それぞれの枠が何時間の枠かは、ログの項目名からは分かりません。
7月は推論 ultra のターンが 692 あり、6月（0）から増えた月です。月別の増減と上限日の関係は、ここでは因果を言えません。
分かったこと
- フルアクセス・承認なしが5ターンのうち4ターンを占めた。6〜8月の月ごとの割合は79〜83%で、ほぼ変わらない。
- workspace-write は、承認を求められる要求が1ターンに1回以上出る水準だった。手間が、フルアクセスに寄った一因と考えられるが、運営者の動機はログからは分からない。
- read-only は69ターン（1.3%）。使う場面は限られた。
向かない場面
- 『81%の人がフルアクセスにしている』と読むこと。運営者1人・2か月の数字。
- 承認要求の回数を、危険なコマンドの回数とみなすこと。何を承認したかの中身は見ていない。
- フルアクセスで事故が起きる確率を、この数字から出すこと。
公式ドキュメント
- Sandbox（OpenAI 公式）（2026年11月1日に開いて確認）
- Permissions（OpenAI 公式）（2026年11月1日に開いて確認）
- Agent approvals & security（OpenAI 公式）（2026年11月1日に開いて確認）