Produced-file chips bypass the canOpenPath/isLoopback gate that 'show in folder' correctly respects

[mirkpul]

Summary

On a headless server accessed remotely (browser connects over an SSH tunnel to a loopback-forwarded port, but the actual DSH host process has no display), clicking a produced-file chip crashes with a native-command failure instead of being disabled/hidden like the adjacent "show in folder" affordance.

Repro

1. Run dsh web --host 127.0.0.1 on a headless Linux server with no DISPLAY/WAYLAND_DISPLAY, no desktop browser installed.
2. Access it from a different machine via an SSH local port-forward (ssh -L 3080:127.0.0.1:3080 ...), so the browser sees localhost (loopback) but the actual filesystem/host process is remote and headless.
3. Have an agent turn produce a file (e.g. an .svg).
4. Click the produced-file chip in the turn tail.

Actual result

path open failed: path open failed: Command failed: xdg-open /path/to/file.svg
/usr/bin/xdg-open: 882: www-browser: not found
/usr/bin/xdg-open: 882: links2: not found
/usr/bin/xdg-open: 882: elinks: not found
/usr/bin/xdg-open: 882: links: not found
/usr/bin/xdg-open: 882: lynx: not found
/usr/bin/xdg-open: 882: w3m: not found
xdg-open: no method available for opening '/path/to/file.svg'

(Before installing xdg-utils at all, the failure is instead spawn xdg-open ENOENT.)

Root cause

In packages/client/ui-deliverables/src/client/ProducedFiles.tsx, canOpenPath is computed correctly:

const canOpenPath = isLoopback && hostCanOpenPath

and it correctly gates the "show in folder" button:

{hidden > 0 && canOpenPath && (
  <button type="button" className={css.showFolder} onClick={() => { openFile('.') }}>
    {t('produced.showInFolder')}
  </button>
)}

But the per-file chip buttons rendered just above are not gated by canOpenPath at all — they always render as clickable and always call openFile(path) regardless of whether the host can actually open a path natively:

{shown.map(path => (
  <button
    key={path}
    type="button"
    className={css.file}
    title={path}
    aria-label={t('produced.open', { name: path })}
    onClick={() => { openFile(path) }}
  >
    {basename(path)}
  </button>
))}

This is inconsistent with packages/host/apiproxy/src/native-path-opener.ts's own canOpenNativePath(), whose doc comment says headless detection exists precisely "which lets a surface show a path as text instead of offering a button that would spawn xdg-open into nothing." The per-chip buttons don't honor that.

Suggested fix

Gate the chip's clickability (or render it as inert text with a title tooltip showing the full path, matching the doc comment's stated intent) behind the same canOpenPath used for "show in folder", so a non-loopback/headless session degrades gracefully instead of surfacing a native-command failure to the user.

Environment

• Deployment: dsh web --host 127.0.0.1, no desktop environment, accessed via SSH port-forward from another machine.
• OS: Ubuntu 24.04 (server), xdg-utils installed after the fact to test the fallback path (still no method available, as expected on headless).

[Jstn-1g]

I reproduced this at the ProducedFiles component contract: it already derives canOpenPath from both the loopback origin and the current Host capability, but only the overflow Show in folder action consumed that decision. Every visible file chip remained a button and could still call the native opener.

I published a tested reference implementation:

• branch: https://github.com/Jstn-1g/deepseek-harness/tree/reference/discussion-4659-produced-files
• exact commit: Jstn-1g@cbf9735
• official base: b150a551b8d465e31e418e1b2eaf5e79bbb7d28e

The same capability decision now governs each produced-file chip. A capable local Host retains the existing button / openFile handoff. Remote, headless, or unavailable Host descriptions retain an inert basename chip with the full path in title; they cannot issue a native-open request. The folder action remains under the same gate.

Verification on Windows:

• focused component regression: 13/13 passed, with 100% statements / branches / functions / lines for ProducedFiles.tsx
• full GUI lane: 3,994 passed, 4 skipped
• documentation gates: 28/28 passed
• staged lint, whitespace, translation pairing, Host build, and client typecheck: passed
• assembled Web build recorded all 200 client artifacts; its replay suite is not a clean Windows signal because the existing seeded-fixture layer injects raw backslash cwd values into JSON and several scenarios expect bash instead of the assembled pwsh. The produced-files E2E aborts in that shared seed parsing before reaching a behavior assertion.

This is a reference branch against the exact official base above, not an upstream merge.