[desktop] All model requests fail in the Electron desktop app (TRANSPORT) while dsh headless and the web UI succeed with the identical profile, credentials, model and network

[redwingsx62-sys]

✅ RESOLVED — see the follow-up comment below. The cause was a plugin
fetch monkey-patch recursion, not the Electron shell. The original
report's central conclusion is corrected there.

---

TL;DR — On Windows 10, DSH Desktop 0.2.0-rc.2 fails every model request (DeepSeek Messages transport failed / TRANSPORT, retries 5/5, 15–17 s per turn), across all providers (deepseek-official, deepseek, opencode-go).

Same machine, same moment, same ~/.dsh profile, credentials, model and network:

• dsh headless (desktop profile) → succeeds (2.9 s)
• Web UI (http://127.0.0.1:3080) → succeeds
• Desktop app (Electron) → fails every time

So the engine, provider registration, credentials, network stack and endpoint are all fine. The failure lives only in the Electron desktop shell.

It started abruptly on 2026-10-10 07:50 (UTC+8) after a scheduled reboot, with no local config change. It is not #9262 (that fails locally in 13–15 ms), not #8947 (~300 s bodyTimeout), not #8837 (boot/resume crashes). I could not find an existing report matching this.

The report also documents 6 additional defects found while isolating this one — most notably that the desktop app writes no logs at all, and that the model picker shows two provider groups both labelled "DeepSeek", so users cannot tell the account route from the API-key route.

Full environment, 12 ruled-out hypotheses with measured evidence, minimal repro and probe scripts below.

---

[desktop] All model requests fail in the Electron desktop app (TRANSPORT) while dsh headless and the web UI succeed with the identical profile, credentials, model and network

1. Summary
   On the same machine, at the same moment, with the identical profile config, credentials, model, reasoning effort and network:
   dsh headless (desktop profile) → succeeds (2.9 s)
   Web UI (http://127.0.0.1:3080, same ~/.dsh) → succeeds
   Desktop app (Electron) → fails every time — TRANSPORT, retries 5/5, 15–17 s per turn
   The DSH engine, provider registration, credential resolution, network stack, model and endpoint are all fine. The failure exists only in the Electron desktop shell.
2. Environment
   OS: Windows 10 Pro (WIN-B045A165KFF, WORKGROUP, not domain-joined)
   DSH Desktop: 0.2.0-rc.2 (%LOCALAPPDATA%\Programs\DeepSeek Harness)
   Electron: 44.0.0
   Bundled Node: 24.18.1
   DSH_HOME: C:\Users\Administrator\.dsh
   Profile: desktop
   Update channel: nightly (resources/app-update.yml → https://download.deepseek.com/dsh-desk/feeds/win-x64/)
   Latest on that channel: 0.2.0-rc.2 (nightly.yml, releaseDate 2026-09-29T10:35:27Z) — no update available
   Third-party plugins in the profile: @michengai/dsh-automation, @michengai/dsh-im-connect, dsh-auto-memory, dsh-cost-meter, dsh-opencode-session-header, dsh-tavern, dsh-whale-galgame, dshmarket (+ bundles)
3. Symptom
   3.1 Two different error strings, one code
   deepseek-official — adapter dsh-llm-deepseek (native) — UI text DeepSeek Messages transport failed — code TRANSPORT
deepseek — adapter dsh-llm-pi-ai (OpenAI SDK) — UI text Connection error. — code TRANSPORT
opencode-go — adapter dsh-llm-pi-ai — UI text Connection error. — code TRANSPORT
   3.2 Consistent failure signature
   Retries exhausted at 5/5, total per turn 15–17 s (matches the default backoff 500+1000+2000+4000 ≈ 7.5 s)
   Retry delays observed: 7581 ms, 8056 ms, 8167 ms, 8088 ms, 7508 ms
   Only a full restart of the app allows a retry — once a session fails, it keeps failing
   3.3 Onset
   2026-10-10 07:50 (UTC+8) onwards. Up to that point everything worked ("login fine, model fine, streaming with no errors"). The machine boots on schedule (BIOS RTC) at 07:40; the first scheduled tasks at 07:50 failed. No local configuration change was made.
4. Minimal reproduction
   A) headless — SUCCEEDS

$exe = "$env:LOCALAPPDATA\Programs\DeepSeek Harness\DeepSeek Harness.exe"
$cli = "$env:LOCALAPPDATA\Programs\DeepSeek Harness\resources\app.asar\dsh\node_modules\@deepseek-ai\dsh-desktop-host\lib\cli.js"

$env:ELECTRON_RUN_AS_NODE = '1'
$env:DSH_HOME    = 'C:\Users\Administrator\.dsh'
$env:DSH_PROFILE = 'desktop'

& $exe "--expose-internals" $cli headless "Reply with exactly: OK"
# Actual: exit=0, 2.9 s, stdout="收到"

B) Desktop app — FAILS
Launch DeepSeek Harness.exe
New session → select DeepSeek-V4-Pro (reasoning: Off) → send test
Actual: 本轮运行失败 DeepSeek Messages transport failed [TRANSPORT], retries 5/5, ~16 s
Both read the same ~/.dsh/profiles/desktop/cordis.patch.yml:

- id: agent-default-model
  name: "@deepseek-ai/dsh-agent-default-model"
  config:
    provider: deepseek-official
    model: deepseek-v4-pro
    reasoningEffort: off

5. Everything ruled out (each with measured evidence)
   Invalid model name — deepseek-flash / deepseek-v4-pro return HTTP 200 on all three endpoint shapes. (Note: the literal id deepseek-v4.1-flash is rejected with 400 — see Bug B.)
   Multi-turn conversation — two-turn conversations tested in both OpenAI and Anthropic formats, all HTTP 200.
   Tool calls — full tool_calls + tool result two-turn chain, HTTP 200.
   Thinking-block replay (Anthropic thinking+signature) — replayed verbatim / thinking dropped / signature blanked: all three HTTP 200.
   Thinking mode itself — desktop still fails with reasoning: Off.
   System proxy / TUN / proxy env vars — ProxyEnable=0; no TUN adapter; default route normal; HTTP_PROXY/HTTPS_PROXY/ALL_PROXY/NO_PROXY unset in all three .NET scopes; ~/.dsh/.env does not exist; Clash Verge enable_tun_mode: false, enable_system_proxy: false.
   Local HTTPS MITM (AV / enterprise proxy) — disabled the machine's Aliyun SASE agent (service Stopped, driver Stopped, zero processes): problem persisted. Node TLS handshake to api.deepseek.com / platform.deepseek.com / harness.deepseek.com: authorized=true, real TrustAsia / DigiCert chains.
   Windows Firewall — no DSH-related rules; no outbound Block rules; all three profiles default-allow outbound.
   Endpoint unreachable — api.deepseek.com HTTP 200 (841 ms); platform.deepseek.com endpoints 200/405; opencode.ai/zen/go/v1 200.
   Bad credentials — DEEPSEEK_API_KEY in ~/.dsh/.credentials.yaml verified working.
   Polluted host-process environment — read the environment of the live DSH host process (PID 23664) directly: no proxy vars, no NODE_EXTRA_CA_CERTS, no SSL_CERT_FILE, no DEEPSEEK_BASE_URL.
   Broken desktop composition config — the identical profile works under dsh headless and the web UI.
6. Additional defects found along the way (independently fixable)
   Bug A — The desktop app writes no logs at all
   %APPDATA%\@deepseek-ai\dsh-desktop\logs\ contains only two crash logs — no regular runtime log. The host process's stdout/stderr go into an internal Electron pipe and are not reachable by the user.
   The only way I obtained a real error during this investigation was to reconstruct the host launch myself via dsh headless. Not something an ordinary user can do.
   Suggested: persist host stderr to disk, or expose a diagnostics export in Settings.
   Bug B — The model name shown in the UI does not match the model id actually sent
   From the bundled catalog:

"deepseek-flash": { "id": "deepseek-flash", "name": "DeepSeek V4.1 Flash",
                    "provider": "deepseek", "baseUrl": "https://api.deepseek.com" }

The UI shows "DeepSeek V4.1 Flash", but the id sent on the wire is deepseek-flash. A genuinely different id, deepseek-v4.1-flash (present in the opencode-go catalog), is rejected by api.deepseek.com:

HTTP 400: The supported API model names are deepseek-flash, deepseek-v4-pro,
          but you passed deepseek-v4.1-flash.

This mismatch cost a great deal of debugging time.
Bug C — llm-deepseek folds every non-HTTP failure into TRANSPORT
packages/llm/llm-deepseek/src/adapter.ts:

const auth = await this.dependencies.resolveAuth(connection)   // <- OUTSIDE the try
try {
    ...
    if (!response.ok) { ...providerError(...)... }   // only here do AUTH/RATE_LIMIT/SERVER exist
} catch (error) {
    if (error instanceof LlmError) throw error
    throw new LlmError('DeepSeek Messages transport failed', 'TRANSPORT', { cause: error })
}

Credential-resolution failure (outside the try) → labelled TRANSPORT
Any other non-LlmError → also TRANSPORT
This is the same misclassification family as #8947 and #9262. Listed here because it repeatedly sent this investigation in the wrong direction.
Bug D — Two provider groups in the model picker are both labelled "DeepSeek"
The picker contains DeepSeek (→ deepseek-official), opencode-go, and deepseek (→ the third-party pi-ai registration). Model display names overlap heavily (both show "DeepSeek V4.1 Flash" / "V4 Pro"). The user cannot tell which route is the account route, which is the API-key route, and which is a third-party gateway.
Bug E — opencode-go reports Connection error. for what is actually HTTP 400 missing x-opencode-session
Reproduced with the bundled OpenAI SDK 6.40.0:

HTTP 400 {"error":{"type":"MissingSessionID",
  "message":"Request is missing x-opencode-session and cannot be routed efficiently."}}

The UI shows the generic Connection error. (APIConnectionError fallback text). The profile has @michengai/opencode-session-header installed, but the header is not injected.
Bug F — The desktop nightly channel has no newer build
nightly.yml reports 0.2.0-rc.2 (2026-09-29), identical to what is installed. @deepseek-ai/dsh@0.2.1-alpha.2 exists on npm but is a different distribution channel from the desktop app, so it cannot be used to fix the desktop.
7. Related reports (checked — none is this bug)
#6934 — Desktop shell: plugin host APIs 403 for the renderer; plugin host routes registered on webServer are unreachable from the desktop shell (fall through to SPA index.html / 405), while the same plugin set works in the browser UI. Closest match in shape (desktop-only, works in web UI). Worth checking whether the host-side half of our 8 third-party plugins is involved. Our symptom is that the model request fails, and it reproduces with reasoningEffort: off on a brand-new session.
#9262 (and #7582, #7834) — Missing attachment object → session permanently fails, misreported as TRANSPORT. Failure is local, 13–15 ms; ours is 15–17 s with 5 retries.
#8947 — streamIdleTimeoutMs capped by undici's 300 s bodyTimeout, misreported as TRANSPORT. Trigger is a >300 s silent stream; ours fails in ~16 s.
#8837 — Desktop 0.2.0-rc.2: BOM in profile package.json crashes boot; turn-resume crash after interrupted tool call. Different failure points.
earendil-works/pi#8838 — Multi-turn/tool-call sessions fail with Connection error. because reasoning_content is echoed back as "". We tested multi-turn + tool calls + all three thinking-replay variants directly against the API: all HTTP 200.
I could not find an existing report matching this one.
8. What remains unknown (stated honestly)
I did not identify the specific difference between the Electron shell and the headless run. §5 lists everything excluded.
The only remaining variable is the Electron runtime itself, and it is not observable from outside:
The desktop app writes no logs (Bug A)
Model requests are issued by the host process, so they do not appear in the renderer's DevTools Network panel — that panel only shows UI polling RPCs (channels, snapshot, getState, …), all returning 200
What I need: a way to make the desktop host process's network failures visible — write host stderr to disk, add a diagnostics toggle in Settings, or surface the real cause in the UI.
9. Impact
Every provider fails in the desktop app (account route, API-key route, third-party gateway)
Scheduled automations all fail, every day (morning digests, heartbeat, patrol)
No self-service diagnosis is possible: no logs, error codes swallowed, provider groups indistinguishable by name
The only workaround is to use the web UI at http://127.0.0.1:3080, which shares the same ~/.dsh
10. Appendix — probe scripts used
10.1 Decide "engine problem" vs "Electron-shell problem"

$exe = "$env:LOCALAPPDATA\Programs\DeepSeek Harness\DeepSeek Harness.exe"
$cli = "$env:LOCALAPPDATA\Programs\DeepSeek Harness\resources\app.asar\dsh\node_modules\@deepseek-ai\dsh-desktop-host\lib\cli.js"
$env:ELECTRON_RUN_AS_NODE='1'; $env:DSH_HOME="$env:USERPROFILE\.dsh"; $env:DSH_PROFILE='desktop'
& $exe "--expose-internals" $cli headless "Reply with exactly: OK"

10.2 Read the live host process's environment (detect pollution)

Get-CimInstance Win32_Process -Filter "Name='DeepSeek Harness.exe'" |
  Where-Object { $_.CommandLine -match 'expose-internals' } |
  Select-Object ProcessId, CommandLine

10.3 TLS chain check (detect local interception)

import tls from 'node:tls';
for (const h of ['api.deepseek.com','platform.deepseek.com','harness.deepseek.com']) {
  const s = tls.connect({ host: h, port: 443, servername: h }, () => {
    const c = s.getPeerCertificate();
    console.log(h, 'issuer=', c.issuer?.CN ?? c.issuer?.O, 'authorized=', s.authorized);
    s.destroy();
  });
}

10.4 Reproduce with the bundled OpenAI SDK (pi-ai route)

import { createRequire } from 'node:module'
const req = createRequire('C:\\...\\resources\\app.asar\\dsh\\')
const OpenAI = req('openai')                       // bundled 6.40.0
const client = new OpenAI({ apiKey, baseURL: 'https://api.deepseek.com', maxRetries: 0 })
await client.chat.completions.create({ model: 'deepseek-v4-pro', max_tokens: 16,
  messages: [{ role: 'user', content: 'hi' }] })   // -> 200 in 1089 ms outside the desktop shell

[redwingsx62-sys]

✅ RESOLVED — root cause found: two plugins monkey-patching globalThis.fetch recurse into each other
Follow-up to the report above. The original report concluded "the failure exists only in the Electron desktop shell." That conclusion was wrong — I'm correcting it here so nobody else follows the same dead end.
Root cause: dsh-opencode-session-header and dsh-cost-meter both patch globalThis.fetch. Their patches call each other recursively, so every outbound fetch() throws RangeError: Maximum call stack size exceeded before any HTTP request is made. The exception is swallowed by llm-deepseek / the OpenAI SDK and re-labelled as the generic retryable TRANSPORT, which is why it looked like a network failure.

Quick self-check — are you hitting this?

1. Does this match your symptoms?
   All providers fail at once (deepseek-official, deepseek, opencode-go, …) — "all providers simultaneously" is the signature
   UI shows DeepSeek Messages transport failed or Connection error.
   Code is TRANSPORT
   Retries exhaust at 5/5, taking 15–17 s per turn (the default backoff 500+1000+2000+4000 ≈ 7.5 s plus overhead)
   A brand-new session fails too
   Started after an app/machine restart — not after a network change
2. Which plugins touch globalThis.fetch? If more than one does, you are at risk:

$mods = "$env:USERPROFILE\.dsh\profiles\desktop\node_modules"
Get-ChildItem $mods -Directory | ForEach-Object {
  $hits = Select-String -Path (Join-Path $_.FullName 'lib\*.js') `
            -Pattern 'globalThis.*fetch|target\.fetch\s*=|defineProperty\([^)]*fetch' `
            -ErrorAction SilentlyContinue
  if ($hits) { "WARNING: $($_.Name) patches fetch ($($hits.Count) hit(s))" }
}

3. Get the real error. Run a fetch inside the desktop profile's plugin context and print the stack — the file paths in it name the culprit:

try {
  const r = await fetch('https://api.deepseek.com')
  console.log('OK', r.status)
} catch (e) {
  console.log('FETCH THREW:', e.constructor.name, e.message)
  console.log(e.stack)      // <- names the exact plugin files
}

Captured stack in my case:

Fetch threw: RangeError: Maximum call stack size exceeded
    at wrapped (.../dsh-cost-meter/lib/native-search-fetch.js:13:34)
    at callAt (.../dsh-opencode-session-header/lib/index.js:70:65)
    at next (.../dsh-opencode-session-header/lib/index.js:75:35)
    at Object.sessionHeaderMiddleware (.../dsh-opencode-session-header/lib/index.js:157:57)
    at callAt (.../dsh-opencode-session-header/lib/index.js:72:18)
    at wrapped (.../dsh-cost-meter/lib/native-search-fetch.js:13:34)
    ...

---

The mechanism
dsh-opencode-session-header (lib/index.js:87-102) hijacks fetch with a getter/setter via Object.defineProperty:

const prevDesc = Object.getOwnPropertyDescriptor(globalThis, 'fetch')
state.patchedFetch = compose(state)
Object.defineProperty(globalThis, 'fetch', {
    get() { return state.patchedFetch },
    set(newFetch) {
        if (newFetch === state.patchedFetch) return
        prevDesc?.set?.call(globalThis, newFetch)
        state.setUnderlyingFetch(newFetch)      // underlying becomes `wrapped`
        state.patchedFetch = compose(state)
    },
})

dsh-cost-meter (lib/native-search-fetch.js:3-34) then wraps it the standard way — and trips the trap:

const original = target.fetch                  // getter -> patchedFetch
const wrapped = function (...args) {
    ...
    return Reflect.apply(original, this, args) // calls back into patchedFetch
}
target.fetch = wrapped                         // setter -> underlyingFetch = wrapped

Resulting cycle:

patchedFetch -> underlyingFetch (= wrapped) -> original (= patchedFetch) -> ...

Infinite recursion → RangeError. The plugin that patches second does not need to be buggy on its own; the combination is what deadlocks.

Why it "suddenly" broke
The two plugins coexist fine until they are loaded together, which only happens in the desktop profile at app start:

dsh-opencode-session-header installed : 2026-10-09 18:00:55
machine scheduled boot                : 2026-10-10 07:40
first scheduled task failed           : 2026-10-10 07:50   <- first load of both plugins

Installing a plugin does not affect the already-running process. The breakage only appears at the next app start — which is why "it worked yesterday and broke today" with no configuration change.

Fix
Option A — remove the plugin from the profile's bundles (fastest, verified working)
Edit ~/.dsh/profiles/desktop/package.json and delete "dsh-opencode-session-header" from dsh.profile.bundles, then fully quit and relaunch the desktop app (exit from the tray; a window close is not enough).

Also consider removing it from dependencies in the same file, or a later pnpm install / plugin-reinstall may add it back to bundles.
Option B — fix dsh-opencode-session-header (if you actually need it)
In lib/index.js, replace the getter/setter hijack in installFetchPipeline() with an immutable chained wrapper, or add re-entrancy protection inside the setter.

---

⚠️ Important correction to the original report (and why it matters)
The report's central experiment — "dsh headless succeeds, so the engine is fine and only the Electron shell is broken" — was invalid, because dsh headless never loads the desktop profile:

// @deepseek-ai/dsh/lib/bin.js
// 1) the first positional arg is expanded into --profile, overriding $DSH_PROFILE
const expanded = first !== void 0 && !first.startsWith("-") && first !== "plugin"
    ? ["--profile", ...argv] : argv;

// 2) the desktop profile is explicitly refused
function rejectElectronProfile(program, profile) {
    if (profile.toLowerCase() === "desktop")
        program.error('error: profile "desktop" is managed exclusively by the Electron application');
}

So dsh headless "..." silently runs the headless profile, and --profile desktop is rejected outright. The profile bundle sets are completely different:
profiles/headless/package.json → @deepseek-ai/dsh-base, @deepseek-ai/dsh-headless
profiles/web/package.json → @deepseek-ai/dsh-base, @deepseek-ai/dsh-web-app
profiles/desktop/package.json → base + web-app + 8 third-party plugins
dsh headless and the web UI are not valid control groups for any desktop-only problem. I compared "clean config" against "plugin-loaded config" while believing I was comparing "Node" against "Electron", and it sent the investigation into the network/TLS/proxy/kernel-filter layer for hours.
The fact that a stack overflow inside fetch is reported as TRANSPORT (a retryable transport error) is what makes this so misleading — see also #8947 and #9262 for other members of this misclassification family.

Runtime environment (for anyone reproducing)
DSH Desktop 0.2.0-rc.2, Windows 10, Electron 44.0.0, Node 24.18.1
Plugins in desktop profile at the time: dsh-opencode-session-header, dsh-cost-meter, dsh-whale-galgame, dshmarket, dsh-tavern, dsh-auto-memory, @michengai/dsh-im-connect, @michengai/dsh-automation
Verified after the fix: fetch connects normally, and deepseek-official/deepseek-v4-pro streams block-start → reasoning-delta → text-delta → usage → finish in a few hundred milliseconds.

Search keywords
TRANSPORT · DeepSeek Messages transport failed · Connection error. · retries 5/5 · 15–17 s · all providers fail · desktop only · plugin conflict · RangeError: Maximum call stack size exceeded · globalThis.fetch monkey patch · dsh-opencode-session-header · dsh-cost-meter · dsh headless does not load the desktop profile

[argszero]

Follow-up from a plugin author. Your correction is the right one; here are the three source facts that made this failure structurally unattributable, plus the plugin shape that would name it.

The cause chain has two silencing stages, not one. Stage one is your root cause (two plugins composing globalThis.fetch and recursing into each other). Stage two is why the answer had to come from twelve ruled-out hypotheses instead of from a log:

1. packages/llm/llm-deepseek/src/adapter.ts:62-66 — the stream generator's catch-all wraps any non-LlmError thrown inside it as new LlmError('DeepSeek Messages transport failed', 'TRANSPORT', { cause: error }). A RangeError: Maximum call stack size exceeded raised by a composed fetch wrapper therefore arrives at the retry policy with the same code and the same message as a dead socket. The code carries no root-cause information at all, which is why TRANSPORT here is not evidence of anything transport-shaped.
2. packages/llm/llm/src/index.ts:96-122 — LlmError.failure is a deliberately closed projection (message, code, status, providerRetryAfterMs, requestId); the inner cause is retained on the live Error only and never serializes into the session log. So the real error cannot be recovered post hoc from any session, only by re-running a fetch inside the profile — exactly the probe you published. Nothing was missing from your method; the log is designed not to carry this.
3. packages/experimental/inspector/src/host/inspection/network.ts:48-52 — the one built-in fetch capture refuses accessor-shaped globalThis.fetch: throw new Error('inspector: globalThis.fetch is an accessor and cannot be observed safely') (:52). Accessor (getter/setter) composition is one of the shapes implicated in your case, so for that class the built-in observability route is closed before it starts. An import-free static scan of the installed bundles — your own self-check script — is the right instrument rather than a workaround.

Why "all providers fail at once" is the composition signature. Provider adapters share no transport, no client and no credential path. The only things they do share in one host process are globalThis and the loaded plugin set. "Every route fails simultaneously and identically, in a fresh session, right after a restart, while dsh headless on the same profile succeeds" is therefore not a network shape — it is the shape of a process-global that something rewrote. That fork is the cheapest first step in triage and might be worth stating in the report body above the hypotheses.

The plugin I am building. A composition doctor for process-global patching, in the same family as the two we already publish — profile-duplicate-doctor (a package materialized twice inside one profile; it resolves package directories through ctx.profileContext / ctx.pluginPackages.packageOf without importing them) and client-bundle-conflict-guard (two client modules registering the same bundle key). Same seam, same discipline:

• enumerate the loaded profile packages and statically scan each one's published entry files for globalThis.fetch patch patterns (Object.defineProperty(globalThis, 'fetch', globalThis.fetch =, target.fetch =) — no import, no execution, so nothing is perturbed by the diagnosis;
• stay silent until there is a symptom: observe error frames on llm/stream, and only when one carries a generic transport code and two or more distinct packages patch fetch, attach a single durable notice naming them, the swallow path above, and the re-run recipe;
• claim only what it can prove: it can establish "two or more packages patch the same global in this process", not "these two recurse into each other". The recursion proof stays with the live stack, and the notice will say so.

If you have a preference between "scan at boot" and "stay silent until the first transport failure", that decides the default. My inclination is the second: a boot scan on a healthy machine is noise, and the notice is far more useful attached to the failure it explains.

[argszero]

The expensive part of this shape is not that the request failed — it is that the session records DeepSeek Messages transport failed and nothing else.

The cause does exist, but it dies in two steps. The adapter's catch-all ends the stream generator with new LlmError('DeepSeek Messages transport failed', 'TRANSPORT', { cause }) (packages/llm/llm-deepseek/src/adapter.ts:62-66), so a socket that died, a provider that hung up, and a bug inside the process all arrive under the same code. LlmError then keeps only the serializable facts in failure (packages/llm/llm/src/index.ts:96-122), and the agent loop re-throws a fresh error built from that projection, so by the time anything user-facing sees it the Error that carried cause is gone. A RangeError: Maximum call stack size exceeded in a fresh session, with every provider failing at once, looks exactly like a network problem.

I published a plugin for the reading half of this: @argszero/dsh-fetch-patch-doctor@0.1.0 (repo).

npm install @argszero/dsh-fetch-patch-doctor

The bundle patch mounts it; there is nothing to configure.

What it uses is the one seam where the error is still alive — the llm/stream waterfall runs around the adapter's generator, so a listener there is handed the live Error before the projection is taken. The wrapper passes every chunk through unchanged and re-throws the same object it caught; the only thing it takes is cause. It walks the chain, attributes stack frames to the mounted plugins whose own files they name, and then scans the plugins the Loader actually mounted (never the ones merely installed on disk) for code that writes a process global, reading them as text and never evaluating them. One durable user-role message per agent names the result, admitted through agent/pre-step.

Two boundaries I kept deliberately:

• It does not wrap a global to "watch" the composition — a third wrapper over the same fetch would be this very defect wearing a badge.
• It does not claim recursion. That evidence only exists in the live stack at the moment of failure, so the advisory reports a verdict it can support: attributed when a live stack names mounted packages, cleared when a stack was read and no plugin frame is on it (a diagnostic that can only ever accuse is one nobody trusts), and when no stack survived it names the writers as suspects, in those words.

So it makes the two halves visible at once; it does not fix the adapter. The upstream fix is to keep the cause in the failure the adapter publishes, or to resolve the wrapper it is calling.

Same family, if it is useful here: @argszero/cordis-plugin-profile-duplicate-doctor (a second copy of @deepseek-ai/dsh-tools in a profile → every tool call dies with reading 'prepare') and @argszero/cordis-plugin-client-bundle-conflict-guard (two client bundles registering the same module id) — both are cases of two runtimes meeting over an identity that had to be a single one, which is what a wrapper over a process global is as well.