[Bug] Desktop shell: plugin host APIs 403 for the renderer, and shared web-profile plugins never load (patches attached)

[joyyoung]

Environment

• macOS, official source build, unpackaged dev shell: pnpm run dev:desktop --skip-build, DSH_HOME=~/.dsh, renderer origin dsh-app://app.
• Plugin set installed in the shared profiles/web profile: dsh-better-sidebar, @goodandready/dsh-time-machine, @dsh-market/plugin, @nanmicoder/dsh-agent-teams, @linxin666/dsh-web-all, dsh-persona-memory, dsh-plugin-model-proxy, dsh-sidebar-title, dsh-answer-reviewer, dsh-loop-continue.

Two separate desktop-shell gaps, both found while trying to use the same plugin set in the desktop app that already works in the browser UI. Patches are applied locally and working; posting here because CONTRIBUTING closes issues and the repo takes Discussions only.

---

Symptom 1 — plugin host APIs answer 403 for the desktop renderer

Every plugin whose host half fences on browser same-origin signals answers 403 inside the desktop shell, while the identical request works in the browser UI. Concrete case: task-board's agent control plane (its non-idempotent POST /dsh-task-board/... calls).

Root cause: the renderer's origin is dsh-app://app, so a request the host forwards to the embedded webServer still reads as cross-origin. The desktop host owns both the renderer and the webServer, so the honest presentation is "same-origin loopback":

// apps/desktop-host/src/index.ts
function loopbackForwardHeaders(request: Request, port: number): Headers {
  const headers = new Headers(request.headers)
  headers.delete('host')
  const authority = `http://127.0.0.1:${String(port)}`
  headers.set('origin', authority)
  headers.set('sec-fetch-site', 'same-origin')
  return headers
}

Symptom 2 — plugin host routes are unreachable from the shell

assetHandler only served the dist bundle plus the connection gateway. But plugin host halves register their routes on the webServer service (skill-explorer, task-board, time-machine, market, …), which the desktop host never consulted, so those routes fell through to the SPA index.html (GET) or 405 (everything else).

Patch: forward any non-asset request to ctx.get('webServer') and treat 404 as "no plugin route" (fall back to the gateway); non-idempotent methods are proxied too instead of being rejected by the blanket 405:

if (request.method !== 'GET' && request.method !== 'HEAD') {
  const proxied = await proxyToWebServer(request)   // 404 => undefined
  if (proxied !== undefined) return proxied
  return new Response(null, { status: 405 })
}

