DeepSeek Harness Windows 报 0xC0000142：内置 Administrator 怎么修

Windows 桌面版把权限切到 workspace-write 后，pwsh、cmd、甚至最简单的 echo 1 都返回 0xC0000142，stdout 和 stderr 全空——如果当前账户是内置 Administrator（SID 以 -500 结尾），这条基本可以直接定性：受限令牌在创建时带了 LUA_TOKEN，而内置 Administrator 在这个标志下起不了任何受限进程。 修复提交 bdd75ca1a0c 只进了 0.2.2-alpha.2 之后的 alpha 线，rc 线没有；所以这不是「再调一下配置」能好的问题，而是「先认账号，再认版本，最后选路径」（#10630、#11297）。

DeepSeek Harness 先认账号：SID 以 -500 结尾就是内置 Administrator

判断是不是内置 Administrator，不看账户显示名，只看 SID：whoami /user 输出的最后一段是 -500，就是内置账户；普通管理员账户的 RID 是随机分配的，不会以 -500 结尾。

按下面三步确认，别靠「我的账户叫 Administrator」来猜：

1. 打开 PowerShell，执行 whoami /user。输出类似 DESKTOP-XXX\Administrator S-1-5-21-...-500，看到 -500 就记下。
2. 执行 whoami /groups，确认当前令牌里有没有 Mandatory Label\High Mandatory Level，以及是否处于提升状态。内置 Administrator 在 UAC 关闭时通常直接是 High。
3. 再确认 DSH 是用这个账户启动的：任务管理器 → 详细信息 → 找到 DeepSeek Harness.exe，看「用户名」列是不是同一个账户。

很多人会误以为「我在 administrators 组里」就是内置 Administrator，其实两者完全不同。普通管理员账户有正常的用户登录令牌，受限令牌还能退回到普通用户权限；内置 Administrator 没有这层退路，所以同样的代码在别人机器上正常，在你这里就全挂。

DSH插件 为什么内置 Administrator 会起不了受限进程

根因是 CreateRestrictedToken 带了 LUA_TOKEN：这个标志本意是把管理员降权成普通用户，但内置 Administrator 没有可降级的普通登录令牌，结果就是受限令牌连进程创建都过不了，统一返回 0xC0000142。

把链路拆开看：

1. DSH 在 workspace-write 下要用受限令牌启动子进程，先调用 CreateRestrictedToken。
2. 为了让子进程没有管理员权限，构造参数里带了 LUA_TOKEN。
3. 普通管理员账户会被降成一个可用的普通用户令牌，进程能起来。
4. 内置 Administrator 没有普通用户登录路径，降级后的令牌缺少必要的登录 SID/配置文件，子进程在 DLL 初始化阶段就失败。
5. 失败被包装成退出码 0xC0000142，stdout/stderr 都来不及产生，所以看起来像「命令没执行」。

这也解释了为什么 read-only 有时也挂、danger-full-access 却正常：后者根本不用受限令牌，自然绕开了这条链。

DeepSeek Harness 版本判定：修复只进了 0.2.2-alpha.2 之后的 alpha 线

修复提交 bdd75ca1a0c 移除了 LUA_TOKEN，但它只合进了 0.2.2-alpha.2 及之后的 alpha 构建；0.2.0-rc.2、0.2.1-rc.3、0.2.1-rc.4 都不包含，所以「升级到最新 rc」并不等于修好。

先确认你实际跑的是哪条线：

1. 打开桌面端「关于」或安装目录里的 resources/app.asar，读 package.json 的 version，记下完整版本号。
2. 如果是 0.2.0-rc.x 或 0.2.1-rc.x，直接判定为「未含修复」。
3. 如果是 0.2.2-alpha.2 或更高的 alpha，按提交号再确认一次：安装包内 app.asar 对应构建应包含 Remove LUA_TOKEN 的改动。
4. 不要用「我点了检查更新」来判断，更新通道可能仍停在 rc 线。

版本矩阵可以记成一句话：rc 线没有，alpha.2 起才有。这也是为什么社区里同一个 0xC0000142，有人升级就好了，有人升级到 rc.4 仍然复现。

DeepSeek插件 三条可行路径：升级、换账户、临时放开

最短路径是升级到含修复的 alpha 构建；不想用 alpha 就新建一个普通管理员账户；两者都不行，才考虑临时切到 danger-full-access，并明确接受失去沙箱隔离的代价。

路径一：升级到 0.2.2-alpha.2 或更高 alpha

1. 先备份 profile 与 ~/.dsh 目录，alpha 线的格式迁移不一定可回退。
2. 从官方 nightly/alpha 通道安装 0.2.2-alpha.2 或更高版本。
3. 启动后执行 whoami /user 确认还是同一个账户，再切 workspace-write。
4. 跑一条 echo 1 验证不再返回 0xC0000142；如果仍失败，说明你中的不是 LUA_TOKEN 这一条，转去查默认 DACL 或控制台。

路径二：新建普通管理员账户

1. 打开 Windows 设置 → 账户 → 其他用户 → 添加账户。
2. 创建一个新的本地账户，类型选「管理员」，不要启用内置 Administrator。
3. 注销当前会话，用新账户登录，重新安装或复制 DSH 到该用户可访问的目录。
4. 在新账户下启动 DSH，切 workspace-write，再跑 echo 1 验证。
5. 确认可用后，把项目与会话数据迁移到新账户的 DSH_HOME，不要两个账户共用同一份会话目录。

路径三：临时切到 danger-full-access

1. 在会话里执行 /permission，选择 danger-full-access。
2. 确认当前项目是可信代码，且你接受「命令不再受工作区沙箱限制」。
3. 用它完成紧急操作后，尽快切回 workspace-write 或换到已修复版本。
4. 不要把这个模式写进默认配置，避免以后忘记。

DeepSeek Harness 别把另外三种 0xC0000142 误判成这一条

同样是 0xC0000142，至少还有三条常见成因：保活组缺失、用 CREATE_NO_WINDOW/CREATE_NEW_CONSOLE 创建子进程、路径 DACL 带了外来 AppContainer 包 SID。它们的判别方式不同，别用同一个方案硬套。

判别顺序建议固定为：先看账号（SID）→ 再看模式（workspace-write vs read-only）→ 再看宿主（桌面端 vs dsh web）→ 最后看 ACL 日志。一次只改一个变量，别同时换账户、换模式又改 ACL，否则永远不知道是哪一条生效。

DSH插件 注意事项：这几件事别做

下面这些做法会加重问题或掩盖真因，先避开再谈修复。

1. 不要靠关闭 UAC 来绕过。UAC 关闭只会让内置 Administrator 更容易以 High 完整性启动，LUA_TOKEN 的问题还在。
2. 不要把所有 0xC0000142 都当成 LUA_TOKEN。先做账号判定，否则会白升级一次 alpha。
3. 不要长期用 danger-full-access 代替修复。它绕开的是整个沙箱，不是这一条令牌缺陷。
4. 不要两个账户共用同一个 DSH_HOME。会话日志和锁文件会互相干扰，出问题后很难判断是权限还是并发写。
5. 升级 alpha 前先备份。profile、会话目录、cordis.patch.yml 都复制一份，alpha 线的迁移不保证可逆。

如果你的账户 SID 不是 -500，这篇的结论就不适用，直接跳到默认 DACL 或控制台那两篇；如果确实是 -500，又不想换账户，最省事的就是升级到含 bdd75ca1a0c 的 alpha 构建。相关排查见 DeepSeek Harness Windows 子进程报 0xC0000142：受限令牌与宿主定位。