[BUG] "Add Workspace" silently does nothing when dsh web is launched as a detached or background process on Windows or macOS

[SrtaEstrella]

New, fully reproducible trigger that is not covered by existing discussions. Related but distinct from #929 (WSL), #702 (macOS foreground latency), and #851 (macOS occasional no-op). This post adds the detached or background server process case and proposes one root-cause fix that covers the whole family.

Summary

When dsh web is started by a process that has no visible interactive desktop (for example an automation agent, a detached service, a background task, or any launcher that spawns the server without an attached console window), clicking Add Workspace / Choose workspace in the browser UI does nothing. No dialog appears and no error is logged. The server is healthy, but the feature looks dead.

This is reproducible 100 percent of the time under that condition. It is distinct from the WSL and macOS cases already discussed elsewhere because the trigger here is simply "the server process has no foreground desktop", regardless of which OS is involved.

Environment

• Package: @deepseek-ai/dsh@0.1.0-rc.6
• Bind address: 127.0.0.1:3080
• Affected platforms: Windows and macOS (both select the native backend by default; Linux resolves to the in-browser picker and is unaffected)
• Server launched by: a background or detached parent process with no attached console window

Steps to reproduce (detached or background process)

1. Start the server from a parent that has no visible console window, for example node lib/bin.js web spawned by an automation agent or a detached background task on Windows or macOS.
2. Open http://127.0.0.1:3080 in a browser.
3. Click Add Workspace.
4. Observe: nothing happens. No folder picker opens. The click appears to be a no-op.

Expected behavior

Clicking Add Workspace should open a usable folder selection UI, either the native OS dialog (when a desktop is actually available) or the in-browser folder tree (when it is not).

Actual behavior

No UI opens. The native Win32 or macOS folder dialog is spawned by the server process, but that process has no interactive desktop foreground, so the dialog is created behind other windows (or with no focus) and is effectively invisible to the user. The frontend receives no path and no error, so the click looks like a no-op.

This is not a missing native dependency. The koffi binary is present and user32.dll loads correctly. The dialog is created, it is simply never visible to the user.

Root cause

The directory picker backend is resolved in dsh-host-directory-picker-auto through resolveDirectoryPickerBackend. The native backend is selected only when all three conditions hold:

• bindHost === "127.0.0.1"
• no SSH_CONNECTION and no SSH_TTY in the environment
• platform is win32 or darwin

In every other case the resolver falls back to browse (the pure in-browser folder tree). The design already follows the good principle that ambiguous cases resolve to browse. Linux, SSH, and remote scenarios all land in browse and work fine.

The flaw is that loopback + no SSH + desktop OS is treated as an unambiguous signal for native, but it is actually ambiguous. The server can be running with no interactive desktop at all (a detached agent, a background service, a headless launcher). In that case the native backend relies on a visible desktop and silently fails to surface its dialog.

Why existing discussions do not cover this

• WSL 中安装不能选择工作区 #929 covers the WSL / no-display case (and uses the cordis.patch.yml workaround). WSL reports platform === "linux", so it never even enters the native branch; its mechanism is different from ours.
• [Bug][macOS][v0.1.0-rc.6] “添加工作区”缺少即时反馈，目录选择器启动延迟且可能未置前 #702 covers a macOS foreground latency where the native picker is delayed or not brought to front.
• 点击选择工作区没有反应 #851 covers an occasional macOS no-op.

None of them describes the detached or background server process trigger, which is a separate and fully deterministic way to hit the same silent native failure. Posting this separately keeps the new trigger discoverable instead of buried inside the WSL thread.

Workarounds

Option A (persistent, recommended): force the browse backend via cordis patch. This is the solution posted in discussion #929 and works for this case too. Edit ~/.dsh/profiles/web/cordis.patch.yml:

- id: directory-picker
  disabled: true
- insert:
    - id: directory-picker-browse
      name: '@deepseek-ai/dsh-host-directory-picker-browse'
    - id: ui-directory-picker-browse
      name: '@deepseek-ai/dsh-client-ui-directory-picker-browse'

This permanently routes workspace selection to the in-browser folder tree.

Option B (quick test): set SSH_CONNECTION to force the browse backend. Confirmed: resolveDirectoryPickerBackend({ bindHost: "127.0.0.1", platform: "win32", env: { SSH_CONNECTION: "x" } }) returns "browse".

SSH_CONNECTION="127.0.0.1 22 127.0.0.1 54321" node lib/bin.js web

Suggested fix

Treat the native backend as requiring an interactive desktop. When the native path would be chosen but the spawning process has no visible or foreground desktop (detached service, background agent, headless launcher, or no console owner), degrade to browse. This keeps the existing philosophy (ambiguous cases resolve to browse) and removes the silent failure mode.

A minimal implementation could detect the absence of an interactive session (for example, no attached console on Windows, or a known headless or service parent) and route those cases to browse instead of native.

Scope and why it matters

Normal interactive use, a developer running dsh web in their own terminal, is unaffected and works as designed. Remote, SSH, and container scenarios already resolve to browse, so they are unaffected too.

The realistic trigger is narrow today. A human at a terminal rarely launches the server detached, and most production deployments already run over SSH or in containers where browse is selected. The case becomes more relevant as AI assistants and automation tools increasingly launch dev servers on behalf of users. Consolidating the WSL case (#929), the macOS latency case (#702), and this detached process case under one root cause (native backend without a usable desktop degrades to browse) should make the fix simpler to land once.

[shinjiyu]

这就是 #358 / #576 / #998 那条缝：官方入口是 Node + npx + 自己填密钥 + 自己选文件夹。Windows 上还没有官方一键启动，后台拉起时「添加工作区」还会没反应。

easy-dsh 只做进门，不是 Electron 桌面壳，也不是 dsh 插件。

• 没有 dsh 就装
• 密钥贴一次，写进 ~/.dsh/.credentials.yaml
• 选文件夹后走官方 API：workspace.create + session.create
• 浏览器打开时输入框已经能用
• Windows 有 install.cmd / 启动.cmd

安装：

npx github:shinjiyu/easy-dsh

介绍帖：#1738
Repo: https://github.com/shinjiyu/easy-dsh