Open Interpreter 的 workspace-write 沙箱提示词模板模型如何知道哪些文件可以写【免费下载链接】openinterpreterA coding agent for open models like Kimi K3 and GLM 5.3项目地址: https://gitcode.com/GitHub_Trending/op/openinterpreterworkspace_write.md是 Open Interpreter本仓库沙箱权限体系中的一个提示词模板文件用于在会话开始或权限变化时向模型精确描述当前sandbox_mode为workspace-write时的文件系统读写边界与网络策略。理解这个模板如何被加载、渲染并拼进系统提示能够帮助你掌握 Open Interpreter 的权限说明生成机制、三种沙箱模式的切换逻辑以及用户配置writable_roots、network_access等参数后如何直接影响模型看到的权限说明。模板原文及其语义模板文件位于 workspace_write.md全文只有一行一个占位符模板Filesystem sandboxing defines which files can be read or written. sandbox_mode is workspace-write: The sandbox permits reading files, and editing files in cwd and writable_roots. Editing files in other directories requires approval. Network access is {{ network_access }}.拆解这句话它向模型传递了四条事实性约束声明作用域文件系统沙箱filesystem sandboxing负责划定哪些文件可读、可写当前模式sandbox_mode是workspace-write写入边界沙箱允许读取文件并允许编辑位于cwd当前工作目录与writable_roots用户额外放行的写入根目录中的文件编辑这两个范围之外的目录需要审批approval网络策略{{ network_access }}是一个运行时占位符由渲染逻辑替换为当前的网络访问状态。值得注意的是cwd与writable_roots这两个词在此处不仅是描述性文字它们与源码中的策略结构一一对应下文会印证因此模型可以据此判断一条写文件命令是否会触发审批请求。三种沙箱模式模板的对照workspace_write.md属于一个三件套。同目录下还有两个姊妹模板read_only.mdFilesystem sandboxing defines which files can be read or written. sandbox_mode is read-only: The sandbox only permits reading files. Network access is {{ network_access }}.danger_full_access.mdFilesystem sandboxing defines which files can be read or written. sandbox_mode is danger-full-access: No filesystem sandboxing - all commands are permitted. Network access is {{ network_access }}.三者措辞严格对齐都从 Filesystem sandboxing defines which files can be read or written 起头只是权限声明逐级放宽只读 → 工作区可写 → 无沙箱限制。这三个取值与 config_types.rs 中定义的模式枚举完全对应#[serde(rename_all kebab-case)] #[strum(serialize_all kebab-case)] pub enum SandboxMode { #[serde(rename read-only)] #[default] ReadOnly, #[serde(rename workspace-write)] WorkspaceWrite, #[serde(rename danger-full-access)] DangerFullAccess, }即用户在配置中可写read-only/workspace-write/danger-full-access三种取值见 config-reference.md 中sandbox_mode一行默认值是read-only。模板如何被加载与渲染模板并非独立存在的文档而是被编译期嵌入 Rust 二进制、并在运行时渲染的提示片段。核心代码在 permissions_instructions.rs编译期嵌入第 30-35 行三个.md文件通过include_str!在编译期读入常量字符串const SANDBOX_MODE_WORKSPACE_WRITE: str include_str!(../templates/permissions/sandbox_mode/workspace_write.md);并解析为Template第 41-44 行解析失败会直接 panic保证模板语法在编译产物中始终合法。运行时渲染sandbox_text函数第 294-321 行根据当前SandboxMode选择对应模板然后渲染占位符let template match mode { SandboxMode::DangerFullAccess *SANDBOX_MODE_DANGER_FULL_ACCESS_TEMPLATE, SandboxMode::WorkspaceWrite *SANDBOX_MODE_WORKSPACE_WRITE_TEMPLATE, SandboxMode::ReadOnly *SANDBOX_MODE_READ_ONLY_TEMPLATE, }; let network_access network_access.to_string(); template .render([(network_access, network_access.as_str())])其中network_access由network_access_from_policy第 209-215 行从网络沙箱策略推导策略启用则取NetworkAccess::Enabled否则取NetworkAccess::Restricted。这正是模板末尾那句 Network access is {{ network_access }} 的填充来源——同一个 workspace-write 模板在允许网络与禁止网络两种配置下会渲染出不同的最终提示。模型自定义文案的优先覆盖渲染逻辑还检查了PermissionMessagesopenai_models.rs 中定义了workspace_write: OptionString字段。如果模型元数据提供了自定义的 workspace-write 权限说明文案会优先使用该文案同样替换{{ network_access }}占位符并跳过内置模板。这意味着模板文件是内置默认值而模型侧配置可以覆盖它。注入会话的方式渲染结果被封装为PermissionsInstructions它实现了ContextualUserFragment接口第 175-191 行以developer角色、包裹在permissions instructions ... /permissions instructions标记中进入对话上下文。也就是说模型看到的是一段带明确定界标记的权限说明而不是散落在系统提示里的普通文字。何时会选择 workspace-write 模式模板的选择不是直接读用户的sandbox_mode字段而是由生效的文件系统沙箱策略推导。关键函数是sandbox_prompt_from_policy第 193-207 行fn sandbox_prompt_from_policy( file_system_policy: FileSystemSandboxPolicy, cwd: Path, ) - (SandboxMode, OptionVecWritableRoot) { if file_system_policy.has_full_disk_write_access() { return (SandboxMode::DangerFullAccess, None); } let writable_roots file_system_policy.get_writable_roots_with_cwd(cwd); if writable_roots.is_empty() { (SandboxMode::ReadOnly, None) } else { (SandboxMode::WorkspaceWrite, Some(writable_roots)) } }从源码结构看判定逻辑是分层的策略具有全盘写权限 → 渲染danger-full-access模板否则取出相对cwd的写入根列表若列表为空→ 渲染read-only模板只要至少存在一个可写根→ 渲染workspace-write模板并把该列表一并带回用于后续拼接。这与模板文本自洽模板宣称可以编辑cwd和writable_roots中的文件而选择该模板的前提恰好就是策略中确实解析出了非空的写入根。用户侧配置writable_roots 与 network_access模板中出现的两个名词writable_roots、network_access在用户配置文件里都有真实落点。config-reference.md 的 Sandbox Tables 一节给出了workspace-write模式对应的配置表[sandbox_workspace_write] network_access false exclude_tmpdir_env_var false exclude_slash_tmp false writable_roots [/tmp/project-cache]各参数含义键作用network_access是否放开沙箱内网络访问直接决定模板中{{ network_access }}渲染成启用还是受限writable_roots追加的可写根目录列表与cwd一起构成模板宣称的可编辑范围exclude_tmpdir_env_var/exclude_slash_tmp控制临时目录$TMPDIR、/tmp是否从自动放行的可写范围中排除配置文档同时提示如果需要更细粒度比如按路径 glob 拒绝、按域名放行网络的控制应改用 permissions profiles而不是把两套体系混在一个活动配置里config-reference.mddefault_permissions project-edit [permissions.project-edit.filesystem] :minimal read [permissions.project-edit.filesystem.:workspace_roots] . write **/*.env deny [permissions.project-edit.network] enabled true无论走哪条路径最终都会收敛到FileSystemSandboxPolicy再经由上一节的sandbox_prompt_from_policy决定渲染哪个模板——permissions profile 中.workspace_roots的 write 规则同样会产生非空的写入根从而落入 workspace-write 分支。模板之后的补充段落可写根清单与拒绝读取清单workspace_write.md本身只是一段输出。完整权限说明由from_permissions_with_network_and_denied_reads第 139-172 行按顺序拼接多个段落沙箱模式段落即模板渲染结果→ 审批策略段落 → 可写根段落 → 拒绝读取段落。其中与模板直接衔接的是writable_roots_text第 323-339 行它把策略解析出的写入根排序后追加为The writable roots are /tmp/project-cache.单个根时用 The writable root is ... 的单数形式。这句追加文本正是模板里 writable_roots 一词的具体展开——模型先被告知cwd 和 writable_roots 可写紧接着被告知 writable_roots 具体是哪些绝对路径使权限边界从抽象描述落到可执行的路径判断。另一个相关段落由denied_reads_text第 341-361 行生成当权限档案中显式 deny 了某些路径或 glob 时会追加 ## Denied filesystem reads 小节并明确指示模型不要为读取这些路径请求提权这些是策略级拒绝。这防止模型对策略性拒绝反复发起审批请求是 workspace-write 边界之外的重要安全补充。小结workspace_write.md虽然只有一行却是 Open Interpreter 权限体系里策略 → 提示词的转换枢纽之一它的文本语义cwd writable_roots 可写、其余目录需审批、网络状态占位符与 config_types.rs 的SandboxMode枚举、config-reference.md 的[sandbox_workspace_write]配置表一一对应它的加载与渲染由 permissions_instructions.rs 完成模式选择取决于生效策略中写入根是否为空它的运行时产物是一段带permissions instructions定界标记的 developer 上下文其中模板正文之后还会追加可写根清单与拒绝读取清单构成模型判断这条文件操作命令是否合规、是否需要请求审批的完整依据。排查权限相关问题时可以沿着配置文件 →FileSystemSandboxPolicy→sandbox_prompt_from_policy→ 模板渲染 → 最终提示文本这条链路定位如果模型对某次写操作的行为与预期不符先确认[sandbox_workspace_write]或 permissions profile 中的写入根与网络配置再看渲染进会话的权限说明是否与配置一致。【免费下载链接】openinterpreterA coding agent for open models like Kimi K3 and GLM 5.3项目地址: https://gitcode.com/GitHub_Trending/op/openinterpreter创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考