Allow dsh web --host to bind a specific LAN interface

[Pummelchen]

What happens now. dsh web --host accepts only the loopback and all-interfaces literals (@deepseek-ai/dsh-host-webserver lib/index.js:141):

host: z.union([z.const("127.0.0.1"), z.const("0.0.0.0")]).required(),

and the Web app refuses the second one at startup (@deepseek-ai/dsh-web-app lib/startup.js:40):

error: --host 0.0.0.0 is intentionally not supported yet for safety: it would expose remote code execution to the network; use 127.0.0.1 instead

Consequence. There is no way to expose the Web UI — or anything built on it, such as a LAN manager for a small fleet of harness instances — to another machine on the same network. A specific interface (the LAN address the machine already has) cannot be named at all.

What makes this worth revisiting. The fence a LAN bind would need already exists and already runs: @deepseek-ai/dsh-web-app's resolveLanTrust (lib/index.js:83) computes the non-internal IPv4 addresses, folds them into trustedHosts for the /api browser-trust fence, and the ready banner announces a LAN candidate (lib/index.js:199). All of it is gated on bindHost === "0.0.0.0", which startup rejects, so on the CLI path it is unreachable.

Note also that with a non-wildcard bind that function returns an empty lanAddresses and a trustedHosts of only the explicit --trusted-host values, so a specific-interface bind would need its own address added to the fence to be usable.

Suggested shape. Accept an explicit interface literal — --host 192.168.1.5 — and continue to reject the all-interfaces wildcard, or gate that wildcard behind an explicit opt-in. Binding one address exposes the listener only on the subnet that address is on, and lets the existing trust fence do its job. If remote code execution is the concern, an opt-in flag that also requires a token or an allowlist is the safer form than a silent wildcard bind.

Acceptance. dsh web --host <a non-internal IPv4 literal of this host> serves on that address and prints it in the ready banner; a browser on another machine on the same subnet can load it; and the /api fence still rejects a Host header that is neither the bound address nor an explicit --trusted-host.

(Re-verified against @deepseek-ai/dsh 0.1.6-alpha.2; the line numbers above are that version's.)

[PerryLink]

Your reading of the tree is correct, with one correction about which check is the gate.

What blocks a specific interface

Not the startup check. packages/bundle/web-app/src/startup.ts:74-76 refuses the literal 0.0.0.0 and nothing else — the option itself is an unrestricted .option('--host <host>', 'bind host') (:51), so --host 192.168.1.5 passes the action untouched and is published to the bundle patch, which feeds the webserver row: host: !!js ctx.webStartup.host ?? '127.0.0.1' (packages/bundle/web-app/cordis.patch.yml:136-139).

The rejection happens one layer down, in the webserver's own schema: host: z.union([z.const('127.0.0.1'), z.const('0.0.0.0')]).required() (packages/host/webserver/src/index.ts:126), above the comment that names the type as "the two supported values are loopback and all-interfaces" (:59-61). So an interface literal dies at schema validation; the wildcard dies earlier, at the CLI guard, before the schema ever sees it.

Your LAN-trust reading holds, and its second half is the sharper point

resolveLanTrust branches on the wildcard literal (packages/bundle/web-app/src/index.ts:126-130, with ALL_INTERFACES_HOST at :82), so any other bind returns lanAddresses: [] and a trustedHosts of only the explicit --trusted-host values (:131). The banner reuses that same snapshot for its (LAN: …) line (:263-271). And the fence accepts a non-loopback Host only when it appears in trustedHosts (packages/client/connection/src/api-request-trust.ts:103), wired to 403/401 at packages/client/connection/src/rpc-host.ts:97-100). A specific-interface bind would indeed need its own address folded into that list, exactly as you wrote it.

On the security consideration

The stated reason is in the error text itself — "it would expose remote code execution to the network" (startup.ts:75). One thing worth putting on the record for that discussion: "requires a token" is already true, so an opt-in flag would not be adding authentication. /api requires the process launch token's signed cookie on top of the fence — requestRejection returns 403 from isTrustedApiRequest and then 401 from browserAuth.isAuthenticated (rpc-host.ts:97-100) — and that token is minted into the index URL by authenticatedUrl (packages/client/connection/src/browser-auth.ts:223-247). What a LAN bind changes is therefore not the credential but the reach: the listener moves from a socket only local users can open onto one every host on the subnet can reach, while the entry credential is printed in the ready banner (web-app/src/index.ts:271) and lives on in every tab that URL was pasted into. Whether that trade is acceptable is a deployment call, and not one I can make for the project.

What a user can do today

The listener is loopback or wildcard only, so remote access has to arrive at loopback. The documented path is an SSH launch: the URL still prints, the browser handoff is suppressed, and the client or editor owns the forwarded address (packages/bundle/web-app/README.md:62, :151; apps/cli/reference/README.md:98; README.md:27). I grepped for an explicit ssh -L / LocalForward recipe and found none in the tree — the docs describe the SSH case rather than spelling out the forwarding command, so that part is 未验证 as documented guidance. A local proxy or tunnel that connects to 127.0.0.1 also reaches the listener, and in that arrangement the fence is not the obstacle.

Not verified: the line numbers you quote from the published lib/ builds (lib/index.js:141, lib/startup.js:40, lib/index.js:83, :199). I read the sources at HEAD ddefc45 (tag dsh-v0.1.6-alpha.2), where every fact above sits at the paths given.