DeepSeek Harness v0.1.7-rc.1
DeepSeek Harness v0.1.7-rc.1: Session V4 & Migration
- Author
- DeepSeekAgent.io Editorial Team
- Published
- Updated
DeepSeek released dsh-v0.1.7-rc.1 on September 23, 2026. The first 0.1.7 release candidate brings terminals, remote workspaces, Headless operation, MCP Resources, browser and Computer Use backends, Plugin Manager, Agent Teams, and Session V4 into the rc line.
For users, DSH now behaves more like a complete workspace than a chat surface: terminals, previews, change review, web pages, Sub-agent conversations, and Team state can all appear in the sidebar. For extension authors, the larger change is a coordinated migration across settings, Agent Presets, Sessions, PTC, Remote APIs, and plugin compatibility checks.
Release and installation
| Check | Current status |
|---|---|
| GitHub Release | dsh-v0.1.7-rc.1, Pre-release |
| Exact npm version | 0.1.7-rc.1 published |
| Successor | 0.1.7-rc.2, now npm latest and next |
| Position | First 0.1.7 release candidate |
Pin rc.1 when reproducing its behavior:
npx @deepseek-ai/[email protected] web
An unversioned install now resolves to rc.2. Record the actual DSH version before comparing behavior or diagnosing a migration.
From chat surface to integrated workspace
Rc.1 consolidates several capabilities introduced across earlier alphas:
- multi-tab Web terminals with shell selection and refresh recovery;
- file-change review in cards or the sidebar, with line and side-by-side diffs;
- Word, Excel, PowerPoint, CSV, and TSV previews;
- sidebar views for URLs, Sub-agent conversations, and submission plans;
- background commands and workflows that wake their original Session on completion;
- a live Agent Team panel with member and task navigation.
This changes the right upgrade test. Do not stop after confirming that a model answers. Run a complete task that edits files, starts a background command, produces a diff, and delivers a file for review.
Remote workspaces, Headless, and MCP Resources
DSH can run its interface and Agent locally while file, command, and PTC tools use a remote workspace over SSH. Headless can read tasks from standard input, resume with --session-id, and emit newline-delimited JSON events through --json.
MCP moves to the official v2 SDK with protocol negotiation, paginated tool discovery, Resource discovery and reading, and URI Templates. A server may provide Resources without providing Tools.
For remote use, document three boundaries separately: where DSH runs, where workspace files live, and which system user executes commands. Web user terminals run with system-user permissions independently of Agent sandbox mode, so terminal authority and Agent-tool authority are not interchangeable.
DeepSeek V4.1 and vision input
Rc.1 adjusts image resizing, token estimates, default request size, and encoding quality for DeepSeek V4.1. It also fixes pi-ai vision models being treated as text-only and allows input types to be adjusted manually.
The official DeepSeek adapter now uses the Messages API exclusively and can reuse uploaded images through the Files API. Custom configurations that still depend on the legacy protocol setting or Chat Completions URLs must migrate. During diagnosis, record the real model ID, Provider, and declared input types instead of relying only on the display name.
Session V4: understand the data boundary before upgrading
Session logs move to V4, with a batch migration tool for developers. Client Sessions can also coexist across multiple instances. The synchronous history APIs snapshotEvents, eventAt, and ownEvents are deprecated, and attachments stored only in custom events are no longer read or exported automatically.
A practical upgrade sequence is:
- finish tasks that are still writing data;
- back up the Harness home and critical workspaces;
- pin and retain the original version for recovery tests;
- open copies of long, attachment-heavy, and Sub-agent Sessions;
- verify turns, attachments, tasks, and deliverables after migration;
- only then allow the new version to write production data.
Rolling back the executable does not roll back the data format. An older release may not understand Sessions already written by rc.1.
Plugin, Preset, and settings migrations
Plugin Manager supports installation, configuration, activation, and runtime unloading, while installation and startup now enforce declared DSH compatibility. Plugins can declare live-update fields, and Bundles can load multiple patch files in order.
Agent Presets are declared and installed through plugin Bundles. Settings move into the current Profile's plugin configuration, and the legacy settings.yaml is imported only once.
Extension authors should verify:
- migration from
agent/session-startto asynchronous serialagent/created; - renamed PTC packages, services, and
workflow-ptc; - workspace reads through
readBytes; spill-policy.maxInlineBytesreplaced bymaxInlineTokens;- directory-based Agent Presets repackaged as Bundles;
- the declared DSH compatibility range includes rc.1.
Agent Team and Sub-agent boundaries
Experimental Team mode standardizes on spawn_teammate, disables subagent and subagent_fork, and raises the default teammate limit to 16. Continuable Sub-agent chains separately default to eight live children and a delegation depth of one.
The two mechanisms serve different collaboration models. Teams use named members, a task board, and continuing coordination; Sub-agents fit one-off or tree-shaped delegation. Check which model an existing Prompt, Profile, or plugin expects instead of only checking whether a familiar tool name is present.
Security and reliability fixes
Rc.1 fixes a Windows sandbox path that could delete outside an authorized directory and blocks cross-workspace deletion. It also addresses process-wide blocking from large streamed tool arguments, concurrent first-load failures for native addons, and retained data in long-lived Gateway streams.
Auto review, browser backends, and Computer Use remain experimental. Test read-only browsing, workspace writes, system commands, and local-computer interaction as separate permission scenarios, recording when approval appears, which user executes a command, and how failures recover.
Rc.1 upgrade checklist
| Area | Validate after upgrading |
|---|---|
| Sessions | V4 history, attachments, long conversations, and multi-instance notices |
| DeepSeek Provider | Messages API, Files API, model ID, and image input |
| Settings | Profile plugin configuration and one-time legacy import |
| Presets | legacy directory Presets migrated into Bundles |
| Plugins | compatibility range, unloading, live updates, and failure recovery |
| Remote | SSH files, commands, binary previews, and execution identity |
| Agent Teams | spawn_teammate, member limits, and task-board workflow |
| Security | Windows deletion boundaries, terminal authority, and approvals |
Rc.1 marks the point where the 0.1.7 architecture entered the candidate line. Users can read it as the integrated-workspace release; maintainers of Profiles, plugins, and long-lived Sessions should treat it as a defined data and extension migration.
Related reading
- DeepSeek Harness v0.1.7-alpha.2 update
- DeepSeek Harness v0.1.7-rc.2 update
- DeepSeek Harness Plugin Manager
- DeepSeek Harness remote development
References
- Official DeepSeek Harness v0.1.7-rc.1 release
- Full changes from v0.1.5-rc.3 to v0.1.7-rc.1
- @deepseek-ai/dsh 0.1.7-rc.1 on npm
FAQ
Is rc.1 still the npm default?
No. npm latest and next now point to 0.1.7-rc.2. Rc.1 installs only when its exact version is pinned.
What should ordinary users check first?
Back up Sessions and settings, then verify the model, images, file changes, background work, and final-delivery flow. Users without custom plugins or Presets do not need to perform every developer migration.
Is rc.1 a stable release?
It is a release candidate and GitHub still marks it as a Pre-release. Pin versions and keep verified backups for long-running tasks and important workspaces.