沙箱读写模型与工作区边界

理解运行安全，先要分清两个相互配合的概念：沙箱回答"物理上允许访问和修改哪里"，审批回答"某个动作执行前是否需要人工确认"。本节聚焦沙箱读写模型与工作区边界，说明不同读写姿态的能力范围、适用阶段，以及它与审批策略如何组合，从机制上限制代理动作的影响面。

一、两种基础读写姿态

读写姿态	能力范围	典型适用阶段
只读姿态（read-only）	以阅读、检索、分析为主，不写入文件系统；适合查看现状、理解调用关系、形成方案	陌生仓库探索、只读调研、复核代码与差异
工作区可写姿态（workspace-write）	在项目工作区内进行受控文件修改，默认不越出项目边界；适合在明确方案后实现改动	方案确认后的编码、测试补充、局部重构

具体在界面或配置中如何切换档位、对应哪些键名，以当前版本官方文档与 codex --help 为准；本节先建立"能力边界"这一稳定概念，方法学不随界面演进失效。

二、工作区边界原则

• 以项目目录为默认作用域：代理的文件读写围绕当前项目工作区展开，避免把改动扩散到系统目录、用户全局配置或其他无关项目。
• 目录外访问需更谨慎：涉及工作区之外的文件、系统路径或全局设置时，应单独评估并在审批环节人工确认。
• 写入与探索分离：先在只读姿态下摸清结构，再切换到可写姿态落地方案，避免"边猜边写"造成大量回退成本。
• 资源与产物归属清晰：临时生成的文件、缓存与构建产物应落在项目约定位置并可被忽略或清理，不污染源码目录。

三、沙箱与审批的分工与组合

维度	沙箱读写模型	审批策略
解决的问题	动作在物理上能触及的范围（读还是写、写在哪里）	动作执行前是否需要人来确认授权
作用层面	限制影响边界，越界动作不被执行	把控风险动作，高敏感操作由人决策
常见起步组合	只读姿态配合保守审批，先安全探索	探索确认后，可写姿态配合常规审批进行实现
高风险组合提示	放宽写边界却无审批把关，误操作难以拦截	全自动审批配合宽沙箱，仅适合受控、可丢弃的自动化环境

四、按任务阶段选择姿态

1. 探索阶段：只读姿态优先，配合保守审批，先产出调研结论与修改方案。
2. 方案确认后实现：切到工作区可写姿态，限定在项目目录内完成受控修改。
3. 验证阶段：以运行测试、查看 git status 与 git diff 核对改动，不盲目扩大写权限。
4. 敏感或破坏性动作：安装依赖、联网、删除、修改凭证等动作单独确认，不依赖宽松的默认姿态放行。
5. 出错回退：实验性结果可通过版本控制或隔离目录回退，避免污染主线工作区。

五、FAQ

问题	处理建议
只读姿态下代理无法修改怎么办	这是预期约束；先完成调研，确认方案后再切换可写姿态实现，不要为省事直接放宽边界。
如何确认代理没有越出项目目录写文件	结合 git status 文件清单与目录约定核对；非预期位置出现的新文件要追溯来源。
沙箱档位和审批档位是不是一回事	不是：一个控制读写物理边界，一个控制执行前是否要人确认，二者应搭配使用。
界面选项与教程描述不一致	以当前版本官方文档和 codex --help 为准；"先只读探索、后受控写入"的原则保持有效。

六、动手练习

• 练习：为一个真实项目分别演练"只读调研"与"工作区可写实现"两种思路：先列出只读阶段要回答的问题清单，再列出可写阶段允许修改的目录范围与需要人工确认的动作。