Fix Blank DeepSeek Harness Web UI: Not Opening

When the DeepSeek Harness Web UI will not open, confirm the process is running and the port is right; when it is blank, check the workspace selection, then the browser console and conflicting interface DSH plugins.

Overview

Debug the Web UI access chain in this order: process → port → page → workspace → plugins. "Not opening" usually lives in the first two segments; a blank screen in the last three. Classify by symptom first: a "connection refused" message usually means the process is not running or the port is wrong; endless loading or timeouts usually mean network or proxy issues; a page that opens but stays blank points to the workspace and plugins. dsh web is an alias for --profile web and opens at http://127.0.0.1:3080 by default (source). DSH is still in developer preview and UI details may change — follow the official docs.

DeepSeek Harness Web UI not opening: confirm the process and port

The default address is http://127.0.0.1:3080; when it will not open, confirm the process is running and the port is not busy. Check three things:

1. Process running: watch the address printed in the terminal when you start npx @deepseek-ai/dsh web — do not use the wrong port.
2. Port busy: start on another port — --port is the Web app's own argument and follows the profile (source):

dsh --profile web --port 8080

3. Address: confirm you visit http://127.0.0.1:3080 and not an old port; on remote or container deployments use the LAN/mapped address — 127.0.0.1 only points at the local machine.
4. Port in use: before switching ports, check whether 3080 is actually taken by another program — lsof -i :3080 on macOS / Linux, netstat -ano | findstr 3080 on Windows; only switch ports after confirming it is busy, otherwise the problem persists on the new port.

If the process is confirmed running and the port is free but the page still refuses to connect, check whether a system firewall or a local proxy is intercepting the loopback address — 127.0.0.1 traffic is usually untouched, but some proxy tools and VPN clients redirect it. Try visiting http://localhost:3080 instead of 127.0.0.1, or temporarily disable the proxy and refresh.

If the DSH process itself will not start (it errors out on launch), do not check the port yet — that is an install or dependency issue; see Fix DeepSeek Harness Install Errors.

Blank DeepSeek Harness Web UI: check the workspace, then the browser console

When the page opens but is blank, confirm the workspace is selected, then read the console errors. In order:

1. Workspace: the new Web UI selects no workspace until you add one — click Select Workspace to join your project directory, and only then does the session input become usable (source). Without this step the UI looks "broken".
2. Browser console: press F12 and read the errors — resource load failures usually mean network or cache issues, JS errors usually mean plugin or version issues. Hard-refresh (Cmd+Shift+R on macOS, Ctrl+Shift+R on Windows/Linux) to rule out stale cache.

If it is still blank after both steps, open an incognito window (to rule out browser extensions) and check the Network panel for failed requests — red-marked requests tell you exactly which frontend resource failed to load. If the errors cluster around model-related requests (401, 404, etc.), the UI itself may be fine — turn to Fix DeepSeek Harness Model Connection.

Another case worth distinguishing: the page shell renders but every request spins forever. The Web UI depends on the backend answering model and session requests — if the shell loads yet nothing responds, the backend is likely stuck on a model call (again see Fix DeepSeek Harness Model Connection) or on plugin code during startup. In that case the terminal running dsh web usually prints the error — read it before touching the browser.

Conflicting interface DSH plugins

When the screen is blank and the console shows JS errors, suspect interface plugin conflicts. Interface plugins (sidebar, terminal UI, themes, etc.) change UI rendering, and several loaded at once can override each other. Debug steps:

1. Run dsh --dump-config to see which interface plugins are currently loaded (source).
2. Uninstall the interface plugins one by one with dsh plugin --profile web remove <package>, refreshing the page after each to see whether it recovers.
3. Reinstall them one at a time to identify the conflicting combination, and keep the one that does not conflict.

Change only one plugin per step and refresh after each uninstall; uninstalling several at once makes it impossible to tell which one conflicts. Start with the most recently installed interface plugins — the newest install is usually the conflict source.

If you do not want to uninstall a plugin just for diagnosis, an alternative is to temporarily comment out its dependency line in the profile's package.json and restart dsh web — the plugin is not removed, just not loaded, which is enough to test whether it caused the blank screen. Restore the line once the conflict is identified.

Interface plugins (sidebar, terminal UI, etc.) are manually curated under the interface category in DSH Plugin Hub — when debugging a broken UI, first review which interface plugins you installed from the Hub and apply the conflict steps above.

Notes

1. If the Web UI cannot be fixed and the task is urgent: use headless mode — dsh --profile headless "your task" creates a session, prints the final answer, and exits without a browser (source).
2. Switching ports does not affect session data; sessions stay per-project under ~/.dsh/sessions.
3. A blank screen is usually not a broken DSH — it is an unselected workspace or an interface plugin conflict.
4. After switching ports the browser may cache the old address; use the new address and hard-refresh once.

Source: official Quickstart, dsh CLI README