[Windows] 工作区包含 TEMP 时，workspace-write 下命令执行器整体失效，且报错无可操作指引

[yanggaihao5-sys]

摘要

在 Windows 上，当会话工作区包含系统的 TEMP 目录时（本例：工作区 = C:\Users，TEMP = C:\Users\yangz\AppData\Local\Temp），workspace-write 模式下命令执行器无法启动任何进程 —— 连 echo test 都失败。文件类工具（读写/检索）不受影响。

失败不是以「降级到别的临时目录」或「明确提示改什么」的方式呈现，而是以一句无法据以行动的内部断言结束。

环境

项	值
dsh	0.1.5-rc.1（@deepseek-ai/dsh，全局 npm 安装）
Node	v24.16.0
npm	11.13.0
OS	Windows 10 家庭中文版 10.0.19045（Build 19045）
Shell	Windows PowerShell 5.1.19041.6456（Desktop 版，非 PowerShell 7）
文件策略	workspace-write
工作区	C:\Users
TEMP / TMP	C:\Users\yangz\AppData\Local\Temp

最小复现

1. 把会话工作区设为 C:\Users（即用户目录的父目录，使 TEMP 落在工作区内部）
2. 在 workspace-write 策略下执行任意命令，例如：

echo test

实际行为

命令未被执行，返回：

Error: Windows ACL temp root must be outside the workspace: workspace=C:\Users; temp=C:\Users\yangz\AppData\Local\Temp

• 连不产生任何文件写入的 echo 也失败 —— 说明该检查位于执行器启动路径上，与具体命令是否触碰文件系统无关
• 报错发生在命令实际运行之前（无任何子进程输出）
• 文件类工具（read / write / edit / glob / grep）在同一会话中工作正常，故障范围限于命令执行器

期望行为

任一即可，按偏好排序：

1. 降级到工作区外可用的临时目录（如 %SystemRoot%\Temp、或自建一个位于工作区外的 ACL 临时根），并照常执行命令
2. 若确实无法降级，报错中给出可操作的指引 —— 例如「请把会话工作区改为不包含 TEMP 的目录，或设置 DSH_TEMP_ROOT 指向 <路径>」，而不是只陈述一个内部不变式
3. 至少不要连 echo 这种零副作用的命令都阻断

影响

工作区设为 C:\Users 的场景并非罕见 —— 用户目录的父级常被当作「我的东西都在这」的默认选择（本项目文档里 C:\Users\<name>\... 这类绝对路径也很常见），而 Windows 上 TEMP 默认就在 C:\Users\<name>\AppData\Local\Temp。两者一撞，命令能力整体归零，用户只能靠文件工具干活，且从报错里看不出该改什么。

临时规避（用户侧）

把文件策略提升到 danger-full-access 后，同一命令正常执行：

python <script>.py    # workspace-write 下失败；danger-full-access 下正常

可作对照，证明问题出在该 ACL 前置检查，而非命令本身。

相关

• #9166 报告了同一族问题（其中「sandbox silently denies access outside workspace」一条与本文相邻）。该帖把 6 个问题合并陈述；本文只针对命令执行器整体无法启动这一个可独立复现的缺陷，故单独提交，避免混入其它议题后失焦。

说明

• 我没有改动任何沙箱配置，以上均为默认策略下的行为观测。
• 本报告只针对失败模式：ACL 临时根需要位于工作区之外这一约束本身是否合理，我不做判断；可改进的是失败时的降级能力与报错可操作性。
• 附带一个次要观察（可能无关，供排查参考）：此环境中命令执行器实际使用的是 Windows PowerShell 5.1（$PSEdition = Desktop，?? 运算符不被支持），与工具名 pwsh 所暗示的 PowerShell 7 不一致。

[argszero]

Confirming this from the source, and adding the facts that decide what can be fixed where — including one that is invisible from the outside: that sentence has two producers, and a fix has to satisfy both.

The check, and why it fires before any child exists

packages/sandbox/sandbox-windows-acl/src/path-boundary.ts:22:

export function assertTempRootOutsideWorkspace(workspaceRoot, tempRoot) {
  if (containsDirectory(workspaceRoot, tempRoot))
    throw new Error(`Windows ACL temp root must be outside the workspace: workspace=${workspaceRoot}; temp=${tempRoot}`)
}

