sandbox：网页版agent会访问工作区外的文件夹？

[Lsylzx11]

输入prompt=“请分析当前项目中 Agent Runtime 的实现。”的时候，我们设定了工作区范围（但是工作区文件夹没有实现agent调用，所以应该直接回答没有）。
由于System Prompt 中给出了DSH 安装路径（允许在检查和扩展时访问），导致agent转而自由访问 DSH 安装路径下的文件夹，来实现分析 Agent Runtime

[mo-fei-work]

这应该是特性，我甚至经常用，读取dsh源码及.dsh配置能够更好的发挥其能力。
访问无所谓，是 读 行为。
它 这工作区只限定 写 行为。
不过读行为似乎包含运行行为与工具使用，这个偶尔确实有风险+吓人，沙盒是否管用也只能靠指令白名单。

[PerryLink]

先说结论：读不受工作区边界约束——这个版本里的工作区范围只对"写"生效，跨工作区读是既定行为，不是沙盒失效；审批策略也不管读，因为审批只在一个调用请求把写权限放宽时才被问到。

读和写是两个不同的范围

沙盒模式本身只描述文件效果：

• docs/subsystems/sandbox.md:11：SandboxMode 只约束 filesystem effects——read-only 要求后端拒绝写入，workspace-write 允许写工作区根和临时区，danger-full-access 不设限；文档还特意补了一句 network 与进程可见性不在这个词汇表内。
• 文件后端说得更直接：packages/fs/fs-sandbox/README.md:12 是"confines model file writes and edits … while preserving the local filesystem's read behavior"；:28 明确 reads stay unconfined；:50 是"Reads, listings, and metadata work exactly as with fs-local"。
• 进程侧同理：packages/sandbox/sandbox-local/README.md:75 说 bwrap profile 是"a read-only host root"加一个可写的工作区 bind——整机文件系统本来就可读，只有写被限制。

所以"工作区"对这两件事的含义完全不同：

	写	读
边界是什么	真围栏：目标规范化后必须落在工作区根或平台临时区内（packages/fs/fs-sandbox/README.md:46）	没有围栏，只要求后端可读
越界时	FS_SANDBOX_DENIED，工具侧给模型看 [sandbox: file access denied under <mode> mode]（同上 :50）	没有任何提示

Host 自己的读接口也是照这个契约写的：docs/subsystems/workspace.md:362（read）、:373（readBytes）、:402（stat）都写着 "absolute path or path relative to the workspace root; files outside it are allowed"，:390 的 readRelated 也写作 including outside the workspace。

哪种审批策略管"读工作区外"？

都不管。审批的消费点只有一个——把写模式升到更宽的模式：

• packages/sandbox/sandbox/src/escalation.ts:28-31 是"严格更宽"的升格表（read-only → workspace-write → danger-full-access）；:153-176 的 approveEscalation 只在请求严格更宽时才去问审批通道，:155 甚至写明目标模式与当前模式相同就直接返回、根本不问。
• 工具层把这个 ask 接到 ctx.approval（packages/core/tools/src/index.ts:1698-1721）。
• 而 ApprovalPolicy 只有 ask / never 两个值（docs/subsystems/approval.md:46）：ask 交给回答者链，never 让每个 ask 直接 rejected（:33）。换句话说，把预设切到带 never 的那一档（默认表里 danger-full-access 与 never 绑在一起，见 docs/subsystems/permission-presets.md:11）只会让"写"更紧，读的权限一点没变。

它为什么会跑去 DSH 安装路径

因为 prompt 里就写着这条路径，而且是 Web 端有意加的：packages/boot/app-boot/src/index.ts:1003-1010 会注入 harness:source 段，正文是 "The DeepSeek Harness implementation checkout is at ${sourceRoot}… Use this checkout only to inspect or extend DSH itself"；Web bundle 在 packages/bundle/web-app/src/index.ts:233-235 调用它。你让它"分析 Agent Runtime"，它手上刚好有一条"可以去看 DSH 自己"的线索，于是转向了源码——这不是沙盒漏了，是检索起点被 prompt 指到了那里。

能收紧什么

1. 只是不想让它知道这个路径：把 Web 端的 surfaceContext 设为 false（默认 true，packages/bundle/web-app/README.md:51）。闸门是 packages/bundle/web-app/src/index.ts:233，README 也写明为 false 时 harness:source、app:web-surface 两段与 DSH_WEB_URL 都不再注册（packages/bundle/web-app/README.md:131）。代价是你同时失去 GUI 上下文（"this page" 的指代、DSH_WEB_URL 等）。
2. 想连读也不给：我没有在文档里核到任何"把读限制在工作区内"的现有配置项——上面每一层都显式把读排除在外；packages/fs/tool-fs/README.md:68 只说 read/read_image 的路径授权归 ctx.fs。真要做到只有从工具层收窄（不给这个 agent 挂载文件读取类工具）。这一点标为未验证：我只确认了没找到相反证据，没有逐个核对所有 fs 工具与后端。
3. 想确认实际发生了什么：读调用会带着 file_path 参数进会话记录（read 的参数表见 packages/fs/tool-fs/README.md:46），可以直接核对它读了哪些绝对路径；审批审计里不会出现它们，因为读不产生 ask。

如果你的目标是"分析当前项目"，比较省事的做法是把工作区里该看的路径直接写进 prompt——按现在的设计，靠读围栏挡不住这件事。