Fix DeepSeek Harness messages transport failed: DSH plugin

DeepSeek Messages transport failed (code: TRANSPORT) is not a verdict that "the network is broken" but DeepSeek Harness's transport-layer fallback label: it is thrown by the catch-all in packages/llm/llm-deepseek/src/adapter.ts — any escaping error that is neither a LlmError nor an idle timeout or explicit cancellation is wrapped as TRANSPORT (source). So the first move is not to switch networks, but to determine "was this request actually sent," then read the real error in the cause. To check what plugins your environment changed recently, look at the installed list in the DSH Plugin Hub. If transport failed is tangled with a stream cut or a half packet, use the five-minute triage for transport failed and stream breaks.

Which DeepSeek Harness layer this error comes from: transport fallback, not model inference failure

This catch in the source splits four ways, and only the "none of the above" case is called TRANSPORT (source):

1. Idle watchdog timeout → reports TIMEOUT, with the message DeepSeek Messages stream idle timeout;
2. Request explicitly cancelled (signal already aborted) → reports ABORTED, with the message DeepSeek Messages request aborted;
3. Already a LlmError → rethrown as-is, keeping its own code;
4. Everything else → wrapped as TRANSPORT, which is exactly the line you see.

Two useful conclusions follow from these four branches:

1. A genuine model / API business error never becomes this line. Authentication failures, invalid parameters, and insufficient quota are themselves LlmError, taking branch 3 and appearing with their own code. So seeing TRANSPORT means the failure happened around request preparation, connection setup, or streaming, not a business rejection from the model side.
2. The real reason is not lost — it is in the cause. The throw keeps the original object as { cause: error }: the outer line is the label, the inner one is the identity.

A quick map of DeepSeek Harness transport-class errors: four categories, match yours first

Before opening logs, sort the failure into one of four categories — each points at a different next step (source):

Use this table as a first filter: only the last row is the fallback label this page is about, and only the last row's decision depends on what cause says.

Before diving into logs: two commands to confirm "the machine can get out"

Rule out the environment first, then open the session log (source). Run these two in the same shell the host uses:

env | grep -i -E 'https?_proxy|no_proxy'
# should show whether a proxy is configured and what it is

curl -sS -o /dev/null -w 'HTTP %{http_code}  connect %{time_connect}s  total %{time_total}s\n' https://api.deepseek.com/v1/models
# should print an HTTP status and timings, not a connection error

Expected: the first command tells you whether an https_proxy / no_proxy pair is in play at all — a proxy that is set but wrong can itself produce this line, and a no_proxy that omits the endpoint will route model traffic through it. The second command separates "the machine cannot reach the endpoint" (a connection error, or an HTTP status far from 200) from "the machine can connect but this particular request failed." Only when both look healthy do you move on to the session-log cause, because if the endpoint is simply unreachable, every request will keep failing and no amount of per-turn digging will help.

DeepSeek Harness troubleshooting by layer: from the network to the cause in the session log

Recommended order: first check whether the request was sent, then the endpoint's return code, and finally the real error in the session log. Check layer by layer:

1. Network and proxy: whether the model endpoint is directly reachable, and whether a proxy re-signs HTTPS. If there is antivirus or a corporate proxy, read antivirus TLS cert chain errors first — that kind of failure also lands on the same line.
2. Was this request sent at all: this is the highest-information test. An HTTP request count of 0 with a failure in the tens of milliseconds means the error happened in local preparation; only if the request was sent and then cut off mid-stream is it a connection-layer issue.
3. The return code of the most recent request at the endpoint: 200 means it connected and the problem is in streaming or locally; 401 / 429 are LlmError and should not show as this line — if they do, the request was probably blocked before reaching the application layer. See the official docs for configuring the model endpoint.
4. The real error for that turn in the session log: open the reason and error object recorded in turn/end, expand the cause, and see what the code inside really is — a missing attachment writes ATTACHMENT_NOT_FOUND, not TRANSPORT.
5. Retry and resume: TRANSPORT is in the default retryable set and retries several times along a backoff chain, and only after exhaustion does the turn fail; the number of llm/retry entries in the log is the trace of how many retries happened (#7834). The session itself does not vanish because this turn failed, so locate the real cause, fix it, and rerun the turn.

A common pitfall: seeing TRANSPORT and retrying over and over. If the underlying cause is a deterministic error like "a local file does not exist," retrying is pure latency — once restored to its original code, it should not be in the retryable set at all.

Separating it from lookalike DeepSeek Harness errors, and preventing recurrence

The same DeepSeek Messages transport failed line has at least two causes, and the test is "was the request sent."

It also differs from two other error classes:

1. Model connectivity config (model connection troubleshooting): that is an endpoint, key, or outbound allowlist problem, usually reporting authentication or connection errors rather than this fallback label;
2. Frontend-to-host connection (Web UI connection errors): that is a channel problem between the browser and DeepSeek Harness, a different link from the model request's transport layer.

A few practical habits to prevent recurrence:

1. Let streaming requests finish: do not switch networks, switch proxies, or sleep mid-generation;
2. Allow the proxy and antivirus through: add the model endpoint to the allowlist so HTTPS is not re-signed in the middle;
3. Do not hand-delete attachment objects: attachments use content-addressed storage, so once deleted with no backup they cannot be rebuilt, and sessions referencing them keep failing;
4. Keep environment changes traceable: manage plugin additions, removals, and version updates in one place, and when troubleshooting first ask "what changed recently" — the installed list and system logs in the DSH Plugin Hub let you cross-check.

Common misconceptions about the DeepSeek Harness messages transport failed error

Five beliefs that turn one fallback label into several wrong fixes:

1. Assuming it always means the network is down: it is a catch-all fallback label, so a local preparation failure such as a deleted attachment lands on the very same line.
2. Treating all four codes as one thing: TIMEOUT, ABORTED, a rethrown LlmError, and TRANSPORT are four branches in the source, and only the last is the fallback.
3. Reading the outer line as the real error: the identity is in cause; the visible line is only a label, so without opening cause you cannot name the fault.
4. Retrying a deterministic failure: if the inner cause is "a local file does not exist," backoff retries add latency without ever succeeding.
5. Fixing the code but never the environment: a proxy that is set but wrong, or an endpoint that is simply unreachable, will keep every request failing until the environment itself is corrected.

Notes on the DeepSeek Harness messages transport failed error

In one line: it is a "could not classify" label, and the check order is "was the request sent → endpoint return code → the real code in cause."

1. Do not blame the network first: this line is thrown by the catch-all, and business errors never become it;
2. Check the request count first: 0 requests = local preparation, requests present = connection or streaming;
3. Always open the cause: the real error code is in there all along, just not rendered outward;
4. Distinguish TIMEOUT from ABORTED: idle timeout and explicit cancellation have their own classifications, so do not treat them all as transport failure;
5. Judge whether retrying is worth it: retries are meaningless for deterministic errors, so locate before rerunning;
6. Same string, different causes: missing attachments and TLS re-signing both land on this line, so split by "was the request sent";
7. Check adjacent errors separately: connectivity config in model connection troubleshooting, frontend channel in Web UI connection errors.

Sources: DeepSeek Harness source - llm-deepseek/src/adapter.ts, DeepSeek Harness Docs - Configure model providers, #7834.