[Bug] Composed filesystem throws "Cannot mix BigInt and other types" on app.asar paths, which silently empties the whole skill catalog

[zy00010]

[Bug] Composed filesystem throws "Cannot mix BigInt and other types" on app.asar paths, which silently empties the whole skill catalog

Environment

• DSH Desktop, bundle version 0.2.0-rc.2 (installed build dated 2026-09-29)
• Windows 11, Node.js v24.21.0
• Default desktop profile, agent preset cordis

Symptom

Every skill shipped with the installation is unresolvable. skill cordis-plugin-development (and the three others) answers unknown or no longer available, and the session has no skill catalog at all — including skills placed in a healthy on-disk root such as $DSH_HOME/skills.

The underlying filesystem fault is a TypeError raised on any packed asar path.

Minimal reproduction

Call the read tool (i.e. any composed-filesystem read) on a path inside app.asar:

<install>\resources\app.asar\dsh\node_modules\@deepseek-ai\dsh-skill-filesystem\package.json

Result:

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

The same operation on the same file placed under app.asar.unpacked, or on any ordinary disk file, succeeds. Reading a directory inside app.asar fails identically, which shows the failure happens before any read — during metadata resolution.

Exact cause (pinned to a line)

@deepseek-ai/dsh-fs-local/lib/index.js requests BigInt metadata:

const info = await probeStats(absolutePath, (path) => stat(path, { bigint: true }));
const info = await probeStats(absolutePath, (path) => lstat(path, { bigint: true }));

and then, at lines 243 and 258:

mode: Number(info.mode & 511n),

511n is a BigInt literal. On ordinary disk paths stat(..., { bigint: true }) returns BigInt fields (verified here: typeof mode === 'bigint', typeof size === 'bigint'), so & is BigInt & BigInt and works. On asar-backed paths Electron's archive layer returns plain Number fields, so the expression becomes Number & BigInt and throws:

> Number(5 & 511n)
TypeError: Cannot mix BigInt and other types, use explicit conversions

That message matches the observed failure verbatim. Because this runs inside probe() — the first metadata probe — every composed-filesystem operation on an asar path fails at fs.resolve, before the caller can see a more specific error.

Why it takes down the entire skill catalog

The shipped cordis preset mounts skill-filesystem with a customSkillDirs entry that resolves inside the archive:

- id: skill-filesystem
  name: '@deepseek-ai/dsh-skill-filesystem'
  config:
    customSkillDirs:
      - !!js ...createRequire(baseUrl).resolve('@deepseek-ai/dsh-agent-preset/package.json')... + '/skills'

SkillProvider.list() iterates roots without a per-root guard:

for (const root of roots) for (const skill of await discoverRoot(root, this.ctx, this.name)) candidates.push(skill);

listSkillRootEntriesFromFileSystem() swallows only absent-path errors (ENOENT / ENOTDIR / FS_NOT_FOUND / FS_NOT_DIRECTORY) and re-throws everything else. So the one poisoned root makes the whole list() reject, the registry skips the provider ("logged and skipped"), and skills from every other root become invisible — the catalog is empty rather than partial.

Suggested fixes

1. Filesystem layer (root cause). Do not mix BigInt with a non-BigInt value: use Number(info.mode) & 511, or have probeStats detect non-BigInt fields and degrade to the plain-stat path. Both keep the intent of BigInt metadata while tolerating archives that ignore the bigint option.
2. Defence in depth. Tolerate one bad root in SkillProvider.list() — skip the failing root instead of rejecting the whole observation. A single unreadable directory should never hide every other skill.
3. Composition. The shipped preset could use bundledSkillDir instead of customSkillDirs for an in-archive directory: bundledSkillDir sets trustedHost: true, which routes discovery through Node I/O rather than the composed filesystem. Trade-off: rank moves from 300 to 600, so shipped skills would rank below user skills (arguably the right priority for content that ships with the installation).

