Troubleshooting

The app names the failure it hit rather than saying "could not connect", so find the sentence you are looking at below. Almost every fix is on the computer — the phone is the device that reports the problem, not the one that causes it.

Connection failures

Nothing answered

Nothing answered at 192.168.1.20:3080. Usually the computer's firewall is blocking incoming connections on port 3080 — allow it and try again. Some routers also stop Wi-Fi devices from reaching wired ones.

Packets are being dropped, not refused, which means something silently ate them.

1. The computer's firewall, in the great majority of cases. On Windows an unrecognised network is treated as Public and blocks inbound TCP. 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 connection to Private (Settings → Network & internet → your network → Network profile type).

2. The router. Many have AP isolation / client isolation, which stops wireless clients from reaching other devices; guest SSIDs almost always do. Check that the phone's IP and the computer's IP share their first three octets.

Refused the connection

192.168.1.20 refused the connection. The harness only listens on the computer itself unless LAN mode is enabled — enable it and restart the harness. If you changed the port, check it matches.

The computer is reachable and nothing is listening on that port. Normally the harness is still bound to loopback. Confirm on the computer:

netstat -ano | findstr 3080

127.0.0.1:3080 → the LAN patch is not in effect; re-check LAN Mode and restart dsh web. 0.0.0.0:3080 → it is, so verify the port in the app matches the one the harness printed.

The harness rejected this address

The harness rejected this address — Connect using the computer's IP address instead of its name, or start the harness with --trusted-host.

HTTP 403 from the trust fence. The harness is running and healthy; it does not trust the Host header you arrived with. It auto-trusts only the IP literals derived from its bind address, so:

• connect by IP instead of hostname, or
• start it as dsh web --trusted-host myhost.local.

The same fence is why a scan may list a harness as Not trusted: it answered, but it refuses this device.

Not on this phone's network

192.168.1.20 is not on this phone's network. This phone is on 192.168.0.x — connect both devices to the same router network…

Checked before any probing, because nothing on the phone can route there. The two devices are on different subnets — typically a guest or IoT SSID, which is deliberately kept separate. Different bands of one SSID (2.4 GHz vs 5 GHz) are normally the same subnet and are fine.

This is also why Scan network finds nothing: the sweep only walks the phone's own /24.

Compare ipconfig (Windows) / ip addr (Linux) / ipconfig getifaddr en0 (macOS) on the computer with the address the app reports for the phone.

Its event stream would not open

192.168.1.20 answered, but its event stream would not open. A VPN or private-DNS proxy on this phone can block WebSocket connections — turn it off and try again.

The HTTP calls succeed but the WebSocket upgrade does not. This one is on the phone: a VPN, private DNS, or an HTTP proxy. Turn it off and retry.

It is not a DeepSeek Harness

Something answered at 192.168.1.20:3080, but it is not a DeepSeek Harness. Check the port the harness printed when it started.

Something is listening, but host.describe did not answer like a harness — usually another service on that port. Use the port from the dsh web output.

No device on this network answers to that name

No device on this network answers to "myhost". Use the computer's IP address instead — run ipconfig on Windows to find it.

Name resolution failed. Use the IP address. If you need the name to work, it must also be passed to dsh web --trusted-host, or you will simply trade this error for a 403.

Enter the computer's IP address and a port between 1 and 65535

Validation, before anything is sent. Check for a typo, a stray space, or an empty port field.

Harness version warning

Harness version X may be incompatible with this app (built for 0.1.0-rc.5).

Non-blocking, and usually harmless — the app parses leniently and renders anything it does not recognise as a generic entry. If something is broken, that warning is the first thing to mention in a bug report. See Compatibility.

After you are connected

Search only finds session and workspace names

This harness has content search turned off, so only session and folder names are matched.

Expected. Full-text search over message content is a harness-side service that is off in the shipped harness configuration, so the app matches session titles and workspace names locally — which is exactly what the harness's own sidebar does under the same configuration. Where a host does provide content search, those hits are merged in.

Settings are read-only

Settings are read-only over the network. Open the harness on its own computer to change them.

By harness design, not a limitation of the app. Settings, credentials, model discovery, host directory pickers, and agent-preset authoring are loopback-only and answer 403 to a network client. Change them on the computer, or connect over adb reverse where the app is a loopback client. See Compatibility.

A control is missing entirely

The app hides controls the connected harness does not offer, rather than showing dead ones. If your build composes no permission presets, no command catalog, or no plugin inventory, those surfaces disappear and you may see "This harness build does not provide that" or "This harness does not expose a command list". Nothing is broken.

No notifications arrive while the app is in the background

Check, in order:

1. Android's notification permission for the app is granted (it is requested on first launch).
2. Settings → Notifications — the individual switches for turn complete, goal, and needs-action.
3. Settings → Notifications → Keep connected in background — without the foreground service, Android may freeze the app and no events arrive to notify about.
4. Notifications for a session you are currently looking at are suppressed on purpose.

Battery optimisation on some vendor ROMs will still kill background work; exempting the app there helps. See Notifications.

The plugin list is empty

This harness lists no plugins.

The harness exposes no plugin inventory, or composes none. The view is read-only in any case — the calls behind the web UI's plugin configuration are loopback-pinned.

An update dialog appeared

The app checks GitHub for a newer release on start. It cannot install anything itself — the dialog only names the version and links to the release page. Declining keeps it away until a later version appears, and Settings → About → Check for updates switches it off. It is the only request the app makes to anything other than your harness.

The turn stopped early

Stopped, Turn aborted, Turn failed, Max tokens reached, Retry scheduled in Ns and Retrying… are all reported by the harness about the run itself, not by the app about the connection. The transcript keeps whatever arrived before the stop.

Still stuck

Open an issue with the app version and protocol baseline (Settings → About), the harness version, which route you used (USB / LAN / same device), and the exact sentence the app showed: Issues.

Security problems should go to the maintainers privately instead — see Security.