[web] "Open file" opens on the host machine and fails silently (no feedback)

[xiejin77]

Summary

In the web UI, clicking a file path (e.g. a file mentioned in a conversation, or the "open file" action on a tool result) does not open the file on the user's machine. It instead triggers host.openPath which opens the file on the host server machine, and the call is wrapped in a silent catch so the user gets no feedback at all.

Evidence (from the published package, line numbers from the bundled build)

• dsh-client-ui-conversation/lib/client.js ~line 9731-9734: openFile calls workspaces.openPath(resolveWorkspacePath(cwd, path)).catch(() => {}) — the .catch(() => {}) swallows every error silently.
• dsh-client-runtime/lib/client.js ~line 9993-9996: openPath invokes api.host.openPath({ path }), which on the host runs a native "open with default app" (openNativePath in dsh-host-apiproxy/lib/index.js ~line 2346-2365).

Impact

• On a localhost deployment the host is the user's machine, so it may work by accident — but still silently.
• On a remote web deployment the file is opened on the server, which the user cannot see/access — the click appears to do nothing. Combined with the silent catch, there is zero feedback.

Suggested fix

• Web clients should not map "open file" to a host-native open. Options:
  • open the path in a workspace-relative view / offer "copy path" + "download", or
  • at minimum remove the .catch(() => {}) and surface a clear message ("opened on host" or "use the desktop client").
• The open semantics should be explicit per client kind (web vs desktop).

Happy to PR if you point at the preferred behavior.