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

CheckCurrent status
GitHub Releasedsh-v0.1.7-rc.1, Pre-release
Exact npm version0.1.7-rc.1 published
Successor0.1.7-rc.2, now npm latest and next
PositionFirst 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:

  1. finish tasks that are still writing data;
  2. back up the Harness home and critical workspaces;
  3. pin and retain the original version for recovery tests;
  4. open copies of long, attachment-heavy, and Sub-agent Sessions;
  5. verify turns, attachments, tasks, and deliverables after migration;
  6. 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-start to asynchronous serial agent/created;
  • renamed PTC packages, services, and workflow-ptc;
  • workspace reads through readBytes;
  • spill-policy.maxInlineBytes replaced by maxInlineTokens;
  • 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

AreaValidate after upgrading
SessionsV4 history, attachments, long conversations, and multi-instance notices
DeepSeek ProviderMessages API, Files API, model ID, and image input
SettingsProfile plugin configuration and one-time legacy import
Presetslegacy directory Presets migrated into Bundles
Pluginscompatibility range, unloading, live updates, and failure recovery
RemoteSSH files, commands, binary previews, and execution identity
Agent Teamsspawn_teammate, member limits, and task-board workflow
SecurityWindows 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

References

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.