directory-picker-auto resolves native behind reverse proxies (tailscale serve etc.) - proposed trustedHosts fix

[Yuuichu]

Summary

When dsh web serves remote browsers through a reverse proxy on a loopback bind (tailscale serve, cloudflared, SSH remote forwarding), the adaptive directory picker resolves the native backend: resolveDirectoryPickerBackend chooses native for any 127.0.0.1 bind on darwin/win32, assuming every browser behind the bind sits at the host display. A remote browser cannot drive the host OS chooser — the dialog opens on the unattended host, and picking a workspace directory fails from a phone or laptop.

Evidence this is a real gap

• The shipped web composition itself works around it: apps/web/tests/pin-browse-picker.overlay.yml pins the browse interaction for the Playwright smoke because "the resolved native backend cannot be driven from the page".
• Remote deployments must hand-apply the same disable+insert overlay to be usable (there is a growing ecosystem of docs for exactly this: tailscale serve + --trusted-host guides).

Proposed fix (small, boot-time only)

Add a trustedHosts signal to DirectoryPickerHostFacts, sampled once at boot from the composing bundle's webRuntime service (the same authorities the /api browser-trust fence serves). A non-empty sample resolves browse before the platform display signals:

export function resolveDirectoryPickerBackend(facts: DirectoryPickerHostFacts): DirectoryPickerBackendKind {
  if (facts.bindHost !== '127.0.0.1') return 'browse'
  if (facts.trustedHosts.length > 0) return 'browse'
  if (present(facts.env.SSH_CONNECTION) || present(facts.env.SSH_TTY)) return 'browse'
  // ...unchanged
}

A deployment that names --trusted-host authorities (or derived LAN literals) serves remote browsers by definition, and the in-browser picker works everywhere. Deployments without authorities keep the prior resolution (attended loopback still resolves native). The bundle's directory-picker row injects webRuntime, mirroring the existing connection row pattern.

Verification

• 31 tests green (unit cases + real-Loader composition with a webRuntime stub; bundle web-app tests unchanged)
• Full-repo pnpm run typecheck and pnpm run lint pass

Status

Reproduced on a real tailscale serve + --trusted-host deployment (phone browser could not pick a workspace directory), fixed locally, and shipped to the ecosystem as a plugin: dsh-remote-picker (npm dsh-remote-picker@0.1.0, install: dsh plugin --profile web add dsh-remote-picker). Happy to inline the full 10-file diff here if useful.

[Yuuichu]

Update: reproduced, implemented, verified, and shipped as an ecosystem plugin

Since posting, this has been validated end-to-end in a real remote deployment and released to the community:

Reproduction (real-world): dsh web --trusted-host <host> behind tailscale serve --bg 3080. From a phone browser, Settings → workspace → pick directory fails: the native OS chooser opens on the unattended host and cannot be driven remotely. The shipped web composition already pins the same workaround for its own Playwright smoke (apps/web/tests/pin-browse-picker.overlay.yml).

Proposed change (small): add trustedHosts to DirectoryPickerHostFacts, sampled once at boot from the composing bundle's webRuntime service (row-injected, mirroring the connection row). Non-empty → resolve browse before the platform display signals. A deployment that names --trusted-host authorities serves remote browsers by definition; deployments without authorities keep the prior resolution. Full diff is 10 files (+190/-30): resolve.ts, index.ts, bundle cordis.patch.yml, both spec files, bilingual README + i18n hashes, bilingual agent note.

Shipped as a plugin: dsh-remote-picker (npm: dsh-remote-picker@0.1.0, install: dsh plugin --profile web add dsh-remote-picker) — disables the auto row and mounts the browse pair with a boot-time self-check.

Verification: 31 tests green (unit cases + real-Loader composition with a webRuntime stub), full-repo pnpm run typecheck and pnpm run lint pass.

Happy to inline the full upstream diff in this thread if it helps; the core idea is one line of signal + one branch — remote-access authorities are already a deployment fact available at boot.