[Bug] Every path inside app.asar fails: "Cannot mix BigInt and other types" (fs-local probe assumes BigInt stats)

[Oooooldbai]

What happens

On a packaged (asar) installation, any Harness filesystem operation that probes a path inside app.asar throws:

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

Two user-visible consequences:

1. Local skills disappear entirely. A preset's skill-filesystem row carries
   customSkillDirs: [<…>/@deepseek-ai/dsh-agent-preset/skills], which resolves inside app.asar.
   Listing that root throws, and @deepseek-ai/dsh-skill then logs
   skill provider "filesystem" skipped: FsError: cannot list "…": Cannot mix BigInt and other types
   and drops the whole provider — so project and user skill roots are lost too, not just the failing
   one. Concretely on 0.2.0-rc.2: skill("cordis-plugin-development") →
   unknown or no longer available, while a real-directory provider (skill-office) keeps working.
2. Agent file tools cannot read the installation. A read-style call against any …/app.asar/…
   path fails with the same error, so agents cannot inspect the shipped source, skills, docs or package
   manifests.

listDir, stat, writeText and editText all go through the same probe.

Environment

• DeepSeek Harness desktop 0.2.0-rc.2 (app bundle 0.2.0-rc.2), Node 24.21.0
• macOS 26.6.2 (build 25G83), arm64
• Checked today: master still contains the defect (see Root cause).

Minimal reproduction

Run with the app's own binary — asar support is active only in Electron, not in plain Node:

ELECTRON_RUN_AS_NODE=1 "/Applications/DeepSeek Harness.app/Contents/MacOS/DeepSeek Harness" -e '
const fs = require("fs");
const p = "/Applications/DeepSeek Harness.app/Contents/Resources/app.asar/dsh/node_modules/@deepseek-ai/dsh-agent-preset/skills";
const s = fs.statSync(p, { bigint: true });
console.log("mode typeof :", typeof s.mode);   // a real path returns bigint
console.log("size typeof :", typeof s.size);
console.log("mtimeNs     :", s.mtimeNs);
try { Number(s.mode & 0o777n) } catch (e) { console.log("Number(s.mode & 0o777n) →", e.message) }
console.log("Number(s.mode) & 0o777 →", Number(s.mode) & 0o777);
'

Actual output:

mode typeof : number
size typeof : number
mtimeNs     : undefined
Number(s.mode & 0o777n) → Cannot mix BigInt and other types, use explicit conversions
Number(s.mode) & 0o777 → 420

Control: the identical call against a real directory (/Applications) returns bigint for every field.
That is why the defect is invisible in a source checkout and reproduces only in a packaged build.

Root cause

packages/fs/fs-local/src/fsio.ts — probe() (mode on line 252) and probeNoFollow() (mode on line 268):

const info = await probeStats(absolutePath, path => stat(path, { bigint: true }))
…
mode: Number(info.mode & 0o777n),

fs.stat(path, { bigint: true }) is assumed to always return BigInt fields — the type annotations say so
(probeStats<T extends Stats | BigIntStats>, versionOf(info: BigIntStats)). Electron's asar layer
ignores the bigint option and returns plain Numbers, so Number & BigInt throws.

The shipped bundle shows the same expression compiled: lib/index.js:243 and :258 contain
Number(info.mode & 511n) — the build turns 0o777n into 511n, which is why searching master for
0o777n finds the source while searching for 511n finds only packaged output.

Related, same function: versionOf() interpolates info.mtimeNs / info.ctimeNs, which are undefined
for asar stats — no throw, but asar paths get version strings containing "undefined", so
expected-version change detection is not meaningful there.

Suggested fix

Normalize before the bitwise operation, at both sites:

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

Secondary robustness suggestion

One unreadable root currently removes every filesystem skill, because the skills service catches a
provider-level list() failure and skips the provider as a whole. Per-root isolation (skip the failing
root, keep the others, surface a per-root diagnostic) would degrade instead of disabling local skill
discovery.

Regression coverage

A unit test that injects a stat returning Number fields (simulating asar) next to the existing BigInt
case, asserting probe() returns a numeric mode and does not throw.

[PerryLink]

这个错误的成因是确定的（BigInt 与 Number 混算）——而同一天已有一条带修复的同类报告

1. 机制

你在 fs-local 的探测里看到的

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

只可能来自一处：某处用了 BigInt 版的 stat（fs.stat(path, { bigint: true }) ⇒ 返回的 size/mtimeNs 等是 BigInt），随后与一个 Number 做了算术（+ / - / * / / 或 %）。比较（>、<）不会抛，算术才会抛 ⇒ 所以真正的触发点是"拿 bigint 字段参与了算术"。

而我们平台上出现"只有 app.asar 内的路径失败"这一点很关键：asar 内的路径是虚拟路径，探测它走的是另一条分支（可能正是 bigint 版本），而普通磁盘路径走的是普通 stat。这个差异解释了你看到的选择性。

2. ⚠️ 请先与 #8815 合并（那条已带修复）

同一天有一条 [Bug Fix / PR] Fix TypeError: Cannot mix BigInt and other types（#8815）。⇒ 极可能是同一处缺陷，且对方已经给出修法。建议：

1. 先去那条对照代码位置（文件 + 符号 + 行）；若确实是同一处 ⇒ 在那边补充你的"asar 路径"这一触发面（你这条的独特价值），而不是另开一条；
2. 若不是同一处 ⇒ 请在正文里写明"与 #8815 不是同一处，因为…"——这个说明能让维护者不必自己判断。

合并的价值：同一个 TypeError 在两条帖子里各修一半，是这类问题最常见的浪费。

