Check the DeepSeek Harness candidate tag before replacing your working setup

Check the DeepSeek Harness candidate tag before replacing your working setup

If you are already experimenting with DeepSeek Harness, there is another candidate tag to inspect: dsh-v0.2.2-rc.2. That is not a reason to overwrite a working installation. DeepSeek still labels the project a developer preview and explicitly warns that compatibility-breaking changes will occur. This release also changes search configuration and default worktree cleanup, making existing settings part of the upgrade check.

The launch command is not a version guarantee

The README at the new tag gives the familiar npm entry point. Install Node.js and run npx @deepseek-ai/dsh web to start the local Web interface. However, that command contains no version selector. Its presence in a tagged README does not establish that an npm invocation will fetch this particular candidate.

For a source checkout, switch to the matching tag and open apps/cli/package.json. The version field should read 0.2.2-rc.2, matching the change shown in the release commit. For an npm installation, inspect that field in the package.json inside the actual @deepseek-ai/dsh package directory being used. A version recorded in the repository does not verify the package fetched on your machine.

The source route also has a build step. DeepSeek's instructions install dependencies, build the repository, and then launch the Web application. The README says the launch command uses existing build artifacts without rebuilding them. After switching revisions, run pnpm run build again before starting with pnpm dsh web, rather than relying on artifacts left by the previous checkout.

Check search settings and cleanup before upgrading

DeepSeek's release notes say web search now defaults to DeepSeek Search API. Search and Fetch can use separate account or API-key billing choices, while older providers and custom settings require migration. Existing configuration therefore deserves a check, not just the installed version number.

Archiving a session now cleans up eligible Git worktrees by default while preserving branches and commits. If you need the local directories to remain, disable cleanup before archiving.

These are documented behavior changes, not features inferred from a version bump or task improvements we have independently tested. Our recommendation is to test this revision separately rather than promote it straight into an existing workflow. Read the project's safety notice, preserve the current environment, and check whether your plugins load and your configuration still behaves as intended. In particular, confirm the cleanup setting before archiving a session whose local directory you want to keep.

Share this article