[Feature] Official remote access for DSH: a supported phone path (not a 0.0.0.0 bind)

[jimmyLC]

Hi DSH team — thanks for the early preview; I run the Desktop edition daily and the plugin architecture has been a pleasure to work with.

Context. macOS, DSH Desktop 0.2.0-rc.2. My agent runs are long, and I want to approve tool calls and check progress from my iPhone instead of staying at the desk. Today there is no supported way to do that.

What I found (all verified on my machine):

• The GUI binds 127.0.0.1 only. --host 0.0.0.0 is deliberately rejected — "it would expose remote code execution to the network". I agree with that reasoning and am not asking you to change it.
• Every /api method and WebSocket requires a browser session: POST /api/host.describe without the cookie returns 401 unauthorized.
• The web UI already ships manifest.webmanifest with display: fullscreen, so it is PWA-installable — nice, and it is most of what a phone needs. What is missing is a sanctioned way to reach it.

What we do instead, and why it is not good enough:

1. Remote desktop (VNC/Jump Desktop over Tailscale). Works, but you drive a full desktop on a six-inch screen — the opposite of what a phone is good at.
2. dsh web + tailscale serve + PWA. Reported to work ([Feature] Mobile-friendly web UI: responsive layout, touch support, and PWA polish #4429), but it needs a separate dsh web host, a --trusted-host entry, and the process launch token. On the Desktop edition none of that is reachable: the desktop host fixes its own args, and there is no documented way to obtain a trusted authority or the launch URL for the phone.
3. Third-party plugins. They require installing third-party code inside the host process — your own plugin-manager docs note that installed host plugin code runs outside the workspace sandbox — usually route session traffic through the author's relay, and several enable a remote terminal by default that runs as the host user and is explicitly not governed by agent approvals.
4. The ecosystem keeps breaking on auth changes. One companion (0x5446/rowel, issue 好棒 #13) is currently broken against 0.2.0-rc.2 precisely because /api began requiring a browser session and it has no code path to obtain one; another is pinned to 0.1.0-rc.6.

The ask, in priority order:

1. A documented contract for a same-machine companion to obtain a legitimate browser session (the same token→cookie exchange a local browser performs, bound to the authority it was issued for). That alone would let the existing ecosystem stop scraping the startup token and stop asking for a network bind.
2. Make it work for the Desktop edition, where the host is started by the Electron shell rather than by dsh web flags.
3. Capability-scoped permissions for paired devices, with remote terminal/exec off by default and clearly separated from agent approvals.
4. Ideally: a first-party mobile client, or at minimum a mobile layout ([Feature] Mobile-friendly web UI: responsive layout, touch support, and PWA polish #4429) reachable over an officially documented transport.

I am not asking for a default 0.0.0.0 bind. The gap is a supported path that is not a raw network bind. Happy to test a preview build or send logs.

[talaon2]

--host 0.0.0.0 is deliberately rejected — "it would expose remote code execution to the network".

This justification is simply invalid! Wouldn’t the right approach be to use a trusted verification method to gain access?