dsh workspaces: pick a directory, configure & manage them in DSH

A DeepSeek Harness workspace is the project directory where the agent reads and edits files and runs commands; the default root is wherever you launch dsh (cd /path/to/project && dsh web). Click Select Workspace in the Web UI to add and select the directory - the session input stays disabled until you do. Add multiple workspaces and switch anytime; permission-gated operations ask you first (source).

Overview: a workspace is the agent's operating boundary

In one sentence: a workspace is the directory the agent can read, edit, and run commands in - the boundary of every session. Pick the wrong one and the agent works in a place you did not intend. Get started in three steps:

1. Understand the concept: the default root is the directory where dsh was launched - confirm it with pwd first;
2. Configure in the UI: click Select Workspace in the Web UI, add and select the project directory;
3. Manage multiple workspaces: add several directories, switch freely, and approve permission-gated actions in the UI.

Each step is detailed below.

Step 1: the concept and the default root directory

The dsh process treats its invocation directory as the default file system location, but a fresh Web UI does not select any workspace until one is added (source). The key action happens before you launch:

# 1. Confirm the current directory is the project you want the agent to work in
pwd

# 2. If not, switch to it first
cd /path/to/project

# 3. Launch the Web UI from this directory (or the npx no-install version)
dsh web
# or
npx @deepseek-ai/dsh web

Two points:

1. The launch directory decides the default root: cd must come before dsh web;
2. It is not locked in: the default is only a starting point - the Web UI can add any directory as a workspace, not just the launch directory.

Step 2: add and select a workspace in the Web UI

In the Web UI, click Select Workspace, add the project directory where dsh was launched, and select it; until a workspace is selected, the session input is unavailable (source). The steps:

1. Click Select Workspace: the entry point at the top of the Web UI opens the directory list;
2. Add a directory: add the project directory you cd-ed into in step 1;
3. Select it: the session input becomes usable only after selection;
4. Verify the boundary: send something like "Summarize this repository" and confirm every agent action stays inside that directory.

Why select first: it is an official safety design - the agent's operating boundary must be explicit before a session starts, so it never touches unapproved locations.

Step 3: multiple workspaces and permissions

One profile can hold several workspaces that you switch between anytime - the agent only operates in the currently selected one, and operations requiring approval under the current permission policy ask you in the Web UI first (source). Management essentials:

1. Switch between workspaces: maintain a directory list under Select Workspace and switch per project without restarting;
2. What the agent can do: read and edit workspace files, run commands, delegate work, and maintain plans - all inside the current workspace;
3. The approval mechanism: operations gated by the permission policy are confirmed by you in the Web UI before execution; the agent stops and waits on anything uncertain;
4. Isolate with profiles: for different plugin sets per task, run dsh --profile <name> web to create separate profiles with independent workspaces and plugins.

Once the workspace is set: add session and tool plugins

With the workspace configured, the next step is extending the agent - pick session and tool plugins in DSH Plugin Hub under Settings > Plugin Center. Install the Hub itself:

dsh plugin --profile web add dsh-plugin

Restart dsh web and open Settings > Plugin Center: browse 4,600+ community plugins by category - session management, file tools, development, and workflow automation - click a card to install with live progress. A workspace plus the right plugins makes a deliverable agent environment.

dsh-plugin-hub · Plugin Center

Notes

One sentence: the workspace decides what the agent can touch, permissions decide what it can do. Three reminders:

1. Never launch from the root: starting in ~ or a drive root hands the agent run of the whole disk - always cd into a concrete project before dsh web;
2. Think before switching: session context and operation history bind to the workspace; when switching, make sure the agent never reads directories it should not;
3. Do not tap through approvals: when the Web UI asks, read the operation (command, target path) first and only then allow - it is the last gate.

Sources: DeepSeek Harness docs - Quickstart, dsh CLI README, DeepSeek Harness official site