Desktop (Electron): local skill discovery silently disappears when a preset customSkillDirs points inside app.asar

[zhoujieh]

Summary

On the packaged Desktop build, every local skill becomes invisible (skill <name> → unknown or no longer available) while the same workspace works in a plain Node/CLI host. The model-facing skill catalog is never published. Root cause is a chain of two independent problems:

1. @deepseek-ai/dsh-web-app's presets/cordis.patch.yml mounts skill-filesystem with

customSkillDirs:
  - !!js process.getBuiltinModule('node:path').join(process.getBuiltinModule('node:path').dirname(process.getBuiltinModule('node:module').createRequire(baseUrl).resolve('@deepseek-ai/dsh-agent-preset/package.json')), 'skills')

In the Desktop build @deepseek-ai/* lives inside app.asar, so that directory is an asar path.

2. @deepseek-ai/dsh-fs-local's probe() does stat(path, { bigint: true }) and then Number(info.mode & 511n). Electron's asar shim ignores { bigint: true } for asar paths and returns a number-valued fs.Stats (every numeric field is number, every *Ns field is undefined), so the BigInt literal in & 511n throws TypeError: Cannot mix BigInt and other types, use explicit conversions.

That error surfaces as FS_IO_ERROR cannot list "<asar dir>". dsh-skill-filesystem's discoverRoot() only tolerates "absent" errors (ENOENT / ENOTDIR / FS_NOT_FOUND / FS_NOT_DIRECTORY), so list() rejects; dsh-skill's listLayerCandidates() catches it, emits a single logger.warn (skill provider "filesystem" skipped: …) and skips the entire provider; dsh-tool-skill then publishes nothing because snapshot.complete === false.

Net effect: one unreadable directory removes all local skills — including project-root .agents/skills — silently, the only user-visible symptom being skill reporting unknown.

Environment

• Desktop build 0.2.0-rc.2 (Electron 44.0.0), macOS arm64.
• Agent preset cordis; reproducible with standard in the same packaged host.
• Workspace has .agents/skills/<name> -> ../../.codex/skills/<name>; the file is readable and its frontmatter is valid (the same workspace works in a non-packaged host).

Minimal repro A — Electron side, no DSH needed

ELECTRON_RUN_AS_NODE=1 "/Applications/DeepSeek Harness.app/Contents/MacOS/DeepSeek Harness" -e '
const fs = require("node:fs")
const p = "/Applications/DeepSeek Harness.app/Contents/Resources/app.asar/dsh/node_modules/@deepseek-ai/dsh-agent-preset/skills/agent-experience/SKILL.md"
const s = fs.statSync(p, { bigint: true })
console.log({ size: typeof s.size, mode: typeof s.mode, blksize: typeof s.blksize, mtimeNs: typeof s.mtimeNs })
try { console.log(s.mode & 511n) } catch (e) { console.log(e.constructor.name + ": " + e.message) }
'

Observed:

{ size: 'number', mode: 'number', blksize: 'number', mtimeNs: 'undefined' }
TypeError: Cannot mix BigInt and other types, use explicit conversions

The older asar fs.stat bug where blksize/blocks were undefined (electron/electron#42686, fixed by electron/electron#50877) is already fixed in Electron 44.0.0 — blksize/blocks are numeric here. What remains is that { bigint: true } is not honoured for asar paths at all, and the *Ns fields are missing.

Minimal repro B — DSH side

Mount @deepseek-ai/dsh-skill-filesystem with customSkillDirs containing any path inside app.asar, then call ctx.skills.list({ cwd }) where cwd is a workspace with .agents/skills: the provider is skipped and no local skill is returned. In the running packaged Host we confirmed with a read-only probe plugin that an otherwise identical provider which avoids ctx.fs (plain Node fs) lists every skill, including the four shipped under app.asar (agent-experience, cordis-composition-reference, cordis-plugin-development, editing-cordis-compositions).

Suggested fixes

1. dsh-fs-local: accept number | bigint in probe() (e.g. BigInt(info.mode) & 511n, and do not depend on *Ns fields), or fall back to non-bigint stats for asar paths. fs.stat(p, { bigint: true }) must not throw for paths the runtime itself ships.
2. dsh-skill-filesystem: per-root isolation in list() — a non-absent error for one root should skip that root (or degrade to complete: false with a readable reason), never fail the whole provider. Today one unreadable directory removes every local skill.
3. Observability (optional, but this is what made it expensive to find): the skip is one logger.warn while the model just sees an empty catalog. Surfacing "local discovery incomplete: <reason>" in the session would make this class of failure self-diagnosing.

Related

• Discussion Skill loader returns 'unknown or no longer available' for skills that exist on disk (session catalog snapshot) #1650 — same user-visible symptom (loader says unknown for skills that exist on disk).
• Discussion Skills with an invalid frontmatter name are dropped silently — the user never finds out #936 — same "dropped silently" family.
• [Bug]: fs.stat blksize/blocks are undefined for .asar files electron/electron#42686 → PR #50877 — asar fs.stat blksize/blocks.
• NousResearch/hermes-agent 9f229a5 — another project dropping stat probes on app.asar paths because of the same shim.

Workaround used downstream (FYI, not a fix)

WEUX mounts the same native provider with ctx.get('fs') masked so it takes the provider's Node read path (Electron's node:fs reads asar fine), and stops pointing customSkillDirs at asar paths; guard: check-shadcn-runtime 8/8.

[slyyr]

The underlying issue appears to be an assumption that fs.stat(path, { bigint: true }) always returns BigInt-valued fields, including when Electron's ASAR filesystem handling is involved.

A defensive fix would be to normalize the value before performing bitwise operations:

const mode = BigInt(info.mode) & 0o777n;

This allows the operation to handle either a numeric or BigInt mode value, provided the field is valid. The implementation should still validate unexpected or missing values and avoid depending on timestamp fields that may not be available.

I'd also separate two concerns:

1. Filesystem compatibility: Make the permission probe tolerate the actual types returned for supported path types.
2. Discovery failure isolation: If one configured skill directory cannot be read, report the failure clearly and consider continuing with other independent roots rather than silently dropping the entire provider.

For packaged Electron applications, I'd test both ordinary filesystem paths and paths inside app.asar, along with missing directories, invalid paths, and permission errors.

The important part is not merely preventing the TypeError; it's ensuring that one incompatible path doesn't make every otherwise valid local skill disappear without a useful diagnostic.

Hope this helps!