Cordis: The Plugin Kernel Under DeepSeek Harness That Makes Uninstall Actually Undo
DeepSeek's new paper with Peking University formalizes revertible effects and reactive coeffects, and argues that on most plugin systems, including the best-engineered ones, uninstalling an extension does not actually remove it until you restart the host.
Uninstalling a plugin almost never uninstalls the plugin. It marks it disabled, tells you to restart, and the listeners it registered, the caches it warmed, and the globals it patched sit there until the process dies. Everyone who has shipped a plugin system knows this and has decided it is acceptable, because the cost is a restart and a restart is cheap.
That accounting breaks the moment the host process is an agent. An agent holds session state, warm connections, an accumulated context you paid for token by token. If installing a tool means restarting, and the agent is the thing installing the tool, you have built a system that erases its own working memory every time it improves itself.
DeepSeek Harness has been the loudest repository on GitHub this week, and the pitch everyone repeated was "everything is a plugin." That is the least interesting thing about it. The interesting thing is one line in the README, which says the harness is powered by Cordis, and links to a paper explaining why the plugins can be pulled back out.
The claim, and the number behind it
The paper is titled A Programming Paradigm for Spatiotemporal Composability, drafted August 13, 2026, and it splits the problem in two.
Temporal composability is the ability to completely revert a component's side effects when you remove it. Spatial composability is the ability to declare dependencies between components and have the runtime react when they appear or disappear. Most plugin systems get partial credit on the second and fail the first outright.
To show that failing the first is normal rather than exceptional, the paper reaches for the most respectable example available: VS Code, which runs one of the better-engineered extension systems in wide use, still cannot unload an extension containing code without restarting the extension host. Summaries of the paper circulating this week put a number on it, reporting an audit as of June 9, 2026 in which 87 of the top 100 Marketplace extensions carried executable code that could not be individually removed at runtime once activated.
Treat that 87 as reported rather than verified. I could not confirm it inside the paper's own text, and an earlier structured summary of a July draft describes the VS Code problem only qualitatively, with no audit and no figure. The qualitative claim is solid and appears in every version. The specific count may belong to a draft I have not read, or to a summarizer's paraphrase. The paper is a preprint whose repository warns in plain language that the content may change substantially between revisions.
How the mechanism works
Cordis lifts two ideas out of type theory and makes them runtime behavior instead of compile-time checks.
Revertible effects handle time. Every transformation a plugin applies to the context has to carry its inverse, and the runtime tracks it. Load a plugin, and each modification pushes an undo function onto a chain. Unload it, and the chain runs backward, restoring the state that existed before the plugin arrived. The stack discipline is the whole trick: last effect applied, first effect reversed.
Reactive coeffects handle space. A component declares which services it needs. Until those services exist, it stays inactive rather than booting and crashing on a null reference. When a provider appears, dependents activate on their own. When a provider goes away, dependents pause and retract their own effects first, then the provider finishes unloading. The ordering is inferred from the declarations, not hand-written by whoever last touched the boot sequence.
The primer bundled with DeepSeek Harness shows what this looks like in code, and it is plainer than the theory suggests. A plugin is an object implementing a Service. A context is a repository of services, so a plugin finds ctx.tools or ctx.llm or ctx.sessions by key rather than importing a concrete implementation. Dependencies get declared through an inject field, so load order falls out of what each plugin requires. Communication runs over typed events with four dispatch modes, emit, waterfall, parallel, and serial, and the mode is part of the event's public contract rather than an implementation detail.
The rule that carries all the weight is the last one: registrations go in through ctx.effect() or ctx.on(), which is what makes teardown unwind predictably. Prompt sections, tool schemas, model adapters, listeners, all of it installs through a channel that knows how to remove it.
The four years nobody noticed
Here is the part that separates this from a launch-week framework.
Cordis has been running in production since well before anyone applied it to agents. The paper validates it on Koishi, a cross-platform chatbot framework built on Cordis, with more than 4,000 community plugins accumulated over four years across messaging adapters, database drivers, admin consoles, and user features. Those plugins were written independently by authors who never coordinated with each other. The only thing holding the composition together was the effect discipline.
The author lineup explains the continuity. The paper carries three names across Peking University and DeepSeek: Yifan Shi, Wei Zhang, and Tianyi Cui. A Quantum Bit writeup fills in who they are. Shi is at Peking University and also a DeepSeek member whose name appears in the DeepSeek V3 technical report, and he created Koishi. Zhang is an associate professor at the Software Institute of Peking University's School of Computer Science. Cui is on DeepSeek's harness team. So the kernel under the agent harness is the same kernel its author has been refining inside a chatbot framework since 2022, now with a formal treatment attached.
That reframes what DeepSeek shipped. The harness is a day old. The composition model underneath it has four years of adversarial testing by strangers writing plugins that had to coexist without ever talking to each other.
Putting it into practice
The lowest-friction way in is to run the thing and read one file.
npx @deepseek-ai/dsh web
That starts the web UI on 127.0.0.1:3080. Node is the only prerequisite. Then read docs/cordis-primer.md, which is short and covers the five ideas you need before writing anything.
The test worth running, whatever harness you are actually committed to, is the reload test, and almost nobody runs it. Mount a plugin. Let it register a tool, a prompt section, and an event listener. Unmount it. Then check three things: is the tool gone from the schema you send the model, is the prompt section gone from the assembled context, and is the listener still firing. In most systems the third one is still firing, and you will find that out in production when a removed plugin keeps intercepting calls.
If you are writing Cordis plugins, the discipline is short. Every registration returns a disposer, either from ctx.effect() or from a helper that handles it for you. When teardown order matters, keep the related work inside a single effect so disposal unwinds in the sequence you intended. Put tool pipeline behavior on ctx.tools, model streaming on ctx.llm, agent coordination on ctx.agents. Use events for interception and policy, service methods for direct calls.
And if you publish something, tag the repository with the dsh-plugin topic, which is how the ecosystem is being assembled.
What this does not solve
The guarantee is only as good as the plugin authors. The runtime reverses inverses you gave it. A plugin that registers a listener outside ctx.effect(), patches a global directly, or spawns a timer it never disposes breaks reversibility, and nothing in the paper or the framework forces compliance. Cordis makes correct teardown expressible and conventional. It cannot make it mandatory. In an ecosystem of 4,000 independently written plugins, "conventional" is doing enormous work, and the failure mode is a single sloppy plugin poisoning a reload that looked clean.
The paper says its own limits out loud, which I respect. Validation is confined to one ecosystem, Koishi, and one language, TypeScript, with no controlled comparison against alternative architectures. Nobody has demonstrated that this design beats a well-built conventional plugin system on any measured axis. It demonstrates that the design works at scale, which is a different and weaker claim.
DeepSeek Harness itself is a developer preview, and the README says in capital letters that there will be compatibility-breaking changes. Cordis is vendored into the harness rather than pulled as a live dependency, with the source and sync procedure kept under vendor/. That cuts both ways. You are insulated from upstream churn, and you are also running a snapshot that may drift from whatever upstream Cordis looks like when you go read its docs.
One caveat on popularity figures, since they are the first thing everyone quotes. GitHub served me wildly different numbers for these repositories across fetches inside a single session, including a cached page claiming under 10,000 stars for a repository whose live page showed 85,300 minutes later. Published figures for the harness's first day range from 22,000 to over 90,000 depending on which snapshot the writer caught. So distrust every star count you read this week, mine included. The structural facts are the ones that hold: MIT license, a small maintainer group, and an API that Cordis's own documentation describes as not yet stable and subject to change without notice.
What to do with this
Reversible teardown is not a feature you will notice until you need it, and you will need it the first time an agent tries to modify its own tooling mid-session. That capability is coming to every harness, not just this one, and the systems that get there will be the ones that solved uninstall before they solved self-modification.
So run the reload test against whatever you are running now. If a removed plugin's listener still fires, you have found the ceiling on how far you can let your agent edit itself, and you found it in a test instead of in an incident.
The paper is worth an hour even if you never touch DeepSeek Harness. It is the clearest statement I have read of a problem the agent tooling world has been walking past for two years.
Sources: cordiverse/paper, A Programming Paradigm for Spatiotemporal Composability; cordiverse/cordis; deepseek-ai/deepseek-harness README; Cordis primer in the harness docs; Quantum Bit summary of the paper, via MarsBit.