五种沙箱 Profile
比较 workspace、devbox、read-only、strict、off 与自定义 Profile 的边界
本页解决的问题
先给结论「五种沙箱 Profile」要解决的关键问题是什么？
比较 workspace、devbox、read-only、strict、off 与自定义 Profile 的边界
让这个结论先证明自己值得留下。 把这一页当成决策工具，而不是需要背下来的定义。把概念连到一个真实任务、一个可观察结果，以及一个能改变你判断的失败上。
写下一个问题：试完这个方法后，你能用什么证据回答它？
结论听起来很完整，却没有检查最关键的假设。
能从 ProfileName 和 SandboxProfile 判断读写与网络边界，能正确配置 custom extends，并识别平台支持与降级条件。
Profile 是多维能力预设
横向位置用于帮助记忆。devbox、workspace、strict 的实际差异同时包含默认读取、可写路径与网络策略。
全文件系统默认可读；workspace、GROK_HOME、临时目录可写；不限制子进程网络。
default_read=truerestrict_network=false
全文件系统默认可读；枚举根目录，除 /data 与虚拟文件系统外广泛授予写权限；网络不限制。
/data 保持可读，在 Linux 通过 bwrap 做写保护全文件系统默认可读；workspace 不可写；GROK_HOME、临时目录和必要设备仍可写。
restrict_network=true关闭全局默认读，只开放系统运行目录与 workspace；workspace、GROK_HOME、临时目录可写。
default_read=falserestrict_network=true
跳过 capability set 应用，记录「Sandbox disabled」。它也接受别名 none。
不可作为 custom extends 的基类extends 规则
- custom 默认从 workspace 开始。
- 可 extends workspace、devbox、read-only、strict。
- 不能 extends off/none。
- 不能 extends 另一个 custom profile。
- read_only、read_write、deny 追加到基类。需要限制子进程网络时，应在 custom 中显式设置 restrict_network=true。
全局优先保护
系统先读取 ~/.grok/sandbox.toml，再读取 .grok/sandbox.toml。项目配置只能新增 profile 名称。若项目声明了全局已存在的同名 profile，merge 使用 entry.or_insert，全局定义保持生效。
文件系统约束
启用 enforce 且运行在 Unix 时，nono 将 capability set 应用到 Landlock 或 Seatbelt。macOS deny 使用 Seatbelt 规则；Linux 的子路径 read-deny 还需要 bwrap bind-over。
网络约束
主进程网络保持开放以访问模型 API。restrict_network 当前通过子进程过滤表达，源码中的 seccomp 实现在 Linux 生效，非 Linux 函数为空操作。平台边界需要按实际构建与运行环境验证。
pub enum ProfileName {
#[default]
Workspace,
Devbox,
ReadOnly,
Strict,
Off,
Custom(String),
}快照说明：枚举完整保留。光谱图用于教学记忆；真实能力来自 resolve()、essential_writable_paths() 与平台 apply 结果。
课堂练习：设计审查专用 Profile
要求能读仓库与系统工具、不能改 workspace、允许写临时目录、限制子进程网络，并额外 deny ~/.ssh。选择一个内置基类，写出 custom profile 的 extends 与 deny，并解释项目为何无法替换用户全局的同名定义。
「Profile 是多维能力预设」里的风险边界在哪里
「能从 ProfileName 和 SandboxProfile 判断读写与网络边界，能正确配置 custom extends，并识别平台支持与降级条件」把安全问题从一句“请模型不要犯错”拉回到权限、数据和环境。真正需要保护的是：模型即使判断失误，系统也不能让错误变成不可逆的结果。
把模型建议和实际权限分开
在「横向位置用于帮助记忆。devbox、workspace、strict 的实际差异同时包含默认读取、可写路径与网络策略」涉及的流程中，要分别检查用户能要求什么、模型能建议什么、工具实际允许什么，以及谁有权批准写入或发送。网页、文档和工具返回值都可能携带不可信指令，不能因为它们看起来像说明就自动提升权限。
- custom 默认从 workspace 开始
- 可 extends workspace、devbox、read-only、strict
- 不能 extends 另一个 custom profile
安全设计必须包含失败和恢复
结合「要求能读仓库与系统工具、不能改 workspace、允许写临时目录、限制子进程网络，并额外 deny ~/.ssh 。选择一个内置基类，写出 custom profile 的 extends 与 deny，并解释项目为何无法替换用户全局的同名定义」做一次反向演练：加入错误输入、缺失凭证或迟迟不到的审批，确认系统会拒绝、暂停并留下可追踪信息，而不是继续执行到底。
从「Profile 是多维能力预设」走到「五种内置 Profile 的源码语义」
「Profile 是多维能力预设」先把问题落在「横向位置用于帮助记忆。devbox、workspace、strict 的实际差异同时包含默认读取、可写路径与网络策略」上；到了「五种内置 Profile 的源码语义」，讨论继续推进到「全文件系统默认可读；workspace、GROK_HOME、临时目录可写；不限制子进程网络」。两段连起来，重点就不只是记住一个结论，而是看清它成立所依赖的条件。
把这条判断带到下一个场景
做安全判断时，把“模型想做什么”和“系统允许做什么”分开，逐个检查数据边界、工具权限、人工确认和失败后的恢复路径。
- 「Profile 是多维能力预设」：横向位置用于帮助记忆。devbox、workspace、strict 的实际差异同时包含默认读取、可写路径与网络策略
- 「五种内置 Profile 的源码语义」：全文件系统默认可读；workspace、GROK_HOME、临时目录可写；不限制子进程网络
- 「最后的要点」：read_only、read_write、deny 追加到基类。需要限制子进程网络时，应在 custom 中显式设置 restrict_network=true
最后的「最后的要点」把讨论落到「read_only、read_write、deny 追加到基类。需要限制子进程网络时，应在 custom 中显式设置 restrict_network=true 」。回看这条线索时，最值得保留的是：当输入、规模或风险改变，哪些判断需要重新做一遍。
我把这篇文章里的一个判断改写成了今天可以验证的小实验。比记住结论更有用的是，知道下一步要观察什么。
读完以后我先回头找它成立的条件，而不是直接把方法搬进项目。这个顺序让后面的取舍清楚很多。
如果把这个判断放到真实工作里，最先需要补的约束是什么？我想知道从阅读到第一次实践之间，哪一步最值得先做。
还没有这篇文章的讨论。