Superseded release note: This page is retained as a historical guide to the 0.1.2 line. As of September 11, 2026, the latest upstream pre-release is 0.1.5 RC2. Read the DeepSeek Harness 0.1.5 release and upgrade guide for the current changes and Session V3 migration checks.
DeepSeek Harness 0.1.2 RC1 consolidates the project's recent work on Agent Client Protocol (ACP), configurable Codex and Claude Code subagents, long-session reliability, Windows support, and developer tooling. It also carries migration-sensitive changes to launch Profiles, Remote calls, Session event APIs, PTC naming, WebFetch defaults, and Session storage.
The release covered here is dsh-v0.1.2-rc.1, published on September 3, 2026. GitHub marks it as a Pre-release. DeepSeek's own safety notice says the project has not undergone a security audit and that sandboxing, approvals, and permissions do not guarantee isolation.
That makes RC1 a clearer integration candidate than the earlier Alpha tags, but not a version to adopt automatically in a production or sensitive environment.
Historical release facts verified: September 4, 2026; supersession checked: September 11, 2026. This article tracks the upstream DeepSeek Harness release. Agent.Space availability and version support must be checked separately.
The 0.1.2 release line in one minute
DeepSeek published four 0.1.2 Alpha tags over six days:
RC1 consolidates that Alpha work into the first 0.1.2 release candidate. The timeline still matters because it shows which migration surfaces changed before the candidate was cut.
For the durable explanation of the project, its plugin architecture, and how to evaluate it, use the DeepSeek Harness guide. This article focuses on the 0.1.2 RC1 release and the Alpha changes it consolidates.
What RC1 consolidates
RC1 is easier to evaluate as four workstreams rather than one long changelog.
Subagent routing became more configurable
RC1 lets an agent select a provider, model, and reasoning effort for a subagent within configured authorization. A caller can also specify those fields and a maximum output length when starting a subagent. Codex and Claude Code subagents gained support for configured models.
This can make delegation more deliberate: a parent can reserve a more capable or expensive model for one bounded job, use a different model for exploration, or cap the output of a child task. It also creates more configuration to review, because the selected subagent backend, provider, model, reasoning setting, and permissions are separate controls.
RC1 also includes two-way follow-up messages between a parent and a continuable child agent through send_message, replacing the earlier one-way report tool. That makes an ongoing delegated task easier to refine, but it also means an integration that depends on report must migrate and test the longer-lived message flow.
ACP covered more of the session control surface
Alpha.1 says its ACP implementation completed support for standard session controls, model settings, MCP, permissions, and cancellation. That is more meaningful than merely opening an ACP connection: a client needs those controls to operate and present a useful agent session.
Connection and long-session behavior kept changing
Alpha.2 added visible connection-failure status, automatic retries, and an immediate reconnect action. It also improved Agent Preset switching and search, long-session processing, and token and elapsed-time details. Its Node.js fix was narrower than general Node 24 compatibility: the release specifically covers startup/HMR on Node.js 24.0 through 24.11.1.
Alpha.3 reduced memory use in long conversations and improved syntax-highlighting responsiveness. It also fixed image delivery for messages added or queued during a running conversation, including follow-up messages to continuable subagents. Alpha.4 continued the long-conversation work across streaming responses, layout, and navigation previews, and added search and filtering to the model catalog.
Migration surfaces changed between tags
Alpha.1 removed the old ApiProxy interface in favor of @Remote, moved application launch paths—including Python SDK and ACP modes—behind dsh Profiles, and renamed Code Mode to PTC mode while preserving readability of existing conversations. Alpha.2 restored SessionEvent.ignorable, which alpha.1 had removed. Alpha.3 removed an optional storage backend. Alpha.4 replaced direct Session.events reads with seq, eventAt(), and snapshotEvents(), and separated SessionSeq from SessionLogOffset at the type level.
Those are not cosmetic release-note details. They can affect integrations, launch scripts, plugins, event consumers, and access to stored Session data.
Configurable Codex and Claude Code subagents
“Codex subagent” and “Claude Code subagent” describe Agent harness backends, not models. A model is the inference engine selected through a provider. The harness supplies the agent loop, tools, session behavior, and integration surface around that model.
The 0.1.2 RC1 controls therefore sit on multiple layers:
DeepSeek's release wording matters: model selection happens within configured authorization. The new option is not evidence that every provider/model pair works, that every caller may choose any model, or that a child inherits a safe permission boundary automatically.
Before enabling model-selectable subagents, define which backends may run, which provider/model combinations are allowed, how credentials reach the child, what output limit is appropriate, and which files, commands, network destinations, or plugins the child can access. Then test a permitted request and a denied request separately.
If team members still use “Codex” or “DeepSeek” to mean both a harness and a model, the agent harness versus model guide provides a cleaner vocabulary for the configuration review.
What “completed ACP support” means
ACP is the communication layer between a user-facing client and a coding agent. It is not a model, subagent implementation, or permission policy. It also does not replace MCP: ACP connects the client to the agent, while MCP connects an AI application or agent to external tools and context.
In RC1, DeepSeek lists five completed ACP areas:
- standard session controls;
- model settings;
- MCP configuration or exposure through the session;
- permissions;
- cancellation.
Together, these features let an ACP client do more than start the process. The client can manage a session, surface model choices, coordinate configured MCP access, present permission decisions, and stop active work through the protocol boundary.
The release also says applications now launch through dsh Profiles, including ACP mode and the Python SDK. If an existing integration called a previous ACP-specific launch path directly, treat the Profile change as a migration task rather than assuming the old command still maps cleanly.
For the protocol roles, lifecycle, and limits behind those terms, read what Agent Client Protocol is. “Completed support” in one release note still does not prove feature parity with every ACP client or production readiness for a particular deployment.
Configuration and migration checks
Review these surfaces before moving an existing setup to 0.1.2 RC1.
1. Remote calls
Alpha.1 completed the migration away from the legacy ApiProxy interface and removed it. Integrations should use the @Remote gateway. Search application code, plugins, and internal examples for ApiProxy; do not rely on a compatibility fallback that the release says has been removed.
2. Launch profiles
Applications now launch through dsh Profiles, including Python SDK and ACP modes. Capture the current launch command, environment, Agent Preset directory, model/provider configuration, and plugin set before changing it. Rebuild the same intent as an explicit Profile, then verify it in a disposable environment.
3. Mode names and event consumers
Code Mode was renamed PTC mode, while existing conversation records remain readable. That should preserve old records, but scripts, documentation, dashboards, or tests that match the old label may still need updates.
Alpha.2 restored SessionEvent.ignorable after alpha.1 removed it. Alpha.4 then replaced direct Session.events access with on-demand read APIs and split Session sequence values from log offsets into distinct types. If a plugin or SDK consumer reads events, test against the exact tag you plan to pin rather than treating “0.1.2 Alpha” as one fixed API.
4. Session storage
Alpha.3 removed the optional SQLite Session persistence backend. The release says existing content is not deleted, but instructs users to use an older version to export it. If that backend holds data you need, export and verify the export before making alpha.3 or a later tag your only runnable version. Keep the older environment available until recovery is proven.
5. Request metadata and Session logs
RC1 says the official DeepSeek adapter includes package names and versions for enabled plugins in official DeepSeek requests by default, with a configuration option to disable that behavior. It also adds optional incremental Session-log uploads, which are off by default.
Review both settings as data-governance decisions. Inventory plugin identifiers, inspect the destination and retention expectations, leave Session-log uploads disabled unless there is an approved reason to enable them, and do not assume “off by default” will remain unchanged in later prereleases.
6. Network access
RC1 enables public WebFetch by default with SSRF protections and without per-request approval for public network access. Alpha.4 says web_fetch is now provided by default to the Python SDK, Headless, ACP, and custom Profiles, while Web PTC mode no longer receives the general-purpose workflow tool by default. These defaults affect what each execution surface can call. SSRF protection addresses one class of server-side request forgery; it does not turn arbitrary fetched content into trusted input. Recheck egress policy, sensitive network reachability, prompt-injection exposure, and the permissions surrounding downstream actions.
The security boundary has not changed
The official DeepSeek Harness Safety Notice is explicit: the project is experimental developer-preview software, has not undergone a security audit, and must not be treated as secure or production-ready.
DeepSeek Harness can execute model-generated code and commands, load third-party plugins, and access the network, processes, credentials, and files exposed to it. Sandboxing, approval prompts, and permission controls reduce risk but do not guarantee isolation.
The official guidance recommends least privilege, a disposable virtual machine or container, backups, limited exposure of credentials and data, and review of plugins, configuration, and proposed commands. The new ACP permission surface or configurable subagent authorization does not replace those controls.
Should you upgrade now?
Use the release state and your dependency on existing data to decide.
A good RC evaluation has a rollback path, a version pin, a small test workspace, no sensitive credentials, representative permission checks, and a saved copy of any Session data that matters.
What this does—and does not—mean for Agent.Space
This article describes the upstream DeepSeek Harness 0.1.2 RC1 release. It does not announce that Agent.Space has adopted RC1, changed its DeepSeek Harness version, or enabled the upstream ACP, Codex subagent, Claude Code subagent, Profile, Remote, or storage behavior described here.
Upstream availability and hosted-product availability are separate facts. Use DeepSeek's tagged release notes for the upstream project, and use Agent.Space's current product interface and product materials for the behavior offered in Agent.Space.
If you want to evaluate a currently available execution option, open Agent.Space, choose an option shown in the product, confirm the model and provider separately, and start with a bounded task whose permissions and output you can inspect.