The session path reaches it from packages/sandbox/sandbox-local/src/index.ts:404, as the first statement of materializeAclGrant — the routine that builds the runner argv (a standing workspace-root grant plus a private temp capability per live session/workspace pair). So the refusal happens while the invocation is being assembled: no child is created, which is exactly what you observed — echo test fails, there is no subprocess output, and the file tools are unaffected because they never spawn that runner.

containsDirectory compares realpathSync.native on both sides, so this is a canonical-containment test, not a string-prefix one.

Why the invariant exists, in the module's own words: "every child created below it would inherit the standing workspace capability." The private temp directory is meant to be the revocable half of the pair; placing it under the workspace root would put it inside the standing one, where it would stop being revocable. So this is a capability-disjointness rule, not a complaint about your setup — and danger-full-access passing is consistent rather than a workaround: with no ACL enforcement there is no standing capability for the temp root to inherit.

The lever is the environment, not a policy field

The temp root is os.tmpdir(). It is not a field on SandboxPolicy — that type carries only mode, workspaceRoot and sessionId — and there is no dsh knob that relocates it for this check. On Windows os.tmpdir() resolves through the documented GetTempPathW order: TMP, then TEMP, then USERPROFILE, then the Windows directory. So the actionable fix available today is to start dsh with TMP/TEMP pointing at a directory outside the workspace, or to choose a workspace that does not contain the temp root. The message already names both operands — it simply does not say that they are the input to a decision you can make.

Two producers of one sentence

The same assertion also runs on the child side, in the runner (packages/sandbox/sandbox-windows-acl/src/runner.ts:131, asserted for workspace-write), where fail() writes windows-acl-run: <detail> to stderr and exits nonzero. Upstream tests it as "agentless workspace-write rejects a temp root inside the workspace before spawning" (status 127, marker never written).

That split explains the shape of what you saw. A session-scoped call is refused by the parent before spawn — a thrown error in the tool result, your case. An agentless workspace-write call passes the ambient temp root through and is refused by the runner — a stderr diagnostic with a nonzero exit. One sentence, two carriers; whichever one a fix addresses, the other has to agree, because both read the same pair of paths.

read-only is deliberately unaffected: that branch passes the ambient temp root through and the runner does not assert for that mode, since nothing is granted. Your scoping of the failure to workspace-write is exactly the boundary the code draws.

On the three expectations

1. Downgrade to a temp root outside the workspace — a core change, and a policy decision: where a private capability lives, and what happens when the ambient choice is unusable, is not something a plugin should decide on the backend's behalf.
2. An actionable message — core, and the cheapest of the three: the sentence already carries both operands; what is missing is the clause that says what to do with them.
3. Do not block zero-side-effect commands — not separable from (1). The check is about the capability the executor needs to start, not about what the command touches; a command that writes nothing still spawns under the same restricted token with the same private temp root. "This command does not need the sandbox's temp root" is not a question decidable at that layer.

All three are upstream-shaped. What is reachable from outside is the diagnosis half, and that is the direction I will take: attach the remediation — both operands plus the TMP/TEMP lever — to the failure, and detect the condition before the first command of a session through the public ctx.sandboxPolicy.resolve({ session }) that the enforcing backends themselves read (mode + workspaceRoot), so a session that is about to lose its command executor says so at the start rather than at the first echo. I will report back here either way.

One adjacent observation, for completeness: the backend does ship a diagnosis skill for denials it cannot explain (registerAclDiagnosisSkill → diagnose-windows-sandbox-acl, packages/sandbox/sandbox-windows-acl/src/acl-skill.ts). This never reaches it — it is a pre-spawn invariant rather than the result of an ACL operation — which is part of why it surfaces as a bare internal assertion.

[argszero]

A stopgap for this is published, and here is what it does.

@argszero/cordis-plugin-sandbox-grant-advisor@0.15.0 —
https://www.npmjs.com/package/@argszero/cordis-plugin-sandbox-grant-advisor

It is a standalone npm plugin with its own public repository
(argszero/cordis-plugin-sandbox-grant-advisor), and it repairs nothing: no ACL
is written, nothing is elevated, no environment variable is set for another
process. This refusal is the fifth failure it covers, and the one it reports in
two places rather than one.