Verification notes

• On master (packages/bundle/web-app/presets/cordis.patch.yml, sha f6527f77ba) the customSkillDirs entry is unchanged, so the trigger is still present there.
• I could not compare packages/fs/fs-local/src/index.ts against this build (GitHub API rate limit), so "still unfixed on master" is verified for the preset only, not for the fs layer.
• The asar-returns-Number half is an inference from the TypeError plus the absence of any other BigInt/Number mixing on that path; the throwing expression itself is verified by reproducing the error message.

[zy00010]

Follow-up: I checked master directly, and the root cause is still present.

packages/fs/fs-local/src/fsio.ts (master):

• 248: const info = await probeStats(absolutePath, path => stat(path, { bigint: true }))
• 252: mode: Number(info.mode & 0o777n),
• 264: const info = await probeStats(absolutePath, path => lstat(path, { bigint: true }))
• 268: mode: Number(info.mode & 0o777n),

0o777n is a BigInt literal — the same value as the decimal 511n in the installed build — so the BigInt/Number mixing is unchanged; only its spelling differs. Searching for the decimal literal therefore finds nothing on master, which should not be read as fixed.

The trigger in the shipped preset is likewise unchanged on master (packages/bundle/web-app/presets/cordis.patch.yml, sha f6527f77ba: skill-filesystem -> customSkillDirs pointing inside app.asar).

Minimal fix is still one token in each of the two places: Number(info.mode) & 0o777, or let probeStats degrade when the returned fields are not BigInt.

[PerryLink]

你的诊断完全正确，两处行号我都在最新代码上核过了。补三样东西：根因可以再钉死一个 token、放大器你没强调、以及一条"即便修好 fs 层也仍会全空"的理由。

1. 根因两处（packages/fs/fs-local/src/fsio.ts）

:248  const info = await probeStats(absolutePath, path => stat(path, { bigint: true }))
:252  mode: Number(info.mode & 0o777n),
:264  ... path => lstat(path, { bigint: true }))
:268  mode: Number(info.mode & 0o777n),

你 follow-up 报的 248/252/264/268 与 origin/master 完全一致。stat 来自 node:fs/promises（:10），Electron 下被 asar 层接管；一旦返回的 Stats 不是 BigInt 形态，Number & BigInt 立刻抛 TypeError: Cannot mix BigInt and other types。

而 probe() / probeNoFollow() 是第一次元数据探测（:242-272），所以任何 asar 路径在 fs.resolve 阶段就炸 —— 这正是你说的"读目录也失败，说明发生在读之前"。

一个措辞上的升级：真正的缺陷是 fs-local 对"非 BigInt 的 Stats"零容忍，与捆绑哪个 Electron 版本无关。这比"asar 返回 Number"更硬 —— 后者我无法从本仓证实（仓内没有 Electron/asar 代码），只能作为与 Electron 版本强相关的前提提出。Electron 是手工构造 asar 的 Stats（其成员类型历史上出过与真实文件不一致的缺陷，main 分支现在才显式把 options.bigint 传给 fillStatArray），所以别把它当不变量写进报告。

2. ⭐ 放大器：skill-filesystem 的根循环没有 per-root 容错

这是"整个目录全空、连健康磁盘 root 都没了"的真正原因，你的报告把它归给 fs 层，但 fs 层只解释了"一个根失败"，解释不了"全部消失"：

