[BUG] workspace-write 调用外部工具可能导致卡死

[Wsrsq]

系统环境

nodejs: v24.13.0
npm: 11.6.2
pnpm:10.30.0
model: deepseek-v4-pro
HEAD: 47f9438
渠道: 官网
操作系统: Windows 10 家庭版 19045.6466

复现方式

workspace-write 模式下令其调用外部工具时稳定触发，且无法停止生成，刷新后网页无反应。只能kill强行关闭。

AI 反馈(仅供参考)

1. Windows 沙箱首次授权：同步 FFI + 全树 ACL 传播（最可能卡住你的那一个）

你运行的外部命令（pwsh）默认走 workspace-write 沙箱。首次执行时，harness 要在工作区根目录 E:\Projects\deepseek-harness 上物化一个带继承的写权限 ACE：

packages\sandbox\sandbox-local\src\index.ts 的 materializeAclGrant() → grant.add(workspaceRoot, true)，同步执行在主线程上
packages\sandbox\sandbox-windows-acl\src\acl.ts 的 grantWrite() 通过同步 FFI 调 SetNamedSecurityInfoW，写入 OI|CI 继承 ACE
Windows 会同步地把这个 ACE 热传播到整棵树的每个文件。代码自己的注释就写着："it would otherwise re-propagate the identical ACE across the whole tree (eager inheritance; minutes on large workspaces)"
这个仓库有 node_modules、大量构建产物，传播一次就是几分钟。这期间主线程被 FFI 调用占死 → 页面刷新排队、点停止排队，什么反应都没有。

2. 中止路径自己就是同步的：spawnSync('taskkill')

packages\subprocess\subprocess-local\src\spawn.ts:281：

ts
复制
spawnSync('taskkill', ['/PID', String(pid), '/T', '/F'], { stdio: 'ignore' })
你点"停止"→ 触发 kill → 走到这里。spawnSync 是同步阻塞且没有超时。正常情况几十毫秒，但一旦 taskkill 被杀毒软件钩住、或目标进程处于不可中断的内核等待，主线程就永远卡在这个调用里——这就是"没办法中止"的直接原因。

3. 输出收集用同步文件写入

spawn.ts 的 OutputCollector.spillAll() 用 openSync/writeSync/closeSync：命令输出超过 64KB 就溢出到临时文件，全部在主线程同步写。磁盘慢或被实时防护扫描时会逐块阻塞。

（另外 sandbox-windows-acl\src\spawn.ts:214 的 waitForExit 是 WaitForSingleObject(INFINITE) 同步 FFI，不过它跑在 runner 子进程里，不直接卡主线程，只是子进程不退出时 harness 会一直等。）

[RayRiver]

我也遇到了，大项目似乎必现

[nokkies]

Verified all three parts of that analysis against source. It is right, and the strongest evidence is that the code documents the cost itself.

The three claims, checked

sandbox-local/src/index.ts — materializeAclGrant is a synchronous method (private materializeAclGrant(...): AclTempCapability, no promise anywhere), and it calls grant.add(workspaceRoot, true) inline.

sandbox-windows-acl/src/acl.ts — export function grantWrite(api, path, sidPtr): void is likewise synchronous, driving SetNamedSecurityInfoW through the FFI bindings.

subprocess-local/src/spawn.ts:281 — spawnSync('taskkill', ['/PID', String(pid), '/T', '/F'], …).

The self-incriminating comment

grantWrite's own JSDoc explains why it skips the apply when the exact ACE already stands:

it would otherwise re-propagate the identical ACE across the whole tree (eager inheritance; minutes on large workspaces)

That skip is an optimization for the second and later runs. It says nothing about the first. On first authorization the ACE does not exist yet, so the apply happens — and "minutes on large workspaces" is the code's own estimate of what that costs. A checkout with node_modules and build output is exactly the large workspace it means.

So the reported shape matches: stable on first external-tool call in a big project (大项目似乎必现), fine afterwards, and fine in small workspaces.

Why nothing responds during it

This is the part worth being precise about, because it constrains the fix. The FFI call is synchronous on the main thread, so the event loop is not merely busy — it is stopped. The web page's refresh, the stop button, and the websocket writes are all queued behind a call that is not going to yield until Windows finishes walking the tree.

That also means a progress message cannot rescue this. Emitting "granting workspace write access, this may take minutes" before the call looks like the cheap fix, but the main thread blocks immediately afterwards, so the frame never flushes to the browser. The user sees the same dead UI, only now the harness believes it warned them. Anything that reports progress has to come from somewhere other than the thread that is blocked.

Which leaves moving the work off the main thread as the only change that actually helps — the FFI call in a worker, with the main loop free to serve the UI and honour a cancel. The spawnSync('taskkill') abort path is the same bug in miniature and would want the same treatment; today "stop" blocks the loop it is trying to rescue.

One thing worth measuring before designing