1. When a command is actually refused. It recognizes the producer's own
sentence with both operands, read from error.message and never from rendered
output — so a command whose own output merely quotes the sentence is an ordinary
success and is left alone. It then names which of the two carriers refused: the
session-scoped provider, while the runner argv was assembled (no child ever
existed, which is why echo test reports no subprocess output at all), or the
runner, whose line arrives behind the windows-acl-run: marker with exit 127
reclassified into a SandboxUnavailableError. The advisory states why no
icacls grant can affect this (the refusal precedes any process) and what
actually moves the condition (os.tmpdir() on Windows is GetTempPathW: %TMP%
first, then %TEMP%, then %USERPROFILE%; or a workspace that is not an
ancestor of the temp root).

2. Before the first command fails — the part this thread asked for. On
Windows, ahead of the first tracked call, the plugin asks the public
ctx.sandboxPolicy.resolve({ session }) for the session's mode and workspace
root and compares that root against os.tmpdir() with the backend's own
canonical computation (realpathSync.native on both, then path.relative — the
same computation assertTempRootOutsideWorkspace / containsDirectory performs,
mirrored rather than imported because sandbox-windows-acl is a Windows-only
package this plugin must not claim as a mandatory peer). A workspace-write
session whose workspace contains the temp root is told the environment change
before it spends a turn on an echo that cannot run. The pre-flight report prints
the three facts it computed so the claim can be audited, and states the one
verification available when no command can be run: if a command does run in the
session, the condition does not apply and the report can be ignored. The two
seats are deliberately separate — the producer's own line and the carrier it came
from are facts only the failure half can have, so a second advisory follows a real
refusal.

Mount:

- insert:
    - id: sandbox-grant-advisor
      name: '@argszero/cordis-plugin-sandbox-grant-advisor'

The advisory half is always on and blocks nothing. An optional, off-by-default
enforceAfter bounds a fail-fast half that is ACL-only by design, which is why it
does not cover this family: its remedy is not a command that repairs a running
session.

Two limits, stated plainly. The recognition and the containment are
re-implementations of the backend's own rule, so the risk that carries is
bounded on purpose: the module can only ever stay silent (a path that does not
resolve, a platform or mode the rule does not govern) or predict the refusal the
producer itself would have made — the sentence it matches on is the rule, so a
change to one changes the other. And the suite runs on macOS, where this was
built: it proves the decision layer (both carrier spellings built from the
producer's format, the containment computed on real directories rather than on
strings, the once-per-agent rule, the disclosure when a Windows host cannot answer
at all), not the Windows path itself.

Finally, since the plugin is a stopgap rather than a fix: the assertion here is
already exact and pre-spawn, so the upstream repair is not a better message but a
reachable one. This is a state the harness can detect before the first command
is dispatched — it is reported today as an internal assertion that a session can
neither read nor act on.

[yanggaihao5-sys]

Thanks — this explains more than my report did, and the two-producer split accounts for something I could not.

Confirmations from the same machine the report came from:

• echo test fails with no subprocess output at all, while read / write / edit / glob / grep all work in the same session — consistent with a refusal at argv assembly in the session-scoped provider, before any child exists.
• Raising the policy to danger-full-access makes the identical command succeed — consistent with your point that with no ACL enforcement there is no standing capability for the temp root to inherit, rather than being a workaround.

On the limit you stated — "the suite runs on macOS … it proves the decision layer, not the Windows path itself" — I can close that gap if it is useful. This machine reproduces the condition deterministically:

OS	Windows 10 10.0.19045 (Build 19045)
Workspace	C:\Users — an ancestor of os.tmpdir()
TEMP / TMP	C:\Users\<user>\AppData\Local\Temp
dsh	0.1.5-rc.1, mode workspace-write

So both seats are exercisable on a real Windows path rather than a stubbed one:

1. Pre-flight half — verify the advisory fires before the first tracked call, in a session that is about to lose its command executor.
2. Failure half — verify recognition on a real refusal, and that the carrier is identified as the session-scoped provider rather than the runner.
3. Negative case — relaunch with TMP pointed outside the workspace; the adviser should stay silent and the command executor should come back. That is exactly the lever you named, so it doubles as a check that the lever is the right one.

