DeepSeek Harness

A model answers requests; a harness supplies the execution environment, tools and session workflow around those requests. The official Web guide describes file access, commands and other agent operations. That makes a repository task a useful first trial.

Our recommendation is to begin with a read-only summary of a small project you understand. Avoid making your first check depend on a plugin marketplace, browser integration, external login or deployment. Add those only when the task actually needs them. A plugin being listed or installed does not show that it loaded successfully in your current session.

Start from npm

With Node.js installed, the official quick start provides this entry:

npx @deepseek-ai/dsh web

The documented default is http://127.0.0.1:3080. Use the URL printed by your process, since flags and launch environment can affect it. For an SSH launch, the README says the host URL is printed rather than opening a local browser.

Configure a model

Open Settings → Models, enter your DeepSeek API key and save. The official guide says the route becomes usable without a server restart. Keep the key in the product’s configuration flow; do not paste it into a task, screenshot or handoff document. Other providers require their own provider configuration.

Choose a workspace

Use Choose workspace to add and select the project directory. The fresh Web interface has no selected workspace even though the process has an invoking directory. The composer remains unavailable until you select a workspace. Web UI guide.

Check these separately

• The local page opens.
• A model request reaches the intended provider.
• The session is bound to the intended project.
• The answer can cite a real file in that project.

If only the first check works, setup is incomplete. Record the failed layer rather than calling the whole product unavailable.

Editorial first-task prompt; not an executed test:

Read this workspace without editing files or running shell commands.
Identify its main entry point, package structure and test entry points.
Support each statement with a repository-relative file path.
List anything you could not determine as unknown.
Do not install plugins, open external accounts, commit or deploy.
Stop after returning the repository map.

Check that every cited path exists in the selected workspace. Compare the proposed test entry point with package scripts or project documentation. If the agent asks for access it does not need for this read-only task, resolve that before expanding scope.

For a later code change, hand it one failing behavior and a clear expected result. Require a diff and an actual check result. A completed chat turn, a plan or a claim that a test passed is not a substitute for inspecting the changed files and the test output.

The official safety notice describes access to model-generated commands, files, processes, network resources and third-party plugins. It warns that approval controls and sandboxing do not guarantee isolation. Limit the trial environment and credentials to what the task actually needs.

The project is in developer preview and explicitly warns of breaking changes. Keep a record of the version and selected model when reproducing a problem. Update deliberately, especially before reusing a workflow that previously worked.

Distinguish a route error from a task error

If the configured provider has no registered adapter, the model cannot start through that route. Check the saved provider/model selection and the provider setup before debugging the page or repository task. This guide does not claim that every provider is supported by every profile.

When handing work to another agent, leave the original workspace path, current diff, checks and remaining restrictions. Use one writer for the same files at a time. These are our handoff recommendations, not guarantees supplied by the product.