DSH plugin: format v4 requires a producer-owned source kind

format v4 message requires a producer-owned source kind means the DeepSeek Harness session format v4 rejected a message's source kind during admission — v4 requires the message source to declare a "producer-owned kind", but what it saw was still the v3-era generic kind: 'plugin' wrapper. Error X → do W: upgrade the plugin to a v4-compatible release, or change the source kind to the producer's own kind per the official note; if it cannot be changed, uninstall the incompatible plugin (source).

The key to this message is that it is not "the session file broke" — a message was blocked by the format check before it was ever written. A user hit this in the wild: a plugin-written message such as /carry threw this sentence directly after the session format moved to v4; the criterion lives in the dsh-session-format-v3-to-v4 admission assertion, which both the encode and decode paths call, so the message can neither be written nor read back (source). Below: what it means, how to fix it, and how it differs from "migration refused".

What the format v4 error means: why a plugin source kind is rejected

The v4 admission check rejects the generic kind: 'plugin' wrapper outright and accepts only a "kind named by the producer itself" — so a message an old plugin wrote the v3 way cannot even get in the door under v4 (source). Compare the shapes:

Read it in this order:

1. It is "admission failed", not "data corruption" — the check runs at the message's write or read entry, and the event is rejected before it lands in the log. Expected: the log may show no trace of this message.
2. It affects both the read and write paths — assertV4SourceRowAdmission / assertV4MessageSources are called on both the encode and decode sides, so it is not only "cannot write"; a message written the old way is also blocked when read back. Expected: after an upgrade or a shape correction, both read and write recover.
3. It is a whole-turn failure, not just this one message going invalid — when the message is appended before some step can run and then throws, the whole turn fails. Expected: once the source kind is fixed, that turn runs to completion.

Keep one sentence: v4 wants "whoever wrote it uses its own name"; the generic wrapper is retired.

Do not read this as a corrupt session file. A message blocked at admission was never appended, so the session on disk is untouched by this error; a genuinely corrupt session surfaces a different family of messages (seq gaps, format-version refusals). Reaching for a session-repair tool here is the wrong move — there is nothing that was written to repair.

4. The convention is namespaced on purpose — by requiring a producer-owned kind, v4 lets the reader tell an official checkpoint from a third-party plugin's marker without a central registry, so a message's origin is self-describing. Expected: a plugin that follows the convention reads its own older messages back correctly under v4.

How to fix format v4 message requires a producer-owned source kind: upgrade, uninstall, migrate

There are three main lines: upgrade the plugin to a v4-compatible fix release first; if you cannot upgrade, change the source kind back to the producer's own kind per the official note; if it is simply incompatible, uninstall it from the market and then handle the affected sessions through the migration flow. Run the steps in order:

1. Upgrade the plugin — update the plugin that throws to a v4-compatible version (dsh plugin --profile web add <package>@latest, or pull the latest from its source channel). Expected: run the same operation again and it no longer throws format v4 message requires a producer-owned source kind.
2. Change the source kind per the official note — if you hold the plugin source, change the message origin from the kind: 'plugin' wrapper to a producer-owned kind — third-party plugins conventionally use a plugin-name-prefixed form such as plugin:<plugin-name> (source). Expected: rerun after the change and the message passes v4 admission.
3. Uninstall the incompatible plugin — when no fix release exists and you cannot change the source, check the version and source in the DSH Plugin Hub installed list, then uninstall the incompatible one so it stops writing illegal shapes into sessions. Expected: the plugin no longer appears in the list and the related operations stop triggering the admission failure.
4. Handle the affected sessions — for sessions that already failed because of this message and will not open or accept new content, go through the official session migration flow (do not hand-edit files). Expected: the session reloads and later writes are no longer refused.
5. Regression-test — rerun the operation that originally threw (for example that plugin's command), then open the affected session to confirm it reads. Expected: only when both pass is the fix done.

Boundary: if your symptom is "after upgrading DeepSeek Harness, old sessions as a whole will not open and report refuses this format v0", that is a different problem — a migration-list issue — covered in the comparison below.

Why upgrading beats editing: a plugin that still writes the retired wrapper is usually not patched to the same release line as the host, so editing a single call site in a vendored copy produces a local fork that drifts again on the next host upgrade. Upgrading to a maintained release keeps the source-kind convention aligned with the host that enforces it; only fall back to editing when you own the plugin and no release exists.

How it differs from session format migration refusal

The only common ground is that both involve the session format; the mechanisms are completely different: this page is a v4 admission failure on the source kind, and the other is a migration allow-list missing an entry and refusing to read old data (source). Compare:

1. Opposite directions: this error is "the new format will not allow an old shape to be written", while migration refusal is "the reader does not recognise a shape it once wrote". Expected: judge by the error string first, then pick the handling.
2. Different cost of handling: this one usually just needs an upgrade or a plugin swap; migration refusal touches historical data and must be backed up first. Expected: when unsure of the mechanism, do not hand-edit session files.
3. Do not conflate them: the full background of migration refusal is in DSH plugin refuses this format v0 after an upgrade, and this page does not repeat it. Expected: each fixes its own, without covering the other.

One more pair worth separating: a v4 admission failure is about the shape of a message source, while a schema or validation error from a tool call is about the arguments a plugin passes. Both can appear in the same failed turn, so read the string: this one names source kind, the other names a parameter. Fixing an argument schema will not unblock a source kind message, and vice versa.

Troubleshooting notes for a DSH plugin session write

1. Read the error string first — v4 source-kind admission and migration refusal are two different things, so choose the handling by the string.
2. Do not hand-edit session files — the format and the origin shape are interrelated, and one wrong edit turns a repairable problem into real corruption.
3. Prefer upgrading the plugin — if a v4-compatible release exists, do not go editing the source.
4. Uninstalling is the steadiest fallback — remove the incompatible plugin first, then talk about migrating historical sessions.
5. Regression-test in two steps — rerun the original operation and open the affected session, and both must pass to call it fixed.

The official DSH plugin convention for message source kind

The official convention in one sentence: after v4, a message origin must be named by the producer itself and the generic wrapper is retired; the same release also changed how session events are accessed, so plugins need to adapt. Two points:

1. A producer-owned kind is a hard requirement — v4 admission rejects kind: 'plugin'; the official checkpoint uses the official type and third-party plugins use a plugin-name-prefixed form, and both generations read the same kind back (source). Expected: a plugin author adapts once to this convention and stays compatible for a long time.
2. The same release carries other breaking changes — they drift with the host upgrade, so after upgrading dsh, run the plugin's offline smoke test / self-check before pushing to production (source). Expected: treating "self-check after upgrade" as a fixed move surfaces this kind of admission problem early.

Rather than hunting down a patch for a plugin that is not v4-compatible, cross-check versions in the DSH Plugin Hub installed list first and remove the incompatible one, then come back. Its home page is https://dsh-plugin.org/.

Sources: deepseek-ai/deepseek-harness (official repo), community plugin dsh-tui-compact-carry, Web UI guide (official docs).