DeepSeek Harness Windows 沙箱导致 Vite / esbuild 打包失败的问题反馈

[uiws]

DeepSeek Harness Windows 沙箱导致 Vite / esbuild 打包失败的问题反馈

一、问题描述

在 Windows 环境下使用 DeepSeek Harness 操作前端项目后，执行 Vite 打包时出现 Access is denied 错误。

具体报错：

[vite:esbuild-transpile] remove
C:\Users\SONGYU~1\AppData\Local\Temp\esbuild-<hash>:
Access is denied.

将 TEMP 路径改为 D:\Temp 后，仍然出现相同错误：

[vite:esbuild-transpile] remove
D:\Temp\esbuild-<hash>:
Access is denied.

Vite 显示构建耗时约 20 秒，且 Gzip 压缩成功，但最终构建命令返回失败：

✓ built in 20.82s
[vite-plugin-compression]: compressed file successfully
ERROR error during build
ELIFECYCLE Test failed

二、运行环境

• 操作系统：Windows
• 项目路径：D:\项目\防火墙\ISRF测试\frontend
• 前端构建工具：Vite
• 包管理器：pnpm
• esbuild 版本：0.18.20
• Node.js：已安装（具体版本待补充）
• 相关工具：DeepSeek Harness、Qoder CN

三、排查过程

1. 检查 Windows 用户目录及临时目录环境变量，确认用户目录为 C:\Users\songyuhui2，TEMP 使用 Windows 短路径 C:\Users\SONGYU~1\AppData\Local\Temp。

2. 验证 TEMP 目录可以正常创建和删除文件。

3. 将 TEMP 和 TMP 临时切换至 D:\Temp，重新打包后仍然出现相同错误，排除单纯的原临时目录路径配置问题。

4. 发现打包失败后，esbuild 临时文件可以通过 CMD 的 del /f 手动删除，说明文件在构建结束后并非始终无法删除。

5. 检查项目中的 esbuild 可执行文件：

   node_modules\.pnpm\@esbuild+win32-x64@0.18.20\node_modules\@esbuild\win32-x64\esbuild.exe
   

   使用 icacls 检查后，发现其具有以下完整性级别标记：

   Mandatory Label\Low Mandatory Level:(I)(NW)
   

6. 使用管理员 PowerShell 执行：

   icacls $exe /setintegritylevel M

   执行成功，之后再次检查，标记变为：

   Mandatory Label\Medium Mandatory Level:(NW)
   

四、当前判断及临时解决方案

目前怀疑 DeepSeek Harness 的 Windows 沙箱机制可能给工作区中的文件添加了 Low Mandatory Level（低完整性级别）标记，并可能通过 pnpm 硬链接影响 esbuild 等可执行文件。

这一判断与故障现象相符，但尚未通过完整的修复后打包测试确认因果关系。

已执行的临时修复：

icacls $exe /setintegritylevel M

该命令成功将项目中的 esbuild.exe 从 Low 完整性级别调整为 Medium 完整性级别。

此前也已验证，更换 TEMP 路径无法解决问题。因此，单纯修改 TEMP 或 TMP 不是有效的修复方案。

五、希望官方协助确认的问题

1. DeepSeek Harness 在 Windows 沙箱模式下，是否会为工作区文件添加 Low Mandatory Level 标记？
2. 为什么沙箱标记可能影响 pnpm 安装的 esbuild.exe，甚至导致它无法清理系统 TEMP 目录中的临时文件？
3. 是否存在已知的 Windows ACL、Mandatory Integrity Control 或 pnpm 硬链接兼容性问题？
4. Harness 退出后，是否可能残留低完整性级别标记？是否有官方提供的检查和恢复方法？
5. 是否计划在后续版本中修复该问题，避免影响 Vite、esbuild 等前端构建工具？

六、期望改进

希望官方能够：

• 排查 Windows 沙箱对工作区文件及 pnpm 硬链接文件的完整性级别标记处理逻辑。
• 确保沙箱退出后不会遗留影响正常开发和构建的文件标记。
• 提供安全、可逆的修复工具或官方文档。
• 在 Windows + pnpm + Vite + esbuild 环境中增加相关兼容性测试。

该问题会导致前端构建产物已经生成，但构建命令最终仍然失败，影响正常开发、测试及部署流程。

感谢协助排查。

[7gzgn]

先说一个可能被忽略的点：构建其实成功了。日志里 ✓ built in 20.82s 和 gzip 压缩都过了，失败的只有 esbuild 收尾时删临时文件那一步，所以产物是完整的，这是清理阶段的 Access is denied，不是编译失败。

按可能性排三个方向，都能自己验：

1. 杀软锁住了 esbuild 的临时 exe。esbuild 在 Windows 上会把自己复制到 %TEMP%\esbuild-* 再 spawn，实时防护（Defender / 腾讯管家这类）会锁住那个 exe 直到超时。把 TEMP 和 node_modules\.pnpm 加白，或临时关实时防护跑一次；好了就是它。
2. 是不是在 DSH 的沙箱里执行的。在 DSH 里跑 pnpm build 时，沙箱的删权限和句柄回收会叠在子进程上。对照实验：同样一条命令在 DSH 外的普通终端跑一遍，如果成功，就锁定是这一层。
3. 都不是的话，用 ESBUILD_BINARY_PATH 指向 node_modules 里那个 esbuild.exe，绕开"复制到临时目录再执行"这一步。

一个判据：你能用 del /f 手动删掉那个临时文件，说明句柄最终会释放，只是删除被拖到了进程退出之后——这正好对应第 1 条，而不是权限本身缺失。