[Bug] 桌面打包版：系统提示词宣传的 implementation checkout 指向 app.asar 内部虚拟路径，agent 工具全部无法访问（0.2.0-rc.2，master 未修）

[railgun20001]

Summary

打包版桌面应用（Windows/macOS）中，每个会话的系统提示词都会写入：

The DeepSeek Harness implementation checkout is at C:\Users\<user>\AppData\Local\Programs\DeepSeek Harness\resources\app.asar\dsh。The checkout location and current working directory are separate values and may differ; never infer the working directory from this path. Use pwd to determine the current working directory. Use this checkout only to inspect or extend DSH itself.

但该路径位于 app.asar 归档内部（app.asar 是单个文件，不是目录），只有 Electron 主进程的 asar 补丁 fs 能读。所有 agent 侧真实工具都访问不了它：

• pwsh / PowerShell Get-ChildItem：找不到路径"…\app.asar\dsh"，因为该路径不存在。
• glob / grep（外部 ripgrep 进程）：os error 2 / 系统找不到指定的路径
• read：Cannot mix BigInt and other types（与 [Bug] Composed filesystem throws "Cannot mix BigInt and other types" on app.asar paths, which silently empties the whole skill catalog #9189 同类的 asar 层内部错误）

而提示词又明确邀请 agent “Use this checkout only to inspect or extend DSH itself”，于是凡是涉及 DSH 内部的任务，agent 都会在首轮去列该目录并失败，把 [stderr] Get-ChildItem: 找不到路径… 打进对话；之后每个后续轮次都可能重试，浪费 token、污染会话记录。在 DSH 相关的会话里几乎必现。

触发条件 / Reproduction

1. 安装打包版桌面应用（Windows 或 macOS，app.isPackaged === true）。
2. 打开任意会话，查看 turn 1 系统提示词，可见 implementation checkout is at …\resources\app.asar\dsh …。
3. 让 agent 执行对提示词所宣传 checkout 的任何检查（提示词本身邀请的行为），例如 Get-ChildItem "…\resources\app.asar\dsh"。

（npx @deepseek-ai/dsh web 的 npm/源码安装方式不受影响——那里 import.meta.url 能解析到真实目录。）

实际行为（Current behavior）

• Get-ChildItem: 找不到路径"C:\Users\…\Programs\DeepSeek Harness\resources\app.asar\dsh"，因为该路径不存在。（GUI 以 [stderr] 分段显示）
• glob/grep：os error 2 / 系统找不到指定的路径
• read：Cannot mix BigInt and other types
• 现象：DSH 相关会话的第一条工具调用常常就是这条失败的 Get-ChildItem，且会重复出现。

期望行为（Expected behavior）

打包模式下，系统提示词不应宣传一个只有 Electron 主进程内可见、任何 agent 工具都无法访问的虚拟路径。可接受的修法（任选其一）：

1. 当 sourceRoot 不是真实文件系统目录（例如位于 app.asar 内）时，不注册 harness:source 提示词段；
2. 打包安装时解包一份真实源码树，或在桌面端把提示指向磁盘上真实存在的运行时副本（如插件管理器安装到 ~/.dsh/profiles/node_modules 的同版本包），保证路径对工具真实可访问；
3. 若保留 asar 内路径，则文案必须说明“实现位于 app.asar 归档内部”，并提供受支持的读取手段（如 asar 提取工具/插件），而不是丢一个裸路径让模型去试。

根因（附代码出处）

