DeepSeek Harness desktop: inspect the profile before trusting the app

DeepSeek Harness makes it easier to start working with a desktop coding agent: download the application, choose a workspace, connect a model, and give it a task. What happens next depends on the configuration you chose. Two installations can look much the same while using different models, tools, and access to the machine.

That flexibility comes from Harness’s plugin architecture. A plugin supplies a part of the application, such as a model connection, file access, or approval prompts; a profile brings a selection of those parts together. Understanding that selection helps you answer practical questions before the first task: where will the files go, which commands can run, and what can the assistant change?

The desktop public preview is a useful way to explore those choices. We will follow them from installation through a small repository-review trial, keeping a record of the configuration so that the result can be understood and repeated.

What the desktop preview adds

DeepSeek’s v0.2.0-rc.2 release is dated September 29, 2026 and includes desktop command and plugin-management improvements. As reviewed on September 30, the official product page describes a worldwide public preview with signed downloads for Apple silicon macOS and 64-bit Windows. That page does not offer a Linux desktop download; the project also documents this Node-based Web UI command:

npx @deepseek-ai/dsh web

The project predates this week’s desktop attention. DeepSeek had already opened the repository as a developer preview, and its current README still warns of compatibility-breaking changes. The installer simplifies getting started, while the underlying software remains in preview.

DeepSeek’s own safety notice is more explicit. It says the project has not undergone a security audit and should not be treated as secure or production-ready. It can execute model-generated commands, load third-party plugins, and access whatever network, process, credential, and file resources the environment makes available.

For a first experiment, this points toward a disposable workspace with a carefully chosen set of capabilities. The next step is to find out how Harness assembles that set.

How a profile assembles the application

The architecture documentation describes a Cordis plugin tree assembled at startup. In everyday terms, Harness builds the running application from layers of configuration. A profile names its bundles, retains separately installed plugins, and applies a profile-specific cordis.patch.yml. Bundle layers load first, followed by profile and home-level patches and any command-line overlay. Later layers can therefore change the configuration you started with.

For example, one profile may combine the standard Web bundle with local file access and approval prompts. Another may send file operations and commands to a remote environment, add scheduled tasks, or use a custom model gateway. Both run Harness, but the assistant has different ways to do its work.

The interface can look nearly identical while the effective behavior differs. This is the same configuration problem described in our guide to operational simplicity: fewer visible controls do not create a simpler system if responders must still distinguish hidden combinations of state. The effective configuration needs to be visible enough to explain what the current session can do.

To inspect the tree that a selected profile will start, Harness provides this command:

dsh --profile web --dump-config

The output gives you a starting record of the configuration. Review it before storing or sharing it: paths, provider references, and plugin settings can reveal details of your environment that should remain private.

Where the model actually runs

Running a desktop application locally does not tell you where its model runs. The question comes up in the current Reddit discussion because Harness supports several ways to connect one.

The model configuration guide documents built-in providers including DeepSeek, OpenAI, Anthropic, Moonshot AI, and Z.ai. It also supports custom endpoints using OpenAI Chat Completions, OpenAI Responses, or Anthropic Messages protocols. A custom endpoint can be a company gateway or a self-hosted server. If the endpoint points to a local inference server, the model call can remain local. If it points to a cloud provider, the desktop interface still sends model requests to that provider.

The same separation applies to credentials. DeepSeek says literal keys are stored in $DSH_HOME/.credentials.yaml, while the settings interface receives a redacted descriptor. That is preferable to returning secrets to the browser, but it does not make the credential harmless. A plugin, process, or host environment with permitted access may still reach resources associated with that key.

A useful configuration record therefore names the provider ID, base URL, protocol, model ID, workspace root, and destination of file operations and command execution. Together, those fields show where content and commands go, whether the setup is wholly local or uses remote services.

Keep a short record of the configuration

The record can be a short manifest: a versioned description of the profile you are testing. The fields below help another reviewer reconstruct its behavior without inventorying every package in the repository.

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?

Build that record from the effective configuration and installed plugin list, then compare it with the workspace and host environment. When a plugin or patch changes, reviewing the difference makes the new capability visible before the next task begins.

