[Bug] @deepseek-ai/dsh-fs-local throws "Cannot mix BigInt and other types" when statting .asar paths under Electron ASAR view (0.2.0-rc.2)

[han-er]

Environment

• DeepSeek Harness: 0.2.0-rc.2
• @deepseek-ai/dsh-fs-local: 0.2.0-rc.2
• OS: Windows (reproduced on Windows 11)
• Runtime: packaged Electron app (DeepSeek Harness.exe), Electron's transparent ASAR view enabled
• Node/Electron runtime: Node.js 24.x bundled by Electron
• Affected source: packages/fs/fs-local/src/fsio.ts
• Observed built file: @deepseek-ai/dsh-fs-local/lib/index.js (probe and probeNoFollow)

Submission note

CONTRIBUTING.md currently says the project does not accept external pull requests and asks contributors to report issues/bugs in GitHub Discussions. This report is therefore submitted as a Discussion.

Summary

dsh-fs-local calls stat(path, { bigint: true }) and assumes the returned mode field is a bigint. Under Electron's transparent ASAR view, a path whose segment ends in .asar (or .asar.unpacked) is treated as an archive directory, and fs.stat(..., { bigint: true }) still returns Number fields for such paths.

probe() then evaluates:

mode: Number(info.mode & 0o777n),

When info.mode is a Number, the Number & bigint expression throws:

TypeError: Cannot mix BigInt and other types, use explicit conversions

This breaks any DSH operation that stats a path containing an .asar segment, including DSH's own installation file:

C:\Users\Administrator\AppData\Local\Programs\DeepSeek Harness\resources\app.asar

Root cause

Electron patches fs in packaged processes so that a path ending in .asar reads as a directory. For those paths, the Stats object returns Number fields even when { bigint: true } is requested.

Minimal reproduction:

// repro.cjs
const fs = require('node:fs');

const p = String.raw`C:\Users\Administrator\AppData\Local\Programs\DeepSeek Harness\resources\app.asar`;
const st = fs.statSync(p, { bigint: true });

console.log('mode type:', typeof st.mode, st.mode);   // "number" 16768
console.log('size type:', typeof st.size, st.size);   // "number" 0
console.log('isDirectory:', st.isDirectory());        // true

try {
  console.log(st.mode & 0o777n);
} catch (error) {
  console.error(error.stack);
}

Run it as an Electron Node process:

set ELECTRON_RUN_AS_NODE=1
"C:\Users\Administrator\AppData\Local\Programs\DeepSeek Harness\DeepSeek Harness.exe" repro.cjs

Observed output:

mode type: number 16768
size type: number 0
isDirectory: true
TypeError: Cannot mix BigInt and other types, use explicit conversions
    at Object.<anonymous> (...\repro.cjs:9:19)

