DeepSeek shipped v0.2.1-alpha.1 of its open-source agent harness (dsh) on October 3, and one line in the release notes deserves more attention than the rest: an experimental Claude Code Mods compatibility layer. Not a port. Not "Mods support". A compatibility layer whose stated purpose is to verify that the Claude Code Mods API is roughly a subset of dsh plugins. That framing tells you a lot about where agent config formats are heading, so I read the release closely and ran the numbers on what actually shipped.
What shipped, exactly
The release landed October 3 at 06:42 UTC on GitHub, with the npm package @deepseek-ai/dsh published about two hours earlier. The dist-tags tell the story of its maturity: latest points at 0.2.0-rc.2 from September 29, while the Mods layer only exists on the alpha tag. This is not the build you install for daily work.
# the Mods compat layer is alpha-only as of Oct 3
npm view @deepseek-ai/dsh dist-tags
# alpha: 0.2.1-alpha.1, latest: 0.2.0-rc.2
npm install -g @deepseek-ai/dsh@alpha
The surrounding release is otherwise about the plugin system itself: a "let the agent create a plugin" entry on the plugin management page, a developer tools bundle with raw session logs, and fixes for dependency mapping when bundles start and stop. DeepSeek describes the whole harness as MIT-licensed and developer-preview quality, with breaking changes expected between builds. It runs non-DeepSeek models through OpenAI-compatible endpoints, which matters for the portability question below.
What the compat layer actually claims
The release note (originally in Chinese, credit to @tianyicui) says the layer's main purpose at this stage is to verify that Claude Code Mods API functionality is roughly a subset of DeepSeek Harness plugins, rather than to give users actual full compatibility. That is an unusually honest sentence, and it's worth unpacking.
A subset test runs in one direction. DeepSeek is asking: can everything a Mod does be expressed as a dsh plugin? If yes, then dsh's plugin surface covers Mods, and mapping a Mod onto a plugin becomes a translation problem instead of a redesign. If no, the gaps tell you exactly which parts of the Mods API are Anthropic-specific. Either answer is useful, and neither is a promise that your Mod will run today.
Compare that with how OpenAI handled the same problem. When Codex plugins shipped, the config surface moved out of the repo and into a new format, and when MCP Extensions landed in ChatGPT's sidebar, the portability bill came due for anything locked to one vendor's plugin schema. I wrote about both (Codex plugins, MCP Extensions). DeepSeek is trying a third route: adopt the incumbent's API shape as a compatibility target before writing its own from scratch.
Why "subset" is the load-bearing word
Claude Code Mods are in-process hooks. They intercept and reshape what the agent does, at points like shell command construction and file access, running inside the same process as the agent loop. We covered the mechanics when Mods shipped in 2.1.287 (details here), and later watched a 7-line Mod override a deny rule (that audit).
In-process hooks are a high bar for a plugin system. If dsh plugins can express them, then dsh plugins are not just tools and commands, they're policy. That's what makes the subset question non-trivial, and it's why I'd trust DeepSeek's careful phrasing over any blog post claiming "Mods now run everywhere".
A 15-minute test you can run
If you maintain Mods or dsh plugins, the alpha gives you a cheap experiment. Take your simplest Mod, the one that only rewrites a command or logs a hook event, and try it under dsh. You're not testing whether it works. You're testing where the translation fails:
- Install the alpha (pinned, in a container or disposable profile, since it's a developer preview).
- Load one Mod with a single hook surface, nothing that touches permissions.
- Note which hook events fire and which silently don't exist.
- Check the developer tools bundle's raw session logs to see what the compat layer did with your hook.
The failure list is the deliverable. It's a map of the Mods API surface that assumes Anthropic's runtime, which is exactly the part worth knowing before you build anything that targets both.
Where I expect it to break
Permission coupling is the obvious fault line. A Mod that overrides deny rules encodes Claude Code's permission model; dsh has its own, including sandbox scripts on Windows and per-tool approval behavior. Hook timing is another: in-process hooks win races that message-passing plugins lose, and a compat layer that marshals across a boundary will show it as latency or missed events. UI surfaces are a third: Mods that draw views depend on the host app's rendering, and the dsh desktop and web UIs are not that.
None of these are reasons to skip the test. They're the reasons the release note says "verify" and not "support".
What this means for your config files
Three vendors now ship agent extension formats, and only one of them is being subset-tested against another. Your rules files, the markdown ones, remain the portable layer: every harness I've used reads instruction files, and none of them cares about the others' plugin schema. That's the boring bet. Keep policy in plain files, keep hooks thin, and pin versions of everything, which is the same discipline we package in AgentConfig Studio ($29) and teach in Verify First (€19). If subset testing becomes the norm, your plugin inventory shrinks to the intersection, and your instruction files carry the rest.
The next signal to watch is whether the compat layer survives to 0.2.1 stable, or quietly narrows to "the parts that translated cleanly". Either way, the repo's release notes are now on my weekly read list, next to the Codex and Claude Code changelogs.
Top comments (0)