Skip to main content
All posts
Guide

DeepSeek Harness Web UI Guide: Workspaces, Sessions, Permissions

How the DeepSeek Harness Web UI works: choosing a workspace, sending tasks, approval popups, permission presets, directory pickers, and the plugin ecosystem.

The DeepSeek Harness (dsh) Web UI runs locally at http://127.0.0.1:3080, and its core flow is: configure a model under Settings → Models, choose a workspace directory, then start a session and send tasks. Everything else — permission presets, the directory picker, /compact, and the entire visual layer — is either a built-in default or a swappable plugin. This guide walks through the parts you'll actually interact with.

Getting to the Web UI

npx @deepseek-ai/dsh web

dsh web is a hardcoded alias for dsh --profile web, and it starts a local HTTP server bound to 127.0.0.1 by default. If you haven't configured a model provider yet, see Setting Up Your DeepSeek API Key and Models before continuing.

Why you can't bind to 0.0.0.0

The --host flag exists, but 0.0.0.0 is intentionally not supported. The documented reasoning is direct: exposing the Web UI to the network would expose remote code execution, since the agent can run shell commands and write files. Some users have tried routing around this with socat or a port-forward setup (Discussion #76); the workspace loader and file picker reportedly still misbehave in that configuration, so it isn't a clean workaround. If you need remote access, use your own trusted tunnel (SSH port-forward, a VPN) pointed at 127.0.0.1, rather than trying to bind the server itself to a public interface.

Workspaces

A workspace is the directory root dsh treats as the agent's working environment. You can't start a session without choosing one — the "new session" flow blocks until a workspace is selected.

There are two directory-picker backends:

BackendHow it works
directory-picker-native (with -auto variant)Uses the OS's native folder dialog
directory-picker-browseAn in-app, browser-rendered folder browser

On Windows specifically, the native picker depends on a native binding called koffi, which has a known install failure mode (directory picker failed: win32 folder dialog worker exited before reporting a result, Discussion #30). The documented fix is to reinstall with --ignore-scripts, then edit ~/.dsh/profiles/web/cordis.patch.yml to disable the native picker plugins and insert directory-picker-browse plus its client UI package instead — full command sequence in our platform install guide.

Once inside a workspace, dsh automatically loads any AGENTS.md or CLAUDE.md file it finds at the root, up to a 65,536-byte render budget, and folds that content into the agent's context for every session in that workspace.

Sessions and the agent loop

Inside a workspace, you start a session and send a task. The agent can read/write files, run shell commands, and delegate to subagents, streaming its plan and tool calls as it works. A few session-level options worth knowing:

  • Minimal preset — a built-in stripped-down agent mode: system prompt fixed to You are a helpful software engineer assistant., with only bash and str_replace_editor tools mounted, no other prompt sections or model-facing plugins. Useful when you want the smallest possible surface area for a task.
  • /compact — a human command (not a model-facing tool) that triggers dsh's context-compaction machinery, backed by the compaction family of packages, to shrink the conversation history without losing the working state.
  • Session content is indexed with an in-memory SQLite store for the duration of the session.

Permissions and the approval popup

Every new session gets a permission preset — a paired sandbox mode + approval policy. dsh ships two by default:

PresetSandbox modeApproval policy
workspace-write (default for new sessions)Writes constrained to workspace root + platform temp dirs; network unrestrictedask — you'll see a popup for actions outside that boundary
danger-full-accessNo sandboxing at allnever — nothing is confirmed, everything just runs

A third sandbox mode, read-only, exists but isn't one of the two default presets — it's available if you configure a custom preset for it. When the agent attempts something the current policy flags, you'll get an inline popup asking to allow or deny; nothing happens silently under the default ask policy. Custom presets can be defined in configuration, though the name custom itself is reserved and can't be reused as a preset name.

If you're setting this up for a shared team environment rather than solo use, see DeepSeek Harness Permissions and Sandboxing and Running DeepSeek Harness in a Team for the sandbox-backend and policy details that don't fit in this guide.

The plugin layer: what's built-in vs. what you add

Almost everything visible in the default Web UI beyond the core chat flow — sidebars, themes, file mention pickers, notification badges — is itself a Cordis plugin, the same mechanism used for tools and model adapters. That means the stock Web UI is intentionally plain, and most of the "polish" people associate with competing tools comes from community plugins rather than built-in features.

dsh plugin --profile web add github:zhu1090093659/dsh-web-ui

That installs dsh-web-ui-all, a bundle of Web UI plugins covering a task board, Git graph, and expanded sidebar panels — one of the most-starred entries in FindHarness's UI category. Other popular directions:

Browse the full set in UI Enhancements, or see the install mechanics (npm vs. GitHub, the allowBuilds prompt) in How to Install DeepSeek Harness Plugins.

FAQ

Can I access the Web UI from my phone or another computer?

Not directly — --host 0.0.0.0 is unsupported for safety reasons, since exposing the port exposes remote code execution to the network. Use a trusted tunnel or port-forward aimed at 127.0.0.1 instead.

Why does the Web UI keep asking me to approve actions?

That's the default workspace-write + ask permission preset working as intended — it prompts for anything reaching outside the workspace-write sandbox boundary. Switch to danger-full-access if you want a fully unsandboxed session with no prompts (understanding the tradeoff), or configure a stricter custom preset.

What's the difference between the minimal preset and a normal session?

The minimal preset locks the agent to a fixed system prompt and only two tools (bash, str_replace_editor), skipping every other prompt section and model-facing plugin. A normal session includes whatever tools and prompt content your installed plugins register.

Do I have to pick a new workspace every session?

You choose a workspace when starting a session; it becomes the root for that session's file access. Whether it's remembered as a default for your next session is a Web UI convenience detail worth checking directly in the app, rather than something documented as fixed behavior.

Is the default Web UI missing features on purpose?

Largely, yes — dsh's "everything is a plugin" architecture means the maintainers keep the core small and let the community ship UI improvements as installable plugins rather than baking every feature into core. See UI Enhancements for what the community has built on top.

Next steps