DeepSeek Harness connects a desktop agent to your models and tools

DeepSeek Harness gives a coding agent a desktop interface and lets you choose the machinery behind it. A model connection supplies the reasoning; file and command tools let the agent work with a repository. Plugins provide those capabilities, and a profile brings the chosen plugins together into a runnable setup.

That flexibility is useful when the work does not fit a single preconfigured assistant. A team might send model requests through its company gateway while reading a local repository, or connect tools that execute commands on another machine. The desktop window can look the same in both cases, even though the model request and the command take different routes.

Consider a hypothetical service repository whose README tells responders to request /health, while its deployment configuration probes /ready. A responder needs to know whether the endpoints serve different purposes or the instructions are stale. Reading the files may answer that question; running the service introduces command execution. Harness can assemble the tools for either task, and its effective profile explains which setup a particular session is using.

What the desktop preview adds

DeepSeek’s v0.2.0-rc.2 release is dated September 29, 2026; it includes desktop command and plugin-management improvements. At the September 30 review, the official product page advertised a worldwide public preview with signed Apple silicon macOS and 64-bit Windows downloads. It did not offer a Linux desktop download. For the Node-based Web UI, the project also documents:

npx @deepseek-ai/dsh web

This is not the project’s first appearance. The repository was already available as a developer preview, and the current README continues to allow compatibility-breaking changes. Packaging the application removes some setup work, but it does not settle what later plugin or configuration changes will mean for a workflow built on it.

The safety notice is direct about a more immediate limit: Harness has not undergone a security audit and should not be regarded as secure or production-ready. It can run commands generated by a model and load third-party plugins. Any network, process, credential or file resource available to its environment may become relevant to what those components can do.

A disposable workspace is consequently a sensible place to learn. To choose the capabilities for that workspace, first look at the configuration that Harness resolves when it starts.

How plugins become a working agent

According to the architecture documentation, startup assembles a Cordis plugin tree from configuration layers. A profile names bundles, retains separately installed plugins and applies its cordis.patch.yml. Bundle layers arrive first; profile and home-level patches and a command-line overlay can then modify them. Reading a bundle alone tells you only part of the story, because a later layer may change the behavior it appears to specify.

An illustrative comparison makes the consequence clearer. A standard Web bundle with local file access and approval prompts creates one kind of assistant. Add remote file and subprocess providers, a custom model gateway or scheduled tasks, and the work can happen in different places or at different times even though the user-facing application remains Harness.

A team supporting both setups now has two different request paths to troubleshoot. A failed file read may involve the local workspace in one profile and a remote provider in the other. The argument in our guide to operational simplicity applies here: support becomes harder as the number of meaningful configurations grows, even if the interface stays tidy. The resolved profile makes those differences visible, so a teammate can trace a failure through the setup that actually ran.

Harness can dump the configuration tree selected for startup. For the Web profile, the following inspection command assumes the dsh CLI is already installed and available in your shell:

dsh --profile web --dump-config

Saving this output makes later configuration changes easier to diagnose: a new provider or patch can be compared with the setup that produced an earlier result. Provider references, paths and plugin settings may contain private environment details, so a copy shared for troubleshooting needs those details removed.

Where model requests and commands go

Installing the desktop application puts the interface on your computer. The selected model provider determines where the conversation is processed. This is useful for a team with an approved company gateway, because it can configure that route while keeping the desktop workflow.

The model configuration guide lists DeepSeek, OpenAI, Anthropic, Moonshot AI and Z.ai among the built-in providers. Custom endpoints can use OpenAI Chat Completions, OpenAI Responses or Anthropic Messages protocols, allowing a company gateway or self-hosted server. With a local inference endpoint, the model call can stay on the machine. With a cloud endpoint, the repository excerpts included in the request travel to that provider. The endpoint therefore determines where the service files in our review are processed.

Credentials have a similar separation between what the interface shows and what the process can use. DeepSeek documents literal keys in $DSH_HOME/.credentials.yaml, with a redacted descriptor sent to the settings interface. Redaction avoids exposing the literal key there; it does not remove the authority associated with it. A permitted plugin, process or host environment may still reach resources available through that credential.

The provider ID, base URL, protocol and model ID therefore belong beside the workspace root and destinations for file operations and commands. Read together, those details let a reviewer follow a request through the system: which content is read, where it is sent, and which environment would carry out a requested action.

Keeping a useful setup reproducible

Once a configuration works for the repository review, saving its important settings makes the next run easier to reproduce. Here, a manifest means that short versioned description: which Harness build ran, which plugins it loaded, and where those plugins sent their work. The following fields help explain a changed result after an upgrade:

Manifest field	Question it answers
Harness and desktop version	Which rapidly changing preview build produced this behavior?
Profile and bundle stack	Which application composition booted?
Installed out-of-tree plugins	Which code extends the shipped profile?
Model provider, endpoint and protocol	Where do prompts and attachments travel?
Workspace root	Which files are in scope?
Filesystem and subprocess providers	Where do reads, writes and commands execute?
Sandbox backend and enforcement result	Which restrictions were actually applied?
Approval policy	Which operations require a person to continue?
Background or scheduled plugins	Can work continue when no one is watching?
Credential references	Which external authority is reachable?

The resolved configuration and installed plugins supply most of this record; the workspace and host environment establish what those settings can reach. If a later review unexpectedly runs a command, comparing the two records can reveal whether a subprocess provider or plugin changed between runs. This gives the record a practical job in troubleshooting rather than making it another inventory to maintain.

Take particular care when moving from the CLI to Desktop. The architecture notes describe Desktop’s own production runtime and reserved desktop profile. Desktop and the npm CLI can share product data while keeping activation and lockfiles separate. Inspecting a Web profile with the CLI consequently cannot establish what the Desktop profile will load; the record needs to describe the instance used for the task.

Comparing a service’s README with its health checks

On a disposable copy of that repository, ask Harness to compare the README, deployment configuration and tests, cite the relevant lines, and propose a documentation correction only if the files support one. The tests may explain whether /health and /ready serve different purposes. This evaluation uses no customer data, production credentials or deployment access.

Asking for a read-only review defines the assignment, but does not enforce it. Mount the repository copy read-only in a disposable virtual machine or container, and constrain outbound access outside Harness. DeepSeek recommends a disposable environment because its own approval and sandbox controls do not guarantee isolation. The trial can then test the quality of the review without depending on the assistant to honor every limit itself.

Before the run, save the manifest and tree hash. Retain the session trajectory, which records the sequence of work and tool calls, so an unexpected result can be connected to what the assistant attempted. Afterward, inspect both process evidence and the repository. These Git checks expose changes in tracked and untracked working state:

git status --short
git diff --exit-code
git diff --cached --exit-code

A useful report would explain what the two endpoints do and show the lines that support its conclusion. If the files do not settle the discrepancy, identifying the missing information is preferable to inventing a correction. The Git checks show tracked-file changes and ordinary untracked files; ignored files and activity outside the repository need separate inspection. The trajectory can also show an attempted write that the environment denied. Together these observations help explain this run, without establishing the security of other plugins or configurations.

If the report identifies a genuine documentation error, a later run could edit the README in the disposable copy. The resulting diff would show whether Harness made the requested correction without changing unrelated material. Running the service to inspect an endpoint introduces command execution instead; that exercise needs a subprocess provider and an environment prepared for the service. A local-model comparison changes a different part of the setup, the provider route. Scheduled reviews add restart, missed-execution and plugin-failure cases.

Keep a new manifest with each of those results. When only one capability changes, the team has a reasonable way to connect a difference in behavior to that change. Alter the model, plugins, patches and permissions together, and even a successful run leaves much more to explain.

How Harness reports command restrictions

The official sandbox documentation describes Harness’s process-sandbox implementations: bubblewrap or Landlock on Linux, Seatbelt on macOS, and a restricted-token and access-control-list backend on Windows. It also reports how completely the selected backend enforced the requested file-effect policy. Crucially for interpreting a trial, a denied command is distinguished from a sandbox runner that failed before the command executed.

Those reports help explain what happened without assuming that selecting “sandbox” produces the same restriction everywhere. Enforcement depends on the backend, host support, requested mode and exposed resources. A credential directory deliberately made available inside the boundary may still be usable by permitted commands. The boundary limits an environment; it does not erase what the environment was given.

For untrusted plugins or prompt-injection-bearing data, keep the whole Harness process behind an external boundary. That is why this trial uses a disposable environment and separately restricted network access. The OpenShell containment guide takes up the harder situation in which an agent may already have changed remote state. A first Harness evaluation need not acquire that recovery problem merely to compare a README with tests.

The cost of maintaining a production workflow

Desktop removes setup work through a packaged runtime, an ordinary update path, and more accessible plugin and trajectory surfaces. For a team exploring repository review, that means more of the experiment can be spent on the question itself: did the assistant explain the endpoint mismatch and make the documentation easier to fix? The saved configuration is useful when repeating or troubleshooting that work.

Production access, regulated or customer data, unattended schedules and unreviewed write-capable plugins change the decision. Those tasks need a dedicated environment, external containment, reviewed plugins, explicitly scoped credentials, backups and an independent way to verify consequential results. If that support is unavailable, keep the work read-only or defer it. Ease of starting the preview does not reduce the cost of recovering from an unwanted change.

There is also a maintenance cost after a promising trial. The preview permits breaking changes, so a plugin-dependent workflow needs pinned versions, upgrade tests against saved profiles and sessions, and a recovery path when a plugin or patch stops composing. Until the team can support that work, a useful experiment should not quietly become a production dependency.

From a file review to a more capable assistant

For the service repository, the first useful result is an explanation of the health-check discrepancy that a teammate can follow back to the files. Harness’s file tools obtain those inputs, the selected model interprets them, and the trajectory records how the session proceeded. Saving the setup alongside that report helps the team repeat the work after the repository or Harness changes.

The next capability follows from what the review needs. A file-only setup may be enough to explain the discrepancy. Editing tools can turn an agreed correction into a diff, while command tools can support a separate run of the service. Those are concrete reasons to customize a profile, and they make the benefit and maintenance cost of each addition easier to understand.

Primary sources

• DeepSeek Harness public preview and desktop downloads
• DeepSeek Harness repository and preview status
• DeepSeek Harness architecture
• DeepSeek Harness Web UI quick start
• DeepSeek Harness model providers
• DeepSeek Harness safety notice
• DeepSeek Harness process sandbox