Whether the cost is the ACE propagation or the enumeration: SetNamedSecurityInfoW with OI|CI on a tree has to touch every child, and node_modules is pathological for file count rather than bytes. If so, excluding the workspace's ignored directories from the grant — rather than granting the root inheritably — would attack the cause instead of the symptom, though it is a larger change to the security model and needs its own argument about what the sandbox then permits.

(Not reproducible on my side at a useful scale, so I have verified the mechanism rather than the timing. If anyone hits it, the useful measurement is wall-clock for the first grant.add against the workspace's file count.)

[nokkies]

I said above I could not supply the timing. I can now — measured it, and it calibrates the problem in a way that is worth knowing before anyone designs a fix.

Method

Applied an OI|CI inheritable ACE to a synthetic tree root and timed the apply. Deliberately granted to the current user, who already had access, so nothing's effective permissions changed — this measures the propagation cost alone. Used .NET SetAccessControl rather than the harness's FFI, so the number is the OS's, without harness overhead on top.

Result: cost tracks FILE COUNT, and is linear

files	apply
1,000	118 ms
5,000	788 ms
20,000	3,407 ms

≈ 0.17 ms per file, clean linear scaling.

Structure does not matter. The same 20,000 files spread across 510 directories nested 8 deep took 3,082 ms — no worse than 20 shallow directories. So a real node_modules, which is pathological for nesting, is no more expensive per file than a flat tree. Only the count matters, which makes extrapolation reliable.

What that means in practice

The harness checkout on this machine holds 75,004 files (56,632 of them in node_modules), which projects to roughly 12–13 seconds of blocked event loop on first authorization.

That reframes the report slightly, and I think usefully:

• A typical repo is not "minutes" — it is ten to fifteen seconds. That is still a total freeze: no refresh, no stop, no websocket. It is precisely long enough for a user to conclude the harness has hung and start clicking things, which then queue behind it and land all at once. It matches "卡死 … 刷新后网页无反应" better than a multi-minute freeze would, because after ~13 s it does come back — by which time several queued actions fire.
• "Minutes" needs a genuinely huge workspace. At 0.17 ms/file you need ~350,000 files for one minute and ~1,000,000 for three. Those exist — a monorepo with many node_modules, or a workspace holding build output and caches — so the JSDoc's estimate is not wrong, it is just describing the tail rather than the common case.

Why this matters for the fix

A 13-second freeze is bad but survivable; a 2-minute freeze is not. Since the cost is linear in file count and the workspace root is what gets the inheritable ACE, the size of the blast radius is entirely determined by what is inside the granted root — which is the argument for scoping the grant rather than only moving it off-thread. Moving it to a worker fixes the UI freeze at every size; scoping it (excluding node_modules, build output, caches) attacks the cost itself and would take the common case from ~13 s to well under a second.

Both are worth doing, but they are independent, and the off-thread move is the one that makes the tail case tolerable at all.

(Caveat: measured on one Windows 11 machine, local SSD, Defender active. Absolute numbers will vary; the linearity and the structure-independence are the parts I would rely on.)

[nokkies]

Fixed locally. Two findings from doing it are worth more than the patch, because both are things the obvious approach gets wrong.

Making confine() async does not work

That was my first attempt, and the compiler killed it. confine() is synchronous because the shell seam is:

abstract start(spec: ShellExecSpec): ShellProcess

start() returns a process, not a promise, across six implementations, and it is consumed inside tool-bash/tool-pwsh job callbacks. Threading a promise through confine() therefore converts a sandbox change into a shell-seam refactor — far more blast radius than this bug justifies. (ffi.ts already documents the constraint: win32Sync exists because "the sandbox seam's server-side per-session grant materializes ACEs inside the synchronous confine() call, which cannot await.")

So the apply moves to the runner

The confinement runner is already spawned per call and already runs with the caller's token. Moving the standing workspace ACE there costs the seam no authority — it still chooses the SID, the path, and when a grant is needed — and the host never blocks. The cost lands where a slow tool call is expected, and refresh/cancel/websocket keep working throughout.

The part I would flag hardest: make it opt-in

My first version had the runner grant whenever --write-sid was present. That broke an existing test:

paired SIDs: the runner trusts caller-owned private-temp grants and materializes nothing itself

which pins a real safety property — the runner does not widen access beyond what the caller established. It asserts that with paired SIDs and no caller-side workspace grant, the child's workspace write is DENIED.

Rewriting that test to match the change would have been the wrong move. The right one is an explicit --grant-workspace flag: the test passes unchanged, the runner still materializes nothing unbidden, and the seam opts in. The existing --write-sid equality check then proves the applied SID is exactly workspaceWriteSid(--workspace), so the flag cannot be used to grant anything else. It fails closed in read-only and in the agentless flow, where it could not mean anything.

Anyone implementing this upstream should keep that shape. Implying the grant from --write-sid is the version that looks simpler and quietly removes a guarantee.

What it does and does not fix

It removes the freeze, not the cost. The first call in a large workspace still takes the propagation time — ~13 s for a 75k-file checkout on my measurements above — because that is real work Windows has to do. The difference is that the harness stays alive and interruptible while it happens.

Shortening it needs the other lever: scoping what sits under the granted root. That is a change to what the sandbox permits, not a performance tweak, so it wants its own decision rather than riding along with this one.

[Meowrium]

Independent reproduction on 0.1.6-alpha.1 (Windows 10 19045, Node v26.3.0) — two additions to the data already in this thread

The trigger here is the PTC run_code tool, not pwsh. Under the ptc agent preset run_code is the model's only tool, so the first tool call in a large workspace goes straight into ctx.sandbox.confine() → materializeAclGrant() → AclWriteGrant.add(workspaceRoot, true) → grantWrite() → SetNamedSecurityInfoW. Same freeze, same fingerprint:

• curl http://127.0.0.1:<port>/ connects (1 ms) and then never answers (000 after 10–15 s); port stays LISTENING, process alive, never recovers.
• Zero session-log writes store-wide (all sessions, not only the stuck one); the last durable event is the tool/call.
• No child processes at all; memory flat (417 MB).
• CPU keeps ticking at ~1.5–4 % over 20 s samples (kernel-side, consistent with the KernelModeTime note above).
• The tool's own 120 s wall-clock deadline never fires — the event loop is stopped, so no timer runs. That is what makes it unrecoverable in place.
• Killing the host releases the byte-range lock in %TEMP%\dsh-acl-locks\<sha256(path)>.lock (so the blocked host is the lock holder). Worth recording: after killing it, re-running the same grant.add() on that path still blocks, so the block is inside the apply, not lock contention with another process.

Timing through dsh's own FFI path — a script that calls workspaceWriteSid() / AclWriteGrant.create() / grant.add(root, true) directly, i.e. exactly what the seam runs, synchronously:

tree	grant.add()
empty directory	2 ms
synthetic 30,000-file tree	12,107 ms
empty directory (repeat)	2 ms

That is 0.40 ms/file — the same linear shape as the .NET baseline measured above (0.17 ms/file), about 2.4× the absolute value because the FFI path adds the readCurrentDacl + SetEntriesInAcl merge on top of the apply.

The affected workspace here is a git checkout with 330,091 files counted inside a 100 s cap (counting did not finish), which puts it in the "minutes" tail of that model and matches the >290 s unfinished run I measured against the real directory. Consistent with 我也遇到了，大项目似乎必现.

One detail that may matter for the fix: the exact-ACE skip only fires for an ACE that is both explicit and exactly matching — hasExactGrant requires AceFlags === 3, and an inherited ACE carries INHERITED_ACE, so it can never match. A workspace root whose DACL is entirely inherited (every icacls line shows (I), no explicit ACE of its own) therefore always pays the full apply on first use. That is the state of the checkout here, and it is the state of any fresh checkout.

Status on 0.1.6-alpha.2 (current newest on npm): not fixed. Diff of every package that could carry a fix:

• dsh-sandbox-windows-acl: a lazy-require refactor only (import koffi from "koffi" → createLazyRequire("koffi")). withPathLock, grantWrite, hasExactGrant, readCurrentDacl, mergeAndApply are unchanged.
• dsh-sandbox-local: lib/ byte-identical.
• dsh-sandbox-policy, dsh-bash-sandbox, dsh-win32-process: identical / lazy-require only.
• dsh-ptc-runtime-node: one unrelated hunk (ELECTRON_RUN_AS_NODE env filtering).
• No new sandbox/ACL package in alpha.2's dependency list.

The grantWrite JSDoc already carries the code's own estimate ("eager inheritance; minutes on large workspaces") in alpha.1 — the cost is known, and it is still unbounded and synchronous.

The workaround also holds for the PTC path. DSH_PERMISSION_MODE=danger-full-access makes ptc-runtime-node short-circuit confinement entirely (policy.mode === "danger-full-access" ? void 0 : await this.ctx.sandbox.confine(...)), so no ACE is materialized; run_code then works on the same 330k-file workspace. This corroborates the #3155 UPDATE 5 confirmation, which was for the pwsh/bash-style tools.

Happy to share the two probe scripts (probe-materialize-grant.mjs for the timing above, probe-acl-locks.mjs for the %TEMP%\dsh-acl-locks holder check) if they are useful to whoever implements the runner-side grant.

（中文摘要：同一 bug 的独立复现 —— 触发工具是 PTC 模式的 run_code（该模式下属下模型只有这一个工具，所以必然吃到 confine() 里的 ACL 授权）；0.1.6-alpha.2 仍未修（相关包只是懒加载重构）；实测 dsh 自己的 FFI 路径下 3 万文件 = 12.1 s（≈0.40 ms/文件），而本机受影响的仓库有 33 万+ 文件，首次授权 >290 s 都没跑完；另发现"精确 ACE 跳过"对纯继承 DACL 的工作区根永不生效（继承 ACE 带 INHERITED_ACE，AceFlags 不为 3），所以全新 checkout 必然付全额传播成本。规避手段 DSH_PERMISSION_MODE=danger-full-access 对 run_code 同样有效。）