【Bug Report】workspace-write下 bash 的 /tmp 与 fs 工具的 /tmp 不是同一个目录

[tsx8]

现象

• fs 工具（write/edit）：进程内围栏，writableRoots() = 工作区 + /tmp + os.tmpdir()（宿主目录，持久）。
• bash 工具（Linux，bwrap 档）：--ro-bind / / + --tmpfs /tmp。每条命令一个全新 tmpfs，退出即弃，宿主 /tmp 不可见。
• 互不可见：bash 写进 /tmp 的文件，fs 工具读不到，反之亦然。
• 版本 rc.7

实例

步骤	观察
bash 解压 tarball 到 /tmp/fcr-src	同一次调用内 ls 成功
下一条 bash 访问 /tmp/fcr-src	No such file or directory
grep 工具访问同路径	No such file or directory
agent 推理（记录原文）	"Perhaps /tmp is sandboxed per-call … Let me extract into the workspace instead, e.g. .tmp-fcr-src, and clean up afterward"

此后全部中间产物（.tmp-fcr-src、.tmp-librime、.tmp-cache、.deploy-test、.verify、.nix-cache-tmp）落在工作区，靠收尾 rm -rf 兜底；会话中断即残留。

信息缺口

• sandbox:policy 上下文只写 "Some platform temporary areas may also be writable"。
• bash 工具描述未提及 /tmp。
• 上述两者均未说明：哪个目录、是否跨调用持久。

各后端 /tmp 语义

后端	/tmp
bwrap（Linux 默认）	每次调用新 tmpfs，不持久
Landlock（退路）	宿主 /tmp，持久
Seatbelt（macOS）	/tmp + 每用户临时目录，持久
Windows ACL	会话级私有 <temp>\dsh-<hash>，会话内持久

建议

1. bwrap 档 --tmpfs /tmp → --bind /tmp /tmp。同 Codex（codex-rs/linux-sandbox/src/bwrap.rs，可写根原地 bind，tmpfs 仅掩蔽 denyRead）。
2. 或会话专属临时目录 + 重写 $TMPDIR（Claude Code 方案；Windows 档已是此模型）。

两者均需配合：工具描述或 sandbox:policy 上下文中写明临时目录语义。

[zoahdev]

补充核验（当前 main 99f6f02，2026-08-17），你的表格与代码引用全部成立，再补三个帖子里没展开的点：

1. "每条命令一个全新 tmpfs" 的准确范围：只对 bash 工具成立

tool-bash 是 one-shot：每次调用走 ctx.shell.run(ctx.shell.resolve(...))（packages/shell/tool-bash/src/index.ts），每次 spawn 一个 bash 进程，bwrap 的 --tmpfs /tmp 随进程退出即弃——所以 bash 工具确实每条命令一个 tmpfs。

但 terminal.create（packages/terminal/tool-terminal/src/index.ts）是持久 PTY：bash 进程活多久，tmpfs 就活多久。也就是说 bwrap 档下实际上有两套语义：

入口	bwrap /tmp 生命周期
bash 工具（one-shot）	每次调用全新，退出即弃
terminal.create/send（持久会话）	随会话存活，会话内跨调用可见

fs 工具一律看宿主 /tmp（packages/fs/fs-sandbox 进程内围栏 + packages/sandbox/sandbox/src/roots.ts:52-55 的 writableRoots()）。所以"跨调用"问题只在 bash 工具出现；持久终端与 fs 工具之间则是"互不可见"（tmpfs vs 宿主），和你观察一致。

2. Windows 档是第二类不对称，不是同一类

README（packages/sandbox/sandbox-windows-acl/README.md）写明：windows-acl runner 在 spawn 前用 SetEnvironmentVariableW 把 TMP/TEMP 改写为会话私有目录（注释里自己说这是 "bwrap tmpfs 语义"），而 fs 围栏只授权 workspaceRoot + /tmp + os.tmpdir()。所以 Windows 上 bash 的 TMP 指向会话私有 <temp>\dsh-<hash>，该目录不在 fs 授权内：bash 写 TMP 的文件 fs 工具读不到，反过来 fs 工具写宿主 temp 的文件 bash 也看不到。这是"私有临时目录模型"下独有的一类不对称，建议在帖子里单列一行。

3. 改方向前注意 pin 住现状的测试

bwrap 的 tmpfs 是有意的，不是疏忽：packages/sandbox/sandbox-local/tests/bwrap.e2e.ts 有一条 workspace-write mounts an EPHEMERAL /tmp 测试，注释写明 "the strongest of the three temp semantics"，并断言宿主 /tmp 不被触碰；local.spec.ts 也断言 profile args 含 tmpfs。你的方案 1（--bind /tmp /tmp）会把 bwrap 档从"最强语义"降级为与 Landlock/Seatbelt 一致（宿主 /tmp 跨会话持久），需要同步改这两处测试并更新 sandbox RFC 里的 "honest per-runner differences" 记录。

我的倾向和方案 2 一致（会话级私有临时目录 + $TMPDIR 重写，Claude Code 模型；Windows 已经是这个模型），并建议无论选哪条，都先把语义写进 bash 工具描述和 sandbox:policy 上下文——你们报告里的"信息缺口"是最容易立刻修复的部分，零行为变更，但能避免 agent 把中间产物落进工作区然后靠 rm -rf 兜底（你们的实例里正是这样）。