Note: plain Node (without Electron's ASAR view) returns bigint fields here, so the failure is specific to Electron's ASAR patched fs.

Affected code in packages/fs/fs-local/src/fsio.ts:

export async function probe(absolutePath: string): Promise<PathInfo | null> {
  const info = await probeStats(absolutePath, path => stat(path, { bigint: true }))
  if (!info) return null
  return {
    version: versionOf(info),
    mode: Number(info.mode & 0o777n), // <-- throws when info.mode is a Number
    type: pathType(info),
    size: Number(info.size),
  }
}

export async function probeNoFollow(absolutePath: string): Promise<PathLinkInfo | null> {
  const info = await probeStats(absolutePath, path => lstat(path, { bigint: true }))
  if (!info) return null
  return {
    version: versionOf(info),
    mode: Number(info.mode & 0o777n), // <-- same problem
    type: pathLinkType(info),
    size: Number(info.size),
  }
}

pathType(info) / pathLinkType(info) continue to work because the original Stats methods are still backed by Number fields; only the BigInt mask expression is wrong.

Suggested fix

Convert info.mode to Number before applying the numeric mask:

-    mode: Number(info.mode & 0o777n),
+    mode: Number(info.mode) & 0o777,

This works for both Stats (Number) and BigIntStats (BigInt) and removes the mixed-type bitwise expression. The same change is needed in both probe() and probeNoFollow().

A more explicit alternative that keeps the BigInt mask:

const mode = typeof info.mode === 'bigint' ? info.mode : BigInt(info.mode)
// ...
mode: Number(mode & 0o777n),

Patch

A ready-to-apply patch is attached as deepseek-harness-fs-local-bigint.patch:

--- a/packages/fs/fs-local/src/fsio.ts
+++ b/packages/fs/fs-local/src/fsio.ts
@@ -249,7 +249,7 @@
   if (!info) return null
   return {
     version: versionOf(info),
-    mode: Number(info.mode & 0o777n),
+    mode: Number(info.mode) & 0o777,
     type: pathType(info),
     size: Number(info.size),
   }
@@ -265,7 +265,7 @@
   if (!info) return null
   return {
     version: versionOf(info),
-    mode: Number(info.mode & 0o777n),
+    mode: Number(info.mode) & 0o777,
     type: pathLinkType(info),
     size: Number(info.size),
   }

Test plan

1. Add a unit test with a fake Stats-like object whose mode is a Number and a BigIntStats-like object whose mode is a BigInt; assert probe() / probeNoFollow() return mode = 384 for 0o600 / 0o777 masks and do not throw.
2. Existing normal Stats/BigIntStats tests should continue to pass.
3. Integration: in an Electron-as-Node process, run stat/lstat against a real .asar path with { bigint: true } and assert the resulting object supports isFile() / isDirectory() and mode & 0o777n-style arithmetic without error.

Workaround for downstream applications

Packaged Electron applications that cannot disable ASAR view (because their own code is loaded from app.asar) can normalize the returned mode before BigInt operations, or stat .asar paths through a physical-filesystem bypass. Downstream DSH Desktop already works around this by setting process.noAsar = true for unpacked processes; the official packaged build loads its own code from app.asar, so it cannot do that.

Additional context

This was observed while running DeepSeek Harness 0.2.0-rc.2 on Windows. Reading the installation's own resources\app.asar through DSH file tools triggered the exact error. After patching the built expression to Number(info.mode) & 511, DSH read no longer threw the BigInt error and correctly returned not a regular file for the ASAR archive path.

[huangbaba1992]

macOS 侧确认（0.2.0-rc.2），并补充影响面

DSH	0.2.0-rc.2（桌面版，profile desktop）
系统	macOS 27.0.1（26A434），Apple Silicon
@deepseek-ai/dsh-fs-local	0.2.0-rc.2
预设	cordis（创造模式，profile 默认）

复现输出（Electron 内建 node）：

asar stat bigint -> mode type: number
REPRO: Cannot mix BigInt and other types, use explicit conversions
normal stat bigint -> mode type: bigint | ok: 493

即 asar 内路径 mode 为 number，普通路径为 bigint，& 511n / & 0o777n 必抛，与平台无关。

影响面不止 .asar 目录本身：本文标题举的是 stat 安装目录，但实际是「任何位于 app.asar 内部的路径」在 DSH 的 fs 层都不可用。除技能发现外（见 #7929、#7906），在 DSH 内直接用 read 工具读 asar 内文件同样失败：

read /Applications/DeepSeek Harness.app/Contents/Resources/app.asar/dsh/node_modules/@deepseek-ai/dsh-agent-preset/skills/agent-experience/SKILL.md
→ Error: Cannot mix BigInt and other types, use explicit conversions

也就是说：任何把内置资源放在 app.asar 内、再经 fs 层读取的功能都会中招，不只是 dsh-fs-local 的调用方。

触发链路（供定位）：presets/cordis.patch.yml 的 skill-filesystem.customSkillDirs 指向 asar 内的 @deepseek-ai/dsh-agent-preset/skills → FileSystemSkillProvider.list() → discoverRoot() → ctx.fs.listDir() → listDirectory() → probe() → Number(info.mode & 511n) 抛 TypeError → 被 listingIoError() 包成 FsError(FS_IO_ERROR)（不在 isAbsentSkillPathError() 的容错范围内）→ 冒泡出 list() → dsh-skill 置 cacheable = false 并跳过整个 provider。

修复方向与 #7929 一致（Number(BigInt(info.mode) & 511n)，或在 probeStats 后对 Number/BigInt 型 stat 做归一化）；技能侧的连带症状见 #7929。