If that is useful, say which seat matters first and I will run it and report back with raw output.

One retraction for the record: my original report listed the PowerShell 5.1 observation as a possible clue. It is orthogonal to this defect — it concerns which shell the executor picks up, not the ACL path — so please disregard that line.

[yanggaihao5-sys]

Verdict: both seats fire on the real Windows path, in the order you described. The gap you named — "the suite runs on macOS … it proves the decision layer, not the Windows path itself" — is closed for both halves.

The environment (the condition, live)

OS	Windows 10 10.0.19045 (Build 19045)
Workspace root	C:\Users
Temp root (os.tmpdir())	C:\Users\yangz\AppData\Local\Temp
dsh	0.1.5-rc.1, mode workspace-write
Plugin	@argszero/cordis-plugin-sandbox-grant-advisor@0.15.0, mounted in the web profile

Before / after, on the same call

One echo test, no escalation, workspace-write.

Before mounting — the producer's sentence alone, one line, no advice:

Error: Windows ACL temp root must be outside the workspace: workspace=C:\Users; temp=C:\Users\yangz\AppData\Local\Temp

After mounting a fresh dsh web — two advisories, in two seats.

Seat 1 — pre-flight, before anything failed

It opened with the standing condition rather than waiting for a refusal:

Standing condition, before anything has failed: this session's sandbox has its private temp root inside the workspace it grants against. Three facts put it there: host win32 — the ACL runner is the only backend with this rule; mode workspace-write — the only mode that materializes a private temp capability; workspace C:\Users; temp root C:\Users\yangz\AppData\Local\Temp … and the last two overlap …

It also carries the falsifiability you built in, which is the right shape for a pre-flight claim:

How to read this, given that no command can be run here to check it: … That also makes the report falsifiable in one step — if a command does run in this session, this condition does not apply to your composition and this message can be ignored.

Seat 2 — the refusal's own report

Then the command was actually refused, and the second advisory arrived with it:

… the producer named the two directories it compared … Those two values are the producer's own, quoted rather than recovered here, so they are the pair the executor actually tested.

Which one this was: the PROVIDER, before any child existed — which is why this call reports no subprocess output at all: nothing ran.

So the separation you described holds on Windows too — "the producer's own line and the carrier it came from are facts only the failure half can have, so a second advisory follows a real refusal." Observed exactly that way: standing report first, refusal report after the refusal, and the standing one explicitly defers to it ("this warning is not a substitute for the refusal's own report").

What this verifies, specifically

1. The carrier split is diagnosed correctly on Windows. The failure half identified the PROVIDER branch — matching the observable signature you predicted (refusal with no subprocess output at all), not the runner branch that would arrive behind windows-acl-run: with exit 127.
2. Seat 1 precedes the first tracked call. Nothing had to fail first; the standing report came before the refusal it describes.
3. The two seats stay separate in the field, not only in the design description.
4. The mirror agrees with the executor on this pair. I re-computed your predicate statically from lib/temp-root.js before mounting, using the backend's rule: relative(realpathSync.native('C:\Users'), realpathSync.native(tempRoot)) = "yangz\AppData\Local\Temp" — not '', not absolute, not ..-prefixed ⇒ containsDirectory = true ⇒ tempRootInsideWorkspace = true. Live behaviour matched the prediction, so the mirror did not drift on the case it exists for.
5. The remedy block is reachable in the exact state it describes. The %TMP%-first ordering of GetTempPathW and the "must exist before the check resolves it" caveat both landed in a session where no command could run — which is the only state where that caveat matters.

What remains unverified on Windows

I would rather name these than let the verdict read wider than the evidence:

• The runner carrier. Only the session-scoped refusal has been exercised. The agentless workspace-write path (runner assertion, windows-acl-run: stderr marker, the SandboxUnavailableError reclassification) is still covered only by your suite.
• The negative case. I have not yet relaunched with TMP pointed outside the workspace, so "adviser stays silent and the command executor returns" — the check that the lever is in fact the lever — is untested by me. That is the next thing I will run unless you want a different seat first.
• read-only and danger-full-access silence. Consistent with the design, not exercised in this configuration.

The negative case is cheap from here and it is the one that closes the loop on the lever itself. Say the word if you want it before you take the upstream fix further; otherwise I will report back with it either way.