• packages/bundle/web-app/src/index.ts：

  /** This dsh installation's root, from either this package's source or built entry. */
  const SOURCE_ROOT = fileURLToPath(new URL("../../../..", import.meta.url))
  ...
  if (config.surfaceContext) {
    ctx.inject(["systemPrompt"], (promptCtx) => {
      addHarnessSourceSection(promptCtx, SOURCE_ROOT)

  该“从模块 URL 向上 4 级”的自定位手法，默认假设 harness checkout 是真实目录（对应设计笔记 .agents/notes/archived/feature/2026-07-21-dsh-system-prompt-source-path.md，其场景是源码安装/npm 安装）。桌面打包后 import.meta.url 位于 …\resources\app.asar\dsh\node_modules\@deepseek-ai\dsh-web-app\lib\index.js，向上 4 级恰好是 app.asar\dsh——一个只在 Electron 进程内“存在”的虚拟路径。

• apps/desktop/src/main.ts 的 runtimeResources() 打包分支同样取 join(app.getAppPath(), "dsh")，与上述一致，且无磁盘存在性守卫。

• master（2026-10-03 提交）上两处代码未变，问题仍存在。

关联讨论

• [Bug] Composed filesystem throws "Cannot mix BigInt and other types" on app.asar paths, which silently empties the whole skill catalog #9189：同一类“asar 内部路径被当真实路径使用”的缺陷在 composed filesystem 侧的体现（BigInt 错误）。
• Desktop (Electron): local skill discovery silently disappears when a preset customSkillDirs points inside app.asar #9164：customSkillDirs 指向 app.asar 内路径时技能发现静默失效。

附：本机临时规避

在用户级 ~/.dsh/AGENTS.md 增加一条全局规则，告知后续会话“该路径位于 app.asar 归档内，禁止用 shell 列目录，改用 asar 提取工具”，可消除噪音，但属于 workaround，未触及根因。

[argszero]

Your root-cause reading is correct, and the section is gated — so there is a workaround today, plus the cheap fix.

The mechanism, confirmed. The text is produced verbatim by addHarnessSourceSection (packages/boot/app-boot/src/index.ts:1059), registered under the section name harness:source (:1042), and the path comes from packages/bundle/web-app/src/index.ts:36:

const SOURCE_ROOT = fileURLToPath(new URL('../../../..', import.meta.url))

Inside a packaged app that resolves to .../resources/app.asar/dsh, which is an archive member rather than a directory — exactly the assumption your report identifies (the archived design note assumed a source or npm install).

It is gated, though, and the gate is documented. packages/bundle/web-app/src/index.ts:252 registers the section only when config.surfaceContext is true (schema default true, :73), and the shipped row sets it true (packages/bundle/web-app/cordis.patch.yml:206, row web-runtime). With surfaceContext: false, neither the harness:source section nor the app:web-surface section nor the DSH_WEB_URL shell variable is registered (packages/bundle/web-app/README.md:55,143).

Workaround you can use before the fix. Patch layers replace the targeted row's complete config rather than deep-merging keys (apps/cli/reference/README.md:9), so restate the row's other values when overriding. Either a --patch overlay for a CLI run, or the home-level $DSH_HOME/cordis.patch.yml (default ~/.dsh/cordis.patch.yml) — which outranks the profile layer and is retained by the Desktop host, since it shares the profile lifecycle including the Harness home patch (apps/cli/README.md:60):

- id: web-runtime
  config:
    openBrowser: !!js ctx.webStartup.openBrowser
    printUrl: true
    publicUrl: !!js ctx.webStartup.publicUrl
    surfaceContext: false
    trustedHosts: !!js ctx.webStartup.trustedHosts

dsh --profile web --dump-config prints the composed tree with a comment naming the layer that supplied each row, so you can confirm the override landed before booting.

Your fix request 1 is the right one and is implementable at the point you name: skip registering the section when the computed root is not an accessible directory — no new configuration, and in a packaged install the check simply fails and the section is skipped, while source and npm installs are unaffected (their root is a real directory). Requests 2 and 3 are heavier and, for the specific symptom here, unnecessary.

Two of your symptoms are a different defect and deserve their own thread. read failing with Cannot mix BigInt and other types is not path resolution — it is raised inside the asar layer's stat handling (same family as the empty skill catalog reports, #9189/#9164). It happens to share the trigger surface with this report, but the fix is elsewhere; keeping them in one thread will route it to the wrong owner. This thread's real defect is the prompt contract: the section invites the agent to inspect a checkout that no agent-side tool can read.

One source note, in case it explains why not every install shows this: a complete agent-preset persona suppresses the section for that agent while keeping the host-owned shell variable (packages/bundle/web-app/cordis.patch.yml:195-199).