DeepSeek Harness workspace-write 0xC0000142: default DACL

Switch DeepSeek Harness to workspace-write on Windows and every shell child process returns 0xC0000142, while the same command runs fine under read-only. In cases that fail only under workspace-write, the root cause usually sits in the restricted token's default DACL: workspace-write writes a derived capability SID into TokenDefaultDacl, while read-only writes the world SID. The hard part is not the conclusion but the evidence — the two modes change two token fields at once, so a plain comparison cannot separate the restricting list from the default DACL. The community nailed it with a single-variable experiment that overrode only the default DACL (#11223, #11448).

DeepSeek Harness: Subtract first: turn "two things changed at once" into one variable

read-only and workspace-write differ not only in the default DACL but also in the restricting SID list; as long as both change together, any comparison only tells you "workspace-write is broken" and cannot attribute it to a specific field.

Start by reproducing a minimal control:

1. Create an empty directory as the workspace and put a single echo 1 test script in it.
2. Switch to read-only, run echo 1, and confirm it returns normally.
3. Switch to workspace-write, run the same command, and confirm it returns 0xC0000142 with no output.
4. Record the full exit code and timing for both runs; do not rely on the UI's word "failed".

Then run the single-variable experiment. The idea: let DSH build the token exactly as it normally would, and override only TokenDefaultDacl after construction, leaving every other field untouched.

1. Open a debug terminal with administrator rights, start DSH, and reproduce the failure.
2. Find the parent of the failing child process and confirm which restricted token it uses.
3. Replace only that token's TokenDefaultDacl with S-1-5-11 (Authenticated Users) or the current logon SID.
4. Leave the restricting SID list, integrity level, and session ID completely unchanged, then start the child again.
5. If it starts, the default DACL is the root cause; if it still returns 0xC0000142, go back to the restricting list or the console.

The value here is elimination: change one thing, observe one result, and the conclusion holds. The community initially guessed that "the capability SID has no read ACE on System32" and later withdrew it precisely because of this experiment — the deciding factor was the default DACL.

DSH plugin: Root cause: the default DACL names a derived capability SID

setTokenDefaultDaclGrant(api, restrictedToken, this.tempWriteSidPtr ?? this.writeSidPtr ?? worldSid) at sandbox-windows-acl/src/index.ts:304 decides which SID goes into the default DACL; under workspace-write it resolves to the derived capability SID, and under read-only to the world SID.

Unroll the call path:

1. Entering workspace-write, DSH needs temporary write access and prepares tempWriteSid / writeSid.
2. After building the restricted token, it grants the default DACL to that capability SID.
3. When the child creates objects, they inherit this DACL by default.
4. But the child must read system paths much earlier, during DLL initialization; the capability SID has no read ACE on those paths, so initialization fails outright.
5. The failure surfaces as 0xC0000142 because the process never reaches the point of running the command.

The comment above the call (index.ts:301-303) states the intent: objects created in a session temp directory should not receive shared-workspace capability. In other words, the capability SID is not a typo — it is deliberate. The problem is that the same SID is also used as the default DACL required for process startup, which is too narrow and stops the child before initialization finishes.

DeepSeek Harness: Why you cannot just swap in the world SID

Changing the default DACL to S-1-5-11 or Everyone does let the process start, but it tears out the isolation that keeps temp-directory objects from inheriting shared-workspace capability; the better fix adds the logon SID alongside the capability SID rather than replacing it.

The three candidates compare like this:

The community recommendation is to keep both the capability SID and the logon SID in the default DACL. Temp-directory objects still cannot get shared-workspace capability, but the basic read permission the child needs to start is present. findLogonSid already exists in token.ts in the same package and is already imported at index.ts:55, so the change is small.

DSH Plugin: What users can do: no switch, so change host or wait

There is no user-facing configuration that changes the default DACL; the only immediate recoveries are changing the host or temporarily opening the sandbox, and keeping workspace-write means waiting for the core fix.

Ordered by cost, lowest first:

1. Switch to dsh web: the Node host does not go through this desktop restricted-token chain, so commands under workspace-write usually run normally; the cost is accepting a browser-based workflow.
2. Temporarily use danger-full-access: commands run, but sandbox isolation is gone, so only use it briefly on trusted projects.
3. Move to a machine or account without the problem: for a one-off delivery, shifting the task to Linux or macOS sidesteps the Windows token differences.
4. Wait for the core fix: watch whether default DACL construction becomes "capability SID + logon SID"; do not expect an rc point release to carry it.

If you have a source checkout, you can patch it yourself: append the logon SID at the setTokenDefaultDaclGrant call site, then run three checks — echo 1, a file write, and a cross-session access. Verifying only that "the command runs" is not enough; confirm cross-session isolation is still intact.

DeepSeek Harness: How it differs from the other two 0xC0000142 families

The default DACL case is identified by "only workspace-write fails, read-only works, and the account is not the built-in Administrator"; satisfy all three before digging further, and do not start by editing tokens.

Run all three checks before deciding whether to touch the token. Change several variables at once and you end up with the vague conclusion that "it seems a bit better".

DSH plugin: Cautions: four traps when experimenting

Experiment on a copy of the token, never on a running task, and keep the SID choice as narrow as possible.

1. Do not edit tokens in a production session. Use a separate test workspace and test account so you do not take down a running task.
2. Do not verify with echo 1 alone. Also test file writes, reads of system paths, and cross-session access to confirm the fix did not remove isolation.
3. Do not treat S-1-5-11 as the final answer. It is only suitable for single-variable verification; the scope is far too wide.
4. Do not ignore version differences. Line numbers in index.ts move between rc builds, so locate code by the function name setTokenDefaultDaclGrant, not by memorized line numbers.

What makes this problem annoying is that it looks like insufficient permissions when the token is simply built too narrowly. Pin the root cause with a single-variable experiment first, then decide whether to change the host, wait for the fix, or patch in the logon SID yourself — do not bounce between account, ACL, and console theories.See DSH plugin: Windows subprocess fails with 0xC0000142 for the related case.