[yanggaihao5-sys]

Negative case for the temp-root family: confirmed. Moving the temp root out of the workspace cleared the condition — and the plugin responded exactly as designed, by going silent on that family and switching to a different one.

How it was cleared

Per the advisory's own remedy 1, TMP/TEMP were set in the process that launches the harness (a wrapper that sets them, then delegates to the existing restart script), with the target directory created first:

TMP  = C:\dsh-temp
TEMP = C:\dsh-temp

Workspace unchanged: C:\Users. Nothing was repaired; no ACL was touched — the two directories simply stopped overlapping, which is the change the advisory describes.

What changed at the refusal

Same call, no escalation, workspace-write:

	Reported
Before	Error: Windows ACL temp root must be outside the workspace: workspace=C:\Users; temp=C:\Users\yangz\AppData\Local\Temp + the family-5 advisory
After	Error: SetNamedSecurityInfoW failed (Win32 5): grantWrite(C:\Users) + the family-1 advisory

So three things are now observed rather than inferred:

1. The remedy is the lever. Setting %TMP% outside the workspace is sufficient to clear the temp-root condition — not merely what the code reads.
2. The pre-flight half goes silent when the condition is gone. It did not keep reporting after the pair stopped overlapping, so the mirror does not fire on a satisfied state.
3. The family dispatch is real. The same install moved to a different signature and answered it with a different advisory, without being told which failure it was looking at.

A sequential exposure on this workspace shape — worth knowing

C:\Users puts a family-5 refusal in front of family 1. The temp-root assertion runs in the provider, while the runner argv is assembled, so the ACL grant is never attempted — the sequence is: family 5 refuses first, family 1 is never reached. Clearing family 5 (by moving the temp root) does not leave a working workspace here; it exposes family 1 underneath.

For anyone whose workspace is a profile parent or a drive root, "move the temp root" is therefore one step of two, not the fix — and the second step is the one with a blast radius.

Which branch actually applies here, and why it matters

Measured on the failing directory (unelevated, read-only):

Owner of C:\Users	NT AUTHORITY\SYSTEM — not the caller
Caller	yzyyzy\yangz
ACEs naming the caller	none — access is BUILTIN\Users: ReadAndExecute, Synchronize
ACEs carrying WRITE_OWNER or WRITE_DAC	none

That forces the second branch twice over: the unelevated icacls "C:\Users" /grant ... cannot run at all (it needs WRITE_DAC, which no ACE here grants and ownership does not supply to a non-owner).

And it is where I want to flag the ordering rather than the content. The advisory's grant branch, if reached by elevation, would have the backend write an inheritable Low integrity label — and on C:\Users that label inherits to every user profile below it, not to one project folder. The failure modes your "what the grant leaves behind" section lists (Electron/Chromium exit, build tools treating files as from-the-internet, publisher warnings) would then apply profile-wide, and removing the label needs WRITE_OWNER — the same right that is missing at the start.

Your advisory does contain the correct escape ("sidestep the ACL entirely: create the workspace under %USERPROFILE%"), and it contains the label warning. What the ordering may understate is that when the workspace is a system-owned ancestor directory, the sidestep is not an alternative — it is the only branch that is both runnable and non-destructive. Promoting it above the grant branch for that shape would have saved me a round of thinking about whether to elevate.

One question on the version boundary

Our install is dsh 0.1.5-rc.1. The advisory places the label half at 0.1.7-alpha.1 and says that "up to 0.1.6-alpha.x the backend touched the DACL only (flag 4), so a Modify-only workspace provisioned fine" — which would put us on the far side of that boundary, yet we reproduce a failure the note attributes to the label line. Two possibilities I cannot separate from here: the boundary is keyed on sandbox-windows-acl's own version rather than dsh's, or on this directory the distinction does not bite — the caller holds neither WRITE_DAC nor WRITE_OWNER, so a DACL-only write would be refused as well, on access rather than on the label. Which is it? It matters for anyone who reads the boundary as a way to decide whether an older build sidesteps this.

Still unverified on Windows

Unchanged from my last note: the runner carrier (agentless workspace-write, windows-acl-run: / exit 127) remains covered only by your suite. The session-scoped half, and now the silence half, are exercised here.