• packages/skill/skill-filesystem/src/index.ts:195-199 → for (const root of roots) { for (const skill of await discoverRoot(root, this.ctx, this.name)) … } —— 循环体内没有任何 per-root try/catch（该文件里唯一被 try 包住的是 :188-193 的 watchManager.observeRoots）
• :760-773 的 listSkillRootEntriesFromFileSystem 只吞 isAbsentSkillPathError（:716-724 定义：ENOENT/ENOTDIR/FS_NOT_FOUND/FS_NOT_DIRECTORY），其余一律 rethrow
• 异常逃到注册表 packages/skill/skill/src/index.ts:602-608 → catch { this.ctx.logger.warn(\skill provider "${provider.name}" skipped: ${errorMessage(error)}`) }` ⇒ 整个 provider 被丢弃
• 而 project / custom / user 根全归这一个 provider：skill-filesystem/src/index.ts:244-264 依次推入 .dsh/skills(project, rank 100)、.agents/skills(200)、customSkillDirs(300)、$DSH_HOME/skills(user-dsh, 400)、$DSH_AGENTS_HOME/skills(500)、bundledSkillDir(600)。customSkillDirs（300）排在两个 user 根之前，所以循环在到达健康 root 之前就中断了

⇒ 所以这条要单列为第二个诉求：skill-filesystem/src/index.ts:195-199 的循环应加 per-root try/catch（记 warn 后 continue）。 即使 fs 层修好，今天任何其他根级故障（EACCES、网络盘、EPERM）也会造成同样的"全空"。

3. 触发器在最新代码上仍在（但你的 blob sha 过期了）

packages/bundle/web-app/presets/cordis.patch.yml:134-138 → - id: skill-filesystem / config: customSkillDirs: / - !!js process.getBuiltinModule('node:path').join(… createRequire(baseUrl).resolve('@deepseek-ai/dsh-agent-preset/package.json') …, 'skills')。

⚠️ 你引的 blob sha f6527f77ba 已过期：origin/master 上该文件是 8c8d567ae3a863e74cba19da2114169a1576d9b2。结论"still present"不变，但引用要更新。

4. 你的建议 3 我核实了：三个关键点都对

• bundledSkillDir 真实存在：skill-filesystem/src/index.ts:72 注释（Bundled skill root; defaults to $DSH_BUNDLED_SKILL_DIR …）、:87 schema、:261 的 { …, source: 'bundled', rank: BUNDLED_SKILL_RANK, trustedHost: true }
• trustedHost: true 让它走 Node I/O 而不是 ctx.fs：:762 → if (fs !== undefined && root.trustedHost !== true) return await listSkillRootEntriesFromFileSystem(root, fs)（读取侧 :856 同理）⇒ 这就绕开了出问题的组合文件系统
• rank 代价 300 → 600 属实：CUSTOM_RANK = 300（:37）对 BUNDLED_SKILL_RANK = 600（packages/skill/skill/src/index.ts:28）

还有一条仓内先例可以直接引用：packages/skill/skill-office/src/index.ts:79（readFileSync(path, 'utf8')）、:92（readFile(locator, …)），配 rank: BUNDLED_SKILL_RANK（:83），同文件 :59/:72 的 statSync（不带 bigint）在打包环境下正常工作 —— 说明"bundled provider 用 Node I/O 读 asar 包内文件"这条路已经有人走通。

5. 建议的形态（两条独立、各自可测）

1. fs 层：Number(info.mode) & 0o777（先转 Number 再与 Number 掩码），或让 probeStats 检测到非 BigInt 字段时降级走普通 stat 路径 —— 两处各改一个 token。
2. skill 层：:195-199 加 per-root 容错。

6. 用户侧 workaround（不等修）

• 把 .dsh/skills（或 ~/.agents/skills）当主来源；
• 在 profile 的 cordis.patch.yml 里覆盖 skill-filesystem 的 config，删掉指向 asar 的那条 customSkillDirs（或换成磁盘路径）。⚠️ 注意 patch 是整体替换该行 config，需要重述其余键（见 packages/bundle/web-app/README.md:103）；代价是预设里那四个随包发布的 skill 会一起消失。

验证命令：对同一份 package.json 分别在 app.asar 与 app.asar.unpacked 下调用 read，前者抛 TypeError、后者正常；再在最新线上确认两处未修：

git grep -n "0o777n" origin/master -- packages/fs/fs-local/src/fsio.ts