DeepSeek Harness: which workspace is behind the desktop window?

Imagine a colleague opening DeepSeek Harness and asking it about the project’s README. Yesterday the answer described the laptop copy. Today it describes an older file somewhere else. The window looks the same. Behind it, a different plugin may be supplying the files.

Harness is a desktop interface around a configurable coding agent. Plugins connect its models and tools; a profile assembles the setup for a session. That makes it adaptable to an existing workflow, but the desktop icon alone cannot explain where its answers come from.

Consider a hypothetical project whose README names /health while deployment probes use /ready. Perhaps those routes serve different purposes. Perhaps the documentation is stale. Reading the files may settle it; running the service adds another capability. The profile tells you what this particular session can do.

A desktop package around a configurable agent

The September 29, 2026 v0.2.0-rc.2 release added desktop-command and plugin-management improvements. At the September 30 review, the product page offered worldwide public-preview downloads for Apple silicon macOS and 64-bit Windows, not Linux desktop. The Node-based Web UI also has this documented launch:

npx @deepseek-ai/dsh web

That package saves assembly work for the README question. It does not remove the need to understand the setup. The repository already existed as a developer preview, and its README still allows compatibility-breaking changes. Easier initial packaging is not a guarantee that later plugins and configuration will stay compatible.

The safety notice says Harness has not been security-audited and should not be considered secure or production-ready. Model-generated commands and third-party plugins can use the files, processes, network and credentials their environment exposes.

Use a disposable project copy for this endpoint question, without production credentials. Before deciding whether the answer is right, establish which copy of the README the profile will actually read.

Which plugin supplied this README?

A file-reading plugin might open the laptop repository, until a later patch replaces it with a provider reading a remote workspace. The request still says “read README,” but the bytes now come from another machine. The architecture guide describes Cordis assembling bundles, keeping separately installed plugins and applying cordis.patch.yml. Later profile, home-level and command-line patches can override earlier settings. Inspect the combined result, not just the first configuration file.

Test commands have a destination too: the subprocess provider determines where they run. A scheduled plugin may continue working after the window closes. For the README comparison, knowing the file source and command destination comes before interpreting the answer.

The simplicity guide discusses the support cost of meaningful configuration differences. Saving the resolved profile gives the next person the setup that actually produced the result, rather than a description of what somebody intended to configure.

If the dsh command-line interface is already installed, inspect the selected Web configuration with:

dsh --profile web --dump-config

Keep that output with a useful result for later comparison. Before sharing it, remove private paths, provider references and settings. A configuration dump can disclose more of the environment than a teammate needs.

The local window can use a remote model

A local desktop does not require a local model. If the selected provider points to an approved company gateway, that remains the route for inference, the model’s work on the request.

The provider guide lists DeepSeek, OpenAI, Anthropic, Moonshot AI and Z.ai. Custom endpoints can use OpenAI Chat Completions, Responses or Anthropic Messages protocols. These define how requests are formatted, not where they stay. A cloud endpoint receives the included README excerpt; a local endpoint can keep that inference on the machine.

A masked key in settings is hidden from sight, not necessarily unavailable to a plugin. DeepSeek documents literal keys in $DSH_HOME/.credentials.yaml and redacted descriptors in the interface. A process with access to the stored credential may still use it. Inspect the host and plugin’s access as well as the screen.

Read the provider, base URL, protocol and model beside the workspace root and tool destinations. Together they show which text is read, where the model processes it and where any command executes.

Keep the route with the result

After a useful README comparison, save the build, loaded plugins and destinations. If tomorrow’s run cannot find the same file, those details let a colleague investigate a changed route instead of attributing it to the model’s mood.

A remote filesystem provider could be reading an older copy with the old endpoint. The answer may accurately describe that copy and still be wrong for the laptop project. The resolved configuration identifies the route; the workspace and exposed host resources determine what lies along it.

Desktop has its own production runtime and reserved profile. The architecture notes say Desktop and npm CLI may share product data while keeping activation and lockfiles separate. A Web CLI dump therefore does not certify what a Desktop session loads.

Let the endpoint comparison stay a reading task

In our disposable copy, look for the lines explaining the two endpoint names before changing either one. Tests might show different purposes rather than a typo. This hypothetical trial supplies no customer data, production credentials or deployment access.

A request to “read only” does not stop a capable tool from writing. A read-only mount in a disposable VM or container enforces the file limit, while external controls constrain outbound access. DeepSeek recommends disposable surroundings because internal controls do not guarantee isolation. The model can investigate the disagreement without receiving a production service to modify.

Keep the initial manifest and file-tree hash for comparison. The recorded sequence of tool calls distinguishes reading tests from trying to run them. Afterward, process evidence and these repository checks answer different parts of what happened:

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

An explanation of both endpoints, supported by source lines, would resolve the reading question. An unexplained difference would remain open. Neither establishes whether tools changed anything. These Git checks cover tracked and ordinary untracked files; ignored files and activity outside the repository need separate inspection. The tool history might show a denied write even when the tree is unchanged. Those are possible observations, not results from a run for this article.

If the files establish stale documentation, the next job can be that one diff. If behavior remains uncertain, a prepared subprocess environment may be needed to run the service. Testing local inference changes the model route instead. Each is a different question with a reason for adding a particular capability.

Save a new manifest after each change. One changed capability makes the comparison easier to explain. Changing the model, plugins, patches and permissions together leaves more possible reasons for a different result.

Did the restriction run, or did startup fail?

Suppose the remaining question needs a test command. A running sandbox denying it differs from a sandbox that never started. The first reports enforcement; the second leaves the intended protected runner unavailable, so investigate startup before retrying. The sandbox guide distinguishes these outcomes and reports enforcement completeness for Linux bubblewrap or Landlock, macOS Seatbelt and Windows restricted-token/ACL backends.

Those backend names do not promise identical restrictions on every host. Read the report for the actual host and mode to see what started and how completely it applied. A permitted operation can still use a deliberately exposed credential. A “sandbox” selection in the window does not establish all the limits needed for the proposed command.

Keep the disposable outer environment while checking the inner restriction. The OpenShell guide examines a different issue: recovering remote effects that have already happened.

Keep the setup understandable after an upgrade

After an upgrade, the colleague may get the old endpoint answer again. A changed plugin or winning patch could have routed the read to another repository copy; it need not mean the model forgot the earlier explanation.

Production access, regulated data, unattended schedules and unreviewed write plugins bring requirements this small trial cannot settle. Keep a read-only role or defer expansion if the team cannot support those responsibilities.

The saved configuration gives the colleague something specific to compare: the file provider, the patch that took precedence and the runner receiving commands. Pin a working version as a starting point, then check whether an upgrade follows the intended route. Desktop packaging saves some assembly work without maintaining that agreement automatically.

Trace the answer back to the files

A useful first result is modest: the repository supports an explanation of health versus readiness, with remaining uncertainty visible. The interpretation, cited lines and recorded route let someone judge that explanation together. None alone establishes that the whole agent works.

Back at the familiar window, the question is sharper now. Did it read the same README, through the same provider, from the same workspace? The profile turns a plausible answer into something the colleague can trace to the files it describes.

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