For /api/* the gateway must stay the fallback, and the connection prefix route answers rejected requests with a plain-text unauthorized / forbidden marker — that marker is distinguishable from a real plugin response because plugin routes answer JSON (related: #5770, #3186):

if ((response.status === 401 || response.status === 403) && !(contentType?.includes('application/json') ?? false)) {
  const text = await response.text()
  if (text === 'unauthorized' || text === 'forbidden') return api.fetch(rebuild())
  return new Response(text, { status: response.status, headers: response.headers })
}

Symptom 3 — dsh-remote-web-ui's boot patch makes the in-app renderer hit its LAN gate

That plugin's boot patch rewrites loopback-fenced paths (/api/*, /sidebar/*, /git/*, /pet/*) onto its gated /remote prefix so a LAN browser can proxy through the desktop's webServer. The desktop renderer runs inside this host and is the host owner (ownsHost), so no pairing applies — but the rewritten path still arrives at the host. Unwrapping before dispatch fixes it:

if (url.pathname.startsWith('/remote/')) {
  url.pathname = url.pathname.slice('/remote'.length)
}

Symptom 4 — the dev shell never loads the shared web profile's plugins

The disposable development project links only first-party workspace deps, and the unpackaged dev shell exposes no settings UI to install anything. Meanwhile DSH_PROFILE is effectively the only channel that reaches family plugins: the host child strips every DSH_DESKTOP_* override, and the dev userData dir carries no profile-selection state.

Patch (2 parts, in apps/desktop/scripts/):

• dev.ts — DSH_PROFILE: process.env.DSH_PROFILE ?? SHARED_WEB_PROFILE_NAME ('web').
• development-project.ts — link the third-party bundles found in ~/.dsh/profiles/web/node_modules into the dev project, merge dsh.profile.bundles from the profile manifest, and copy the profile's cordis.patch.yml:
  • mergeWebProfileManifest() derives bundles from the manifest and filters @deepseek-ai/dsh-*, so first-party rows keep coming from the workspace build.
  • WEB_PROFILE_THIRD_PARTY_BUNDLES is the weak spot: I hardcoded my plugin set as a fallback. A maintainer-grade version probably wants either manifest-only derivation or an explicit opt-in list — guidance welcome.

Also apps/desktop-host/config/desktop.cordis.patch.yml needs web-runtime enabled (inject: [webServer], openBrowser: false, printUrl: false, surfaceContext: false) because plugin rows inject the webRuntime service it supplies; webserver gets pinned to loopback 127.0.0.1:3199 with compression: none.

---

Verification

With the patches above, in the unpackaged dev shell: task-board's control plane no longer returns 403, and dsh-better-sidebar + @goodandready/dsh-time-machine behave exactly as in the browser UI (bottom panel renders, toggle shows/hides it, time-machine registers its tab and snapshots the workspace). Checked over CDP against dsh-app://app/index.html, plus a full host restart to confirm the fixes are not artifacts of one process.

Diff: 4 files, +183/−6 (apps/desktop-host/src/index.ts, apps/desktop-host/config/desktop.cordis.patch.yml, apps/desktop/scripts/dev.ts, apps/desktop/scripts/development-project.ts). Happy to turn it into whatever shape maintainers prefer — or to drop the env-specific pieces.

Questions

1. Is proxying through ctx.get('webServer') inside desktop-host the right seam, or should this be a first-class request-level seam (webServer middleware layer (ctx.webServer.use): a request-level seam so plugins can guard /api #3186) so each host doesn't re-implement it?
2. For the honest same-origin presentation of forwarded requests — is rewriting origin/sec-fetch-site acceptable, or would you rather plumb the renderer origin as trusted in the webServer's own config?
3. For Symptom 4, should the dev shell mirror a profile at all, or is "install into the desktop profile" the intended path once it has a settings UI?

---

中文摘要

在官方源码构建的未打包桌面 dev 壳里发现两处桌面端专属缺口（同一套插件在浏览器 UI 上工作正常）：

1. 插件 host API 全部 403：渲染进程 origin 是 dsh-app://app，宿主转发到内嵌 webServer 的请求被插件按跨域信号拒绝；宿主同时拥有渲染进程与 webServer，故按同源 loopback 呈现（改 origin + sec-fetch-site）。
2. 插件 host 路由根本不可达：插件 host 半边把路由注册在 webServer 服务上，而 assetHandler 只看 dist 与 connection gateway → 落到 SPA index.html 或 405；改为非资产请求先问 webServer（404 视为无插件路由再回落 gateway），并放行非幂等方法；/api/* 上用「plain-text unauthorized/forbidden」区分网关拒绝与插件响应。
3. dsh-remote-web-ui 的 boot patch 把 loopback 路径改写到它带门禁的 /remote 前缀；桌面渲染进程本身就是 host owner，故先脱壳再派发。
4. 未打包 dev 壳不加载 profiles/web 的第三方插件，且 DSH_PROFILE 是唯一能到达 family 插件的通道（host 子进程会剥离 DSH_DESKTOP_*，dev userData 无 profile 选择状态）→ dev.ts 设 DSH_PROFILE ?? 'web'，development-project.ts 镜像 profile 的第三方 bundle + 合并 dsh.profile.bundles + 复制 cordis.patch.yml；另需在 desktop.cordis.patch.yml 启用 web-runtime 并固定 webserver 到 127.0.0.1:3199。

补丁已在本地工作树（4 文件 +183/−6），验证方式为 CDP 检查 dsh-app://app/index.html + 完整重启宿主。因为 CONTRIBUTING 关闭 issues、只收 Discussions，故发在此处征求方向。

[joyyoung]

Follow-up: the same reachability gap, as an opt-in patch

This continues the desktop report above. Two gaps stop plugin routes from working under
the Electron carrier, and both are now closed without changing the shipped default.

1. The routes never exist in the shell. The shipped Desktop overlay keeps
webserver and web-runtime disabled (deliberately: "it opens no listening port"),
and every plugin route — /sidebar/*, /api/*, the remote stream — lives on the
webServer service. Flipping those rows in the shipped overlay is not an option: the
disabled state is asserted by apps/desktop/tests/profile-mcp.spec.ts. So the shell now
gains a second overlay that is applied only when the launch opts in.

2. A dsh-app: page cannot open a WebSocket the fence trusts. The renderer built its
socket URLs from location.origin, which is dsh-app://app under the carrier, and the
request fence rejected Origin: dsh-app://app as cross-site. With no loopback origin to
dial, every sidebar socket died with 1006.

Patch

desktop-web-surface-optin.patch — 7 files, +244/−10, applies cleanly on 0d1f500:

git apply --check desktop-web-surface-optin.patch   # ok
git am               desktop-web-surface-optin.patch   # ok
apps/desktop-host/config/desktop.web-surface.cordis.patch.yml | 27 ++   (new)
apps/desktop-host/src/index.ts                                 | 146 +  (gate + transport seat)
apps/desktop-host/package.json                                 |   3 +-
apps/desktop/src/core-package-set.ts                           |   1 +
apps/desktop/tests/desktop-web-surface.spec.ts                 | 70 ++   (new)
apps/desktop/tests/prepare-package-set.spec.ts                 |   6 +-
scripts/check-workspace-constraints.ts                         |   1 +

The opt-in is read from the launch environment snapshot, so either the process
environment or a .env layer can set it:

DSH_WEB_SURFACE=1

Deliberately not a DSH_DESKTOP_* name: the host child strips that prefix from its own
environment, so the gate would never see it. Nothing else moves — the shipped overlay
still pins both rows off, and an opted-in launch binds webServer to 127.0.0.1:3199
with the webRuntime row injected as the plugin rows expect. The new overlay is
registered everywhere the shipped one is: package file list, DESKTOP_HOST_RUNTIME_FILES,
its constraint allowlist, and the package-set assertion that already required the
shipped config.

Companion client fix (separate repo)

The client half is in omdsh-dev/DSH-better-sidebar#706: socket URLs are built from the
transport seat the host already injects (__DSH_TRANSPORT__.webOrigin), falling back to
location.origin; and the request fence accepts a dsh-app: carrier Origin before
the cross-site check, while still requiring a loopback/trusted Host. Cross-site origins
are unchanged (403).

Gates

Check	Result
pnpm run build:lib:host	ok — bundled host contains the web-surface overlay path
tsc -b tsconfig.client.json	exit 0
oxlint (changed + new files)	0 warnings, 0 errors
vitest run (desktop-web-surface, prepare-package-set, profile-mcp, host-protocol, host-process)	5 files, 19 tests passed
tsx scripts/verify-cordis-config.ts	184 config files passed
git apply --check / git am on a clean tree	ok

Live check, under the carrier

Launched with the shipped overlay untouched, only DSH_WEB_SURFACE=1 set in the
environment:

Probe	Result
host listens on 127.0.0.1:3199	yes (webServer only exists because the launch opted in)
__DSH_TRANSPORT__ in the renderer	{"ownsHost":…,"webOrigin":"http://127.0.0.1:3199","openStream":…}
upgrade /sidebar/ws/terminal — Origin: dsh-app://app	101 Switching Protocols
upgrade /sidebar/ws/terminal — loopback origin	101
upgrade /sidebar/ws/terminal — Origin: https://evil.example	refused
upgrade — carrier origin but Host: evil.example	refused (Host still has to be loopback/trusted)
/sidebar/ws/agent-terminals, /sidebar/ws/agent-opens — carrier origin	101
shells spawned by the host process	two /bin/zsh -l children
1006 / 1008 in the boot log	none

One suggestion

port: 3199 is a fixed default for the opt-in overlay. If the port matters, allowing
port: 0 and publishing the resolved port through the same transport seat would remove
the last fixed number from the desktop path — the renderer already takes its origin from
that seat, so nothing else has to change.