DeepSeek Harness Windows 0xC0000142: built-in admin fix

Switch the Windows desktop app to workspace-write and pwsh, cmd, even a plain echo 1 come back as 0xC0000142 with empty stdout and stderr. If the account is the built-in Administrator (SID ending in -500), that is usually enough to close the case: the restricted token is built with LUA_TOKEN, and the built-in Administrator cannot start any restricted process under that flag. The fix, commit bdd75ca1a0c, only went into the alpha line after 0.2.2-alpha.2 — not the rc line. So this is not something you tune away in settings; the order is: identify the account, identify the build, then pick a path (#10630, #11297).

DeepSeek Harness: Identify the account first: a SID ending in -500 is the built-in Administrator

Whether you are on the built-in Administrator is decided by the SID, not the display name: if the last segment of whoami /user is -500, it is the built-in account; a normal administrator gets a random RID that never ends this way.

Work through these three checks instead of guessing from "my account is called Administrator":

1. Open PowerShell and run whoami /user. A line like DESKTOP-XXX\Administrator S-1-5-21-...-500 means you are on the built-in account; note the -500.
2. Run whoami /groups and confirm whether the token carries Mandatory Label\High Mandatory Level, and whether DSH is running elevated. With UAC off, the built-in Administrator is usually already High.
3. Confirm DSH was launched by that same account: Task Manager → Details → locate DeepSeek Harness.exe and compare the "User name" column.

Plenty of people assume "I am in the administrators group" equals the built-in Administrator. They are different things. A normal administrator has a regular user logon token the restricted token can fall back to; the built-in Administrator has no such fallback, which is why the same code works on a colleague's machine and fails on yours.

DSH plugin: Why the built-in Administrator cannot start restricted processes

The root cause is CreateRestrictedToken with LUA_TOKEN: the flag is meant to demote an administrator to a normal user, but the built-in Administrator has no regular logon token to demote to, so the restricted token cannot even create a process and returns 0xC0000142 across the board.

Break the chain into steps:

1. Under workspace-write, DSH starts child processes through a restricted token and calls CreateRestrictedToken first.
2. To strip administrator rights from the child, the call includes LUA_TOKEN.
3. A normal administrator account is demoted to a usable normal-user token, and the process starts.
4. The built-in Administrator has no normal-user logon path; the demoted token lacks the required logon SID and profile, so the child dies during DLL initialization.
5. The failure is reported as exit code 0xC0000142, before stdout or stderr can exist, which looks like "the command never ran".

This also explains why read-only sometimes fails while danger-full-access works: the latter does not use a restricted token at all, so it skips the entire chain.

DeepSeek Harness: Version check: the fix only landed in the alpha line after 0.2.2-alpha.2

Commit bdd75ca1a0c removes LUA_TOKEN, but it was only merged into 0.2.2-alpha.2 and later alpha builds; 0.2.0-rc.2, 0.2.1-rc.3, and 0.2.1-rc.4 do not include it, so "upgrade to the latest rc" is not a fix.

Confirm which line you are actually running:

1. Open the desktop "About" panel, or read package.json inside resources/app.asar in the install directory, and write down the full version.
2. If it is 0.2.0-rc.x or 0.2.1-rc.x, treat it as "fix not included".
3. If it is 0.2.2-alpha.2 or a later alpha, verify once more by commit: the app.asar in your installer should be built from the commit that contains Remove LUA_TOKEN.
4. Do not decide based on "I clicked check for updates" alone; the update channel may still be pinned to the rc line.

The version matrix compresses into one sentence: rc line no, alpha.2 and up yes. That is why the same 0xC0000142 is fixed for some people by upgrading and still reproduces for others after moving to rc.4.

DSH Plugin: Three workable paths: upgrade, switch account, temporarily open up

The shortest path is upgrading to an alpha build that contains the fix; if you do not want an alpha, create a normal administrator account; only if neither works should you temporarily switch to danger-full-access and accept the loss of sandbox isolation.

Path 1: upgrade to 0.2.2-alpha.2 or a later alpha

1. Back up your profile and the ~/.dsh directory first; alpha format migrations are not guaranteed to be reversible.
2. Install 0.2.2-alpha.2 or later from the official nightly/alpha channel.
3. After launch, run whoami /user to confirm you are still on the same account, then switch to workspace-write.
4. Run echo 1 to verify the 0xC0000142 is gone. If it still fails, you are not hitting LUA_TOKEN — move on to the default DACL or console checks.

Path 2: create a normal administrator account

1. Open Windows Settings → Accounts → Other users → Add account.
2. Create a new local account and choose the "Administrator" type; do not enable the built-in Administrator.
3. Sign out of the current session, sign in as the new account, and reinstall or copy DSH into a directory that account can access.
4. Launch DSH under the new account, switch to workspace-write, and run echo 1 again.
5. Once it works, move projects and session data into the new account's DSH_HOME; do not share one session directory between both accounts.

Path 3: temporarily switch to danger-full-access

1. In the session, run /permission and pick danger-full-access.
2. Confirm the project is trusted code and that you accept commands no longer being confined by the workspace sandbox.
3. Finish the urgent task, then switch back to workspace-write or move to a fixed build as soon as possible.
4. Do not write this mode into your default configuration, or you will forget it is on.

DeepSeek Harness: Do not mistake three other 0xC0000142 causes for this one

The same 0xC0000142 has at least three other common causes: a missing job object/keep-alive group, child processes created with CREATE_NO_WINDOW/CREATE_NEW_CONSOLE, and a path DACL that carries a foreign AppContainer package SID. Each needs a different diagnosis, so do not force one fix onto all of them.

Keep the diagnosis order fixed: account (SID) → mode (workspace-write vs read-only) → host (desktop vs dsh web) → ACL logs. Change one variable at a time; swapping account, mode, and ACL at once means you never learn which one mattered.

DSH plugin: Cautions: things not to do

Most cases get worse when several things change at once; keep to one variable and one account check.

1. Do not work around this by disabling UAC. Turning UAC off only makes it easier for the built-in Administrator to start at High integrity; the LUA_TOKEN problem remains.
2. Do not treat every 0xC0000142 as LUA_TOKEN. Run the account check first, or you will upgrade to an alpha for nothing.
3. Do not use danger-full-access as a long-term substitute for the fix. It bypasses the whole sandbox, not this one token defect.
4. Do not share one DSH_HOME between two accounts. Session logs and lock files interfere with each other, and afterwards you cannot tell permissions from concurrent writes.
5. Back up before upgrading to alpha. Copy the profile, the session directory, and cordis.patch.yml; alpha-line migrations are not guaranteed to be reversible.

If your SID does not end in -500, this article does not apply — jump to the default DACL or console articles instead. If it does end in -500 and you would rather not switch accounts, the least painful route is upgrading to an alpha build that contains bdd75ca1a0c.See DSH plugin: Windows subprocess fails with 0xC0000142 for the related case.