Bug report about: "Add Workspace" button is unresponsive on Linux desktop (native directory picker never surfaces) title: "[Bug] Add Workspace unresponsive on Linux desktop — native picker (zenity) dialog never surfaces" labels: bug

[longforus]

---

name: Bug report
about: "Add Workspace" button is unresponsive on Linux desktop (native directory picker never surfaces)
title: "[Bug] Add Workspace unresponsive on Linux desktop — native picker (zenity) dialog never surfaces"
labels: bug

---

Environment

• DSH version: 0.2.0-rc.2
• OS: Linux desktop, Wayland session (XDG_SESSION_TYPE=wayland) with XWayland (DISPLAY=:0)
• Native chooser binaries present: zenity and kdialog
• No SSH (SSH_CONNECTION / SSH_TTY unset)
• Accessing the Web GUI via http://127.0.0.1:3080

What happened

Clicking the sidebar "Add workspace" (+) button produces no visible response —
no OS dialog, no in-app dialog, no error toast.

Root cause

@deepseek-ai/dsh-host-directory-picker-auto resolves the interaction at boot
(resolveDirectoryPickerBackend in packages/host/directory-picker-auto/src/resolve.ts):

bindHost === "127.0.0.1"                               → pass
ssh === false                                          → pass
platform === "linux"                                   → has zenity + DISPLAY/WAYLAND_DISPLAY → "native"

So the composition mounts dsh-host-directory-picker-native +
dsh-client-ui-directory-picker-native. The native backend then runs:

zenity --file-selection --directory --title="Select Workspace Directory"

On this machine the zenity dialog does not surface in front of the browser
(presumably a Wayland/XWayland session mismatch, or the dialog opens on a
different display/workspace). Because the native client occupant
(NativeDirectoryFlow) is renderless and its pick() promise stays pending
while zenity is open, the workspace flow stays busy:

directoryBusy = flowOpen || pickingFolder   → stays true

createWorkspaceShortcutControls().add then silently ignores subsequent clicks
(its directoryBusy guard), so every further click on "Add workspace" is a
no-op.

Net effect: no dialog, no error, no feedback.

Steps to reproduce

1. On a Linux desktop with a Wayland session, zenity installed and DISPLAY
   set, start dsh --profile web.
2. Open http://127.0.0.1:3080 in the browser.
3. Click the "+" (Add workspace) button in the workspace sidebar.
4. Observe: nothing happens.

Workaround

Pin the interaction to the in-app browser picker in the profile's
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'

Suggested fixes

1. Add a timeout / failure fallback for the native picker so a non-surfacing
   dialog cannot wedge directoryBusy forever, and surface the failure to the
   user.
2. Make resolveDirectoryPickerBackend more conservative on Linux — e.g. prefer
   browse on Wayland sessions, or when the browser origin is not on the same
   display.
3. Give the native flow a cancellation/timeout path so a pending pick() can
   release the busy state instead of silently swallowing further clicks.

[PerryLink]

你这条我能给出确切机制：Linux 上 native 要求"有 chooser 且 有显示变量"，而判定只在启动时做一次，没有回退

1. 判定逻辑（HEAD = dsh-v0.2.1-alpha.1，逐字）

packages/host/directory-picker-auto/src/resolve.ts:50-54：

if (facts.bindHost !== '127.0.0.1') return 'browse'
if (facts.ssh) return 'browse'
if (facts.platform === 'darwin' || facts.platform === 'win32') return 'native'
if (facts.platform !== 'linux' || !facts.linuxChooser) return 'browse'
return present(facts.env.DISPLAY) || present(facts.env.WAYLAND_DISPLAY) ? 'native' : 'browse'

同文件 :16 的采样类型就写着 Partial<Record<'DISPLAY' | 'WAYLAND_DISPLAY', string>>，:42-44 也说明"ambiguous 一律判 browse"。

⇒ 你这个环境（Linux + Wayland、本机 127.0.0.1、非 SSH、zenity/kdialog 已安装、WAYLAND_DISPLAY 有值）会被判成 native——所以 DSH 是去调原生选择器了，而不是"没反应"。你看到的"按钮无响应"很可能是"原生对话框没浮出来"（Wayland 下的 GTK/portal 问题），而进程侧可能已经执行过那次调用。

2. 关键缺陷：判定是一次性的，没有回退

resolve.ts 是在启动时采样一次并定下后端的；没有"原生选择器失败 ⇒ 改用 browse"这条路径。⇒ 于是：

• 后端选了 native；
• 原生对话框没出现；
• 用户看到的是"点了没反应"，而且没有任何提示——这与你在 Linux/Wayland 上观察到的完全一致。

建议把诉求写成两条（第二条是根治）：

1. 原生选择器调用失败或超时 ⇒ 回退到网页内选择器（browse）——即在运行时允许一次降级，而不是只在启动时判一次；
2. 给用户一个显式开关（例如配置项/命令行参数强制 browse），这样在 Wayland 这类环境下能自救。

3. 你可以现在就做的规避（不依赖修复）

在没有显示变量的会话里启动，判定就会落到 browse。例如：

env -u WAYLAND_DISPLAY -u DISPLAY dsh web

或在 SSH/无头会话里启动（facts.ssh 为真也会判 browse）。如果这样按钮就正常了，那就等于实证了上面的判定链——这也是给维护者最有力的一条证据。

4. 请补三样（把这条从"没反应"变成"可定位"）

1. zenity --file-selection --directory 在你这台 Wayland 会话里能否弹出（直接命令行跑一次）——这一步能立刻区分"DSH 没调"与"调了但没显示"；
2. 服务端终端的输出（若原生调用失败，通常在那里有痕迹）；
3. echo $XDG_SESSION_TYPE $WAYLAND_DISPLAY $DISPLAY 的实际值。

一条边界

我确认的是**判定逻辑本身（:50-54）与"只在启动时判一次、无运行时回退"这一结构。"zenity 在你那台机器上没浮出来"**以第 4 节的实测为准——我没有 Wayland 环境可复现。