3. 请补三样（让可复现性更强）

1. 完整栈的第一帧（哪个函数在做那个算术）——你已定位到"probe assumes BigInt stats"，把那一行贴出来即可；
2. 最小复现：是不是"任意 asar 内路径都失败"（挑一个已知存在的 asar 内路径试）——若是，任何人都能一条命令复现；
3. 版本：你未写版本。⚠️ 当前最新是 0.2.1-alpha.1（latest/next = 0.2.0-rc.2）⇒ 请补基线。

4. 关于"本地技能全部消失"这个后果（建议保留并放大）

你写"预设的 skill-filesystem 行带的 customSkillDirs 指向 asar 内路径 ⇒ 本地技能全部消失"。⇒ 这把一个 TypeError 升级为功能整块不可用，是这条报告最有分量的部分。建议把它放在摘要第一句——比"某个 TypeError"更能说明优先级。

一条边界

我确认的是该错误的唯一成因类别（BigInt/Number 混算）与 asar 虚拟路径会造成分支差异这一层推理。具体哪一行、以及是否与 #8815 同处，以你们两条的代码对照为准——我没有跑打包安装。

[wangyu0317]

Independent macOS arm64 confirmation + evidence that the whole provider is dropped, not just the failing root

Environment: DSH Desktop 0.2.0-rc.2 (installed build 2026-09-29), macOS arm64, default desktop profile, agent preset cordis.

Confirming both halves of the report on this machine:

1. Any composed-filesystem read inside app.asar fails before the read itself. Two different members — …/@deepseek-ai/dsh-agent-preset/skills/cordis-plugin-development/SKILL.md and …/@deepseek-ai/dsh-agent-preset/package.json — both return Error: Cannot mix BigInt and other types, use explicit conversions. The same call against a normal on-disk file succeeds.

2. skill cordis-plugin-development answers unknown or no longer available, and no skill catalog is ever published for the session, while the skill tool itself is present in the request's tool list.

One extra data point for the "entire provider is dropped" claim:

I copied the four shipped @deepseek-ai/dsh-agent-preset/skills/* bundles byte-identically (sha256 matches the entries in desktop-runtime.json) into a healthy on-disk scanned root (project root <cwd>/.dsh/skills, rank 100) and waited for the watcher to pick it up. The load still answers unknown or no longer available. A valid skill that has lived under the user root (~/.agents/skills, rank 500) is equally unresolvable. So no configured root is being scanned at all — consistent with dsh-skill skipping the entire filesystem provider once the asar root throws.

For the contrast, another report (#7906) finds Standard mode unaffected on the same install, leaving the preset's customSkillDirs as the only variable.

Agreeing with the suggestion in #9164: a single unreadable custom root should not take every other configured root with it, and the provider-level skip should be diagnosable from the session, not only from one log line.

[suyuhao1206]

来报到！已在 #8815 中补齐了基于 0.2.1-alpha.1 (HEAD 5badb15009) 的完整内联 git diff、单测覆盖（覆盖 probe、probeNoFollow 及 versionOf 回退）、asar 忽略 bigint 的根因分析以及验证命令，将 #8815 定位为本报告（#8842）的修复侧实现。两帖已形成双向关联闭环。

[laughinbytes]

2026-10-14 复核：两处缺陷在 master 与最新预发布 dsh-v0.2.1-alpha.2 上均未修复。

位置	状态
packages/fs/fs-local/src/fsio.ts（blob a9d97fd6）	未修 —— 仍是 :252 / :268 的 Number(info.mode & 0o777n)
packages/bundle/web-app/presets/cordis.patch.yml	未修 —— 仍是 customSkillDirs 指进 app.asar
最新发布 v0.2.1-alpha.2（2026-10-09）	不含修复

补一条此前没贴过的证据，说明这不是回归、而是从未工作过：
在本机全部历史会话日志中，创造模式（cordis preset）的会话从未出现过 skill catalog；
同一批日志里其它 preset 的会话则全部都有。

旁证：skill office-docx 能成功（来自全局层 dsh-skill-office），
而 skill cordis-plugin-development 与任何 ~/.agents/skills 下的条目一律
unknown or no longer available —— 说明 list() 并没有 reject，而是 complete === false
导致 dsh-tool-skill 整份目录都不发布。

环境复核：DSH Desktop 0.2.0-rc.2 / macOS arm64。

修法方向（本线程与 #8815 已有讨论，此处仅作确认）：probe() 不应假定 BigInt 形状
（Number(info.mode) & 0o777，并让 versionOf() 容忍缺失的 mtimeNs/ctimeNs）；
packaged skills 根改用 bundledSkillDir（trustedHost: true，走原生 Node I/O），
而不是 customSkillDirs（强制走 ctx.fs）。

---

EN: Re-checked on 2026-10-14 — both defects are still present on master and on the latest
pre-release dsh-v0.2.1-alpha.2. fs-local/src/fsio.ts:252/:268 still computes
Number(info.mode & 0o777n), and the cordis preset still points customSkillDirs inside app.asar.

Evidence that this never worked rather than regressed: in the complete local session-log history no
cordis-preset session ever contains a skill-catalog message, while every session on other presets does.

The provider is not rejecting: skill office-docx resolves (global dsh-skill-office layer) while every
filesystem skill reports unknown or no longer available — consistent with snapshot.complete === false,
which makes dsh-tool-skill publish no catalog at all.

Environment: DSH Desktop 0.2.0-rc.2, macOS arm64. Suggested: stop assuming BigInt stats in probe(),
and use bundledSkillDir (trusted root, plain Node I/O) instead of customSkillDirs.