LAN Mode

To reach the harness from a phone over Wi-Fi, the harness has to listen on more than loopback. This page is the short version of harness/README.md, which is the canonical document and also carries the full troubleshooting section.

Read Security before doing this. The harness has no authentication. While it binds 0.0.0.0, anyone on that network can drive the agent, including running commands on the host computer. Only do this on a network you trust — never on public, guest or conference Wi-Fi.

If you only want to try the app, use adb reverse over USB instead — see Getting Started. It needs none of this.

Why there is a patch at all

The harness web server binds 127.0.0.1 by default, and dsh web --host 0.0.0.0 is intentionally blocked, precisely because there is no auth layer yet. The supported way to change server configuration is the harness's own user patch layer, so that is what this uses — no forked code, one file, reversible.

Steps

1. Find your harness home. $DSH_HOME, or ~/.dsh — on Windows typically C:\Users\<you>\.dsh. The web profile lives at:

<harness-home>/profiles/web/cordis.patch.yml

2. Add the webserver row. Create the file if it does not exist; merge this row if it does. It is the same row shipped as harness/cordis.patch.lan.yml:

- id: webserver
  name: '@deepseek-ai/dsh-host-webserver'
  inject: [webStartup]
  config:
    host: '0.0.0.0'
    port: 3080

3. Restart the web profile.

dsh web

The URL line now names a LAN address as well as loopback:

dsh web: http://127.0.0.1:3080 (LAN: http://192.168.1.20:3080)

4. Connect. In the app, tap Scan network, or enter 192.168.1.20 / 3080 manually.

Trusted hosts

The /api trust fence checks the Host header of every request. When the server binds all interfaces it derives and auto-trusts its own LAN IP literals, so connecting by IP needs no further configuration.

A hostname is not covered by that derivation. If you want to reach the harness as myhost.local, start it with:

dsh web --trusted-host myhost.local

Otherwise the harness answers 403 and the app reports "The harness rejected this address" — the connection is fine, the name is what it dislikes.

Firewall

On Windows, an unrecognised network lands in the Public profile, which blocks inbound TCP — the single most common reason a correctly patched harness is unreachable. In an elevated PowerShell:

New-NetFirewallRule -DisplayName "DeepSeek Harness (dsh web)" -Direction Inbound `
    -Action Allow -Protocol TCP -LocalPort 3080 -Profile Private,Domain

Then set the network to Private: Settings → Network & internet → your network → Network profile type.

Confirming it took effect

netstat -ano | findstr 3080

0.0.0.0:3080 means the patch is in effect. 127.0.0.1:3080 means it is not — re-check the file path and restart dsh web.

What stays loopback-only

LAN mode does not unlock everything. By harness design these remain refused for network clients and are shown read-only in the app, with a banner: settings, credentials, model discovery, host directory pickers, and agent-preset authoring. See Compatibility.

Reverting

Delete the patch row and restart dsh web. The harness is back to loopback-only.