This is especially important for the desktop application. The architecture notes say Desktop ships its own production runtime and reserved desktop profile. Desktop and the npm-installed CLI can share product data while keeping package activation and lockfiles separate. A profile you inspected through the Web CLI is not automatically proof of what the Desktop profile loads.

Try a small repository review

Consider a hypothetical team evaluating Harness against a disposable copy of a small repository. The first task is deliberately narrow: read the README and tests, identify one inconsistency, and produce a proposed diff without modifying the working tree. The environment contains no production credentials, no customer data, and no route to a deployment system.

The request describes the desired task; the environment needs to enforce its limits. For this trial, put the repository copy in a disposable virtual machine or container, mount it read-only, and restrict outbound access outside Harness. This follows DeepSeek’s safety guidance, which recommends a disposable environment because Harness’s own sandbox and approval controls do not guarantee isolation.

Record a tree hash and the manifest before the task, and retain the session trajectory, which shows the sequence of work and tool calls. Afterward, inspect the repository and process evidence. These Git checks help you see whether the tracked or untracked working state changed:

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

If the task succeeds and the checks are clean, the result supports a narrow, useful conclusion: this profile completed this read-only task in this restricted environment without changing the repository. A denied write attempt adds evidence about the restriction itself. Neither outcome amounts to a security audit of the platform.

Next, change one capability at a time. If the team wants Harness to edit the copied repository, create a new trial with write access to that copy and a reviewable diff. If it wants a local model, change only the provider route and verify the destination. If it wants scheduled work, test the scheduler in the disposable environment and confirm what happens after restart, missed execution, or plugin failure.

Changing one capability at a time keeps the result understandable. A new manifest and observation let the team connect any difference to the change it made, rather than guessing among simultaneous model, plugin, patch, and permission changes.

Understand what the sandbox restricts

Harness provides a process-sandbox interface with platform-specific implementations. The official sandbox documentation describes Linux support through bubblewrap or Landlock, macOS through Seatbelt, and Windows through a restricted-token and access-control-list backend. It also reports how completely the selected implementation enforces the requested file-effect policy, and distinguishes a denied command from a sandbox runner that failed before execution.

That reporting helps explain an unexpected result. Restrictions depend on the selected backend, the host’s support, the requested mode, and the resources you expose. If the configuration permits access to a credential directory, commands allowed inside that environment may be able to use it.

For untrusted plugins or data that may carry prompt injection, keep an external boundary around the Harness process. This article’s trial uses a disposable environment and independent network restriction for exactly that reason. Our OpenShell containment guide addresses the later recovery problem when an agent may already have changed remote state. Harness evaluation should avoid reaching that problem until the local capability set is understood.

When the trial needs stronger controls

The desktop application is a meaningful improvement for someone who wants to explore Harness without assembling the Web UI from source. It packages the runtime, adds a normal update path, and makes the plugin and trajectory surfaces easier to reach. For a disposable repository, synthetic documents, or a personal experiment with no sensitive credentials, that convenience can justify a bounded trial.

The decision changes when the task requires production access, regulated data, customer material, unattended schedules, or write-capable plugins whose behavior has not been reviewed. In that case, the public preview’s convenience is insufficient. Use a dedicated environment, external containment, a reviewed plugin set, explicit credential scope, backups, and an independent way to verify every consequential result. If those controls are not available, keep the task read-only or defer it.

The same boundary applies to compatibility. A plugin-dependent workflow may be useful during preview, but the repository explicitly allows breaking changes. Do not make it a production dependency until the team can pin versions, test upgrades against saved profiles and sessions, and recover when a plugin or patch no longer composes.

What the first trial should leave behind

At the end of the trial, keep the manifest, model route, workspace restrictions, tool-call record, and independent file checks together. They give the next reviewer enough context to reproduce the configuration and decide whether an additional permission is worth testing.

The desktop preview makes that first experiment more approachable. Its flexibility becomes useful when you can explain how the selected parts affected the work. Inspect the resolved profile, constrain one task outside the agent, and expand only when the observed behavior matches the capability you intended to add.

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