**[Bug][Windows][Desktop 0.2.0-rc.2] workspace-write mode: every shell command fails with sandbox-local windows-acl temp grant materialization failed**

[cai1930909715-code]

[Bug][Windows][Desktop 0.2.0-rc.2] workspace-write 模式下所有 shell 命令失败：sandbox-local windows-acl temp grant materialization failed

摘要 / Summary

On Windows, every pwsh tool call in the default workspace-write (confined) mode fails immediately with:

sandbox-local windows-acl temp grant materialization failed and its cleanup also failed

The command is never started. The same command succeeds under danger-full-access, on the same machine, same account, same session. So @deepseek-ai/dsh-sandbox-local's Windows ACL grant path is broken, making confined mode unusable on Windows.

复现 / Steps to reproduce

1. DSH desktop 0.2.0-rc.2 on Windows, permission mode left at the default workspace-write
2. Ask the Agent to run any shell command, e.g. Write-Output "test"
3. Fails 100% of the time with the error above

Control experiment:

4. Run the exact same command with danger-full-access → succeeds

已排除的原因 / Ruled out

This is the useful part — please don't re-investigate these.

Not a TEMP path / character-encoding issue.
System TEMP was D:\C盘迁移\Temp (non-ASCII). I repointed TEMP/TMP to an ASCII-only C:\DSHTemp, restarted DSH, retested. Identical error. C:\DSHTemp stayed completely empty — no DSH writes to it at all.

Not a directory ACL problem.
Performed a full repair of D:\C盘迁移\Temp and its entire subtree:

takeown /F "<TempRoot>" /A            -> succeeded (ownership to Administrators)
icacls  "<TempRoot>" /reset /T /C     -> succeeded (whole tree reset)
icacls  "<TempRoot>"                  -> no (DENY) entries;
                                         Authenticated Users:(I)(M)

Before the repair, icacls /reset was denied even from an elevated prompt. After it, ACLs were fully normal. Identical error either way.

Not stale corrupted directories.
D:\C盘迁移\Temp originally contained 7 randomly-named directories (4bu3sm5k, elg5xl4j, …) that returned Access is denied on access. All were taken over and deleted. The directory is now clean. Identical error.

Not a leftover process / missing restart.
Confirmed via Task Manager that no DeepSeek Harness.exe remained, then cold-started DSH. Repeated several full quit-and-restart cycles. Identical error.

Not insufficient OS or account permission — key control.
Under full access I manually reproduced exactly the operation the sandbox performs:

New-Item -ItemType Directory -Path $test -Force
icacls $test /inheritance:r /grant "${env:USERDOMAIN}\${env:USERNAME}:(OI)(CI)(F)"
icacls $test            # verified the ACL was actually applied
Remove-Item $test -Recurse -Force   # removed successfully

Tested both inside the session workspace and in C:\DSHTemp. Both succeeded.
The OS permits this account to do this ACL work. The defect is inside DSH's own sandbox implementation.

定位线索 / Where it looks broken

Reading the @deepseek-ai/dsh-sandbox-local Config schema through the Inspect API:

field	default
runnerCommand	[] (empty)
runnerFailureSignatures	[] (empty)
probeTimeoutMs	5000

Inference (explicitly an inference, not verified):

1. probeTimeoutMs + runnerFailureSignatures imply the sandbox runs a capability probe before use, classifying the outcome by matching output signatures. "materialization failed" may be the fallback error when the probe fails or times out — not an actual ACL failure.
2. That would explain why no amount of filesystem ACL repair changes anything: the failure is not in the ACL operation.
3. No sandbox runner executable exists in the install tree. A recursive search for sandbox|runner|acl|grant across the install directory matched only unrelated Python stdlib files. With runnerCommand empty there is nothing to fall back to but the built-in implementation.

Suggested place to look: the grant-directory create/cleanup path in the Windows ACL implementation, and whether probe timeout / signature-mismatch failures are being reported as materialization failed.

影响 / Impact

• In confined mode no shell command can run at all, removing a large part of the Agent's tool surface (no scripts, no verification, no external programs).
• Users are pushed into danger-full-access long-term, which defeats the file sandbox entirely.
• Since this is the default mode, a normal user hits it immediately, and the error text points at ACLs, which sends debugging down the wrong path for a long time (as it did here).

环境 / Environment

DSH desktop : 0.2.0-rc.2
platform    : win32 / x64
Node        : 24.21.0
Python      : 3.12.14
pnpm        : 11.7.0
System TEMP : D:\C盘迁移\Temp   (also tried C:\DSHTemp, no change)
Workspace   : C:\Users\cai19\Documents\deepseek-harness\default-workspace
Install     : C:\Users\cai19\AppData\Local\Programs\DeepSeek Harness

Relevant plugins: @deepseek-ai/dsh-sandbox-local, @deepseek-ai/dsh-sandbox-policy, @deepseek-ai/dsh-fs-sandbox, @deepseek-ai/dsh-pwsh-sandbox

当前绕过 / Current workaround

danger-full-access. Functional, but it disables the file sandbox — not a substitute for a fix.

---

Every conclusion above is measured; the only inference is clearly marked in the "Where it looks broken" section.

[cai1930909715-code]

Note on the title: markdown emphasis was accidentally left in the title and cannot be cleaned up. GitHub does not permit an author without maintain permission to edit or delete their own discussion (UpdateDiscussion and DeleteDiscussion both return FORBIDDEN, and the REST PATCH endpoint returns 404), so the asterisks and backticks above are literal. The report body below is unaffected and complete.

[argszero]

Thanks for the elimination work — the "ruled out" section is what makes this answerable. Two of your inferences do not hold against the source, and one datum you already have is decisive. Everything below is read from origin/master at 0.2.1-alpha.2 (d743267388); the two strings you pasted are the same in 0.2.0-rc.2.

1. There is no capability probe in this path

probeTimeoutMs would mean something here only if the chain had more than one rung. PLATFORM_CHAINS (packages/sandbox/sandbox-local/src/index.ts:160-167) is win32: ['windows-acl'] — a sole candidate — and chainVerdict() returns a sole candidate without probing it ("A sole candidate needs no arbitration; its execution-time refusal still fails closed", :514-515). probeRunner is only reached for the multi-rung linux chain. runnerFailureSignatures classifies the stderr of a user-supplied runnerCommand, which you have empty (the default). And the grant path itself — materializeAclGrant (:396-455) — contains no probe at all. So nothing timed out, and nothing was probed; "materialization failed" is a literal thrown error, not a fallback verdict.

2. The sentence you saw is a wrapper that by construction carries neither the code nor the path

Two sites throw it, with different wording (:417 vs :447):

• sandbox-local windows-acl workspace grant failed and its cleanup also failed — the standing workspace-root grant
• sandbox-local windows-acl temp grant materialization failed and its cleanup also failed — yours

Both are new AggregateError([error, ...cleanupFailures], '<that text>'). AggregateError.message does not contain its members: the Win32 code and the affected directory live in error.errors, and a consumer that reads the surfaced line alone — a log reader, the model, a diagnosis plugin — receives a sentence naming neither. That is a property of the wrapper, not a gap in your investigation, and it is the reason this failure is hard to act on.

Yours being the temp variant is itself information: the workspace-root grant is a different message, so the standing root ACE either applied or was already cached, and the refusal is on the private per-session capability directory.

3. What that block actually does, in order (:428-447)

1. mkdtempSync(join(tmpdir(), 'dsh-')) — the private capability directory, created before any ACL work
2. AclWriteGrant.create(tempSid) — ConvertStringSidToSidW plus two well-known SIDs
3. grant.add(tempDir) — withPathLock → mkdirSync(dirname(lockPath), { recursive: true }); then readCurrentSecurity (GetNamedSecurityInfoW) and one SetNamedSecurityInfoW applying three edits at once (capability allow ACE, ambient FILE_DELETE_CHILD deny, Low integrity label)
4. on any throw: grant.dispose() — which calls revokeWrite, i.e. the same lock again — and then removeTempDir (rmSync(path, { recursive: true, force: true }))

Two consequences, and they are the whole of what "and its cleanup also failed" tells you:

• The condition is not transient: the same directory refused both the write and its revocation.
• Steps 3 and 4 share the lock path, and the lock path is <GetTempPathW()>\dsh-acl-locks\<sha256(path)[0:16]>.lock (packages/sandbox/sandbox-windows-acl/src/acl.ts:65-95). A lock directory that cannot be created or opened fails the grant and its cleanup together and produces exactly the sentence you pasted — with no ACL operation having been attempted at all. That mechanism is in neither your report nor the earlier ACL discussions.

4. The decisive datum is already in your report — and it points at a second temp resolution

There are two independent "temp" resolutions in this one call, and you have measured only one:

• os.tmpdir() (Node) chooses the capability directory — the dsh-XXXXXX one
• GetTempPathW() (the Win32 call the lock uses, and the one the native layer prefers) chooses dsh-acl-locks

You wrote that C:\DSHTemp — the root you redirected to — stayed completely empty, with no DSH writes at all. That is not a side observation; it is a measurement. mkdtempSync runs before any ACL work, so any failing call must have left a dsh-XXXXXX directory there (cleanup also failed, so it stays), and normally a dsh-acl-locks directory beside it. If that root holds neither, then the running process never resolved temp to it, and both the failing directory and the lock live under the old root, D:\C盘迁移\Temp.

So the probe I would ask for is: reproduce the failure, then look at both roots for dsh-* entries and icacls the ones you find. The owner is the first line of that output and it matters — see below. And capture error.errors (or the raw uncaught stack) once: that is the only place the Win32 code is.

5. Your ACL repair may have removed the very condition the grant needs

takeown /F <root> /A sets the owner to Administrators. This backend's documented prerequisite is that the calling account holds WRITE_DAC/WRITE_OWNER on that directory: owner-implicit rights come only from your own ownership, and a UAC-filtered Administrators membership contributes deny-only SIDs. icacls /reset then restores inheritance, and an inherited Authenticated Users:(M) does not carry WRITE_DAC/WRITE_OWNER (Modify is full control minus change-permissions and change-owner). That combination is the recorded cause in the data-volume reports — [discussion #7750], [#7735], [#8232] — and the repair there is an explicit ACE naming the caller, one line per root, because a sibling root on the same volume is not covered by another root's line.

Your manual control used icacls ... /grant "${env:USERDOMAIN}\${env:USERNAME}:(OI)(CI)(F)" — the correct shape — but only on a directory you had just created, whose owner was you and whose parent you had reset. That is not the same object as the one the backend is asked to edit.

6. The repair already ships — use it on the path the probe names

@deepseek-ai/dsh-sandbox-windows-acl bundles and registers the diagnose-windows-sandbox-acl skill (registerAclDiagnosisSkill; it arrives with 0.2.0, so it is in your 0.2.0-rc.2). It reads the requested path and every ancestor, adds the signed-in user's Full-control allow ACE where effective WRITE_DAC/WRITE_OWNER is missing, verifies every change by re-reading it, backs up each changed DACL, preserves denies/owner/inheritance, refuses reparse points, and exits nonzero with a recovery path if a repair fails. It needs an unconfined caller for that one call (a confined child cannot read or write security descriptors), so escalate it in the session.

Point it at the directory step 4 identifies — not at the root you redirected. If the failing directory is in the old root, repairing the new one is a no-op, which is exactly the shape of "identical error either way" you observed across your repairs.

[argszero]

This sentence has a plugin form now, so the next session that hits it does not have to re-derive the mechanism from the source.

@argszero/cordis-plugin-sandbox-grant-advisor 0.19.0 — https://www.npmjs.com/package/@argszero/cordis-plugin-sandbox-grant-advisor (repo: https://github.com/argszero/cordis-plugin-sandbox-grant-advisor)

npm install @argszero/cordis-plugin-sandbox-grant-advisor

Mount it by adding the shipped cordis.patch.yml entry to your profile (an insert of id sandbox-grant-advisor). This is its seventh recognized failure, added for this thread.

What it recognizes. Both producer sentences, verbatim — they are two halves and the plugin keeps them apart, because the difference is real:

• the temp half is the per-session private capability; its cleanup revokes the temp ACE and removes the private directory;
• the workspace half is the standing root ACE; its cleanup only frees the grant SIDs, and that ACE is the reuse cache and is kept on purpose.

So the layer tells you where to look, and the workspace half failing also means the temp directory was never created.

What it does with the line. It does not name a cause, because the line carries none: this is an AggregateError message, and Node builds that message from the argument the thrower passed rather than from errors — so the Win32 code, the API name and the directory are absent by construction, not by truncation, and the runtime hands the session error.message. The advisory states that, then hands over candidates in the order a probe can separate them, with the one that needs no ACL at all first — every grant and every revocation runs under the same per-path lock, and the lock file is created before any security descriptor is touched:

<GetTempPathW()>\dsh-acl-locks\<first 16 hex of sha256(lowercased path)>.lock

A lock root that cannot be created or opened fails the grant and its cleanup together and produces this exact sentence having attempted no ACL operation. It is also the only candidate a directory listing can settle, with no privileges:

dir "<temp root>\dsh-acl-locks"

The lock file is opened with OPEN_ALWAYS and never deleted, so an absent or empty directory after a failure is itself the finding.

It ships no repair command, on purpose — the line names no directory, and a grant aimed at the wrong one is worse than none. Instead it hands over the probe that names the directory and then the backend's own diagnose-windows-sandbox-acl skill, with the version boundary that the skill arrives with the 0.2.0 line (a 0.1.7 install should not go looking for it).

It also names what you measured as not helping, with the reason each fails: takeown /A moves ownership to Administrators, whose implicit rights are READ_CONTROL and WRITE_DAC and therefore not WRITE_OWNER; icacls /reset /T /C restores an inherited Authenticated Users:(M) entry that carries neither right.

One inference it discards, since it was made here: a visible probeTimeoutMs in the Config schema invites "the capability probe timed out". This backend has no capability probe — its Windows chain is a single rung selected without probing, and the grant path contains no probe at all — so no timer can produce this sentence.

The upstream repair is at the two throw new AggregateError(...) lines themselves: the members already hold exactly what the reader needs, and the defect is that Node's AggregateError.message is built from the thrower's argument, so none of it reaches a line the session can read. Quoting the first member's message into the thrown text (or attaching the members to the rendered result) would answer "which directory, which right" at the source; the plugin is the stopgap until then.