[BUG] v2.1.143: silent render-miss after upstream stream stall in skill-scoped turn (follow-up to #58897, fix incomplete)

What's Wrong?

In the VS Code extension webview, the final assistant text from a long, multi-tool-call turn does not render in the chat panel, even though it is fully persisted to the session JSONL on disk and is visible when the same session is opened via the CLI (claude --resume <sessionId>). The chat appears truncated right after the user prompt, with no error toast, no Unhandled case: [object Object] banner, and no further UI updates. Subsequent shorter assistant turns in the same session DO render normally.

This looks like the render-miss class of #58897 / #59054 / #58984 but is not fixed in v2.1.143 (the version that closed those threads). I have two independent reproductions on v2.1.140 and v2.1.143 with identical signature.

The single structural difference between the not-rendered assistant entries and the rendered ones in the same JSONL is the attributionSkill field: the missing-from-GUI entries have attributionSkill: "<skill-name>" set (the turn was generated inside a slash-skill invocation), and the visible entries do not (turns outside any skill scope).

What Should Happen?

The webview should render the assistant turn that is already persisted to the session JSONL, including assistant turns produced inside slash-skill invocations. Developer: Reload Window should re-render the full conversation from disk (matching the workaround reported by the author of #58984), but in my case it does not recover the truncated render either.

Error Messages/Logs

No Unhandled case banner in the UI for this manifestation. Stall warnings and a Stop hook schema validation failure are logged at the moment the missing turn is persisted:

# session A: 2026-05-14, ext v2.1.140
2026-05-14T13:25:30Z  Stream started - received first chunk
2026-05-14T13:26:03Z  [WARN] [Stall] stream_idle_partial lastChunkAgeMs=15001 bytesTotal=655 idleDeadlineMs=300000
2026-05-14T13:26:29Z  [WARN] [Stall] stream_idle_partial lastChunkAgeMs=14999 bytesTotal=691
2026-05-14T13:26:44Z  [WARN] [Stall] stream_idle_partial lastChunkAgeMs=30001 bytesTotal=691
2026-05-14T13:27:01Z  [WARN] [Stall] stream_idle_partial lastChunkAgeMs=15001 bytesTotal=727
2026-05-14T13:27:03Z  [WARN] Streaming stall detected: 74.5s gap between events (stall #1)
2026-05-14T13:27:10Z  [WARN] Streaming completed with 1 stall(s), total stall time: 74.5s
2026-05-14T13:27:50Z  [WARN] Streaming stall detected: 36.2s gap between events (stall #1)
2026-05-14T13:28:54Z  Assistant text block (5649 chars, attributionSkill="<skill-name>") persisted to JSONL
2026-05-14T13:28:54Z  [DEBUG] Hook JSON output validation failed - Stop hook returned hookSpecificOutput.additionalContext which is not in the Stop schema

# session B: 2026-05-18, ext v2.1.143
2026-05-18T08:54:09Z  Stream started - received first chunk
2026-05-18T08:56:11Z  [WARN] Streaming stall detected: 45.8s gap between events (stall #1)
2026-05-18T08:56:39Z  Assistant text block (5253 chars, attributionSkill="<skill-name>") persisted to JSONL

In both sessions the assistant turn that fails to render is the first turn produced inside the slash-skill scope and follows at least one mid-turn upstream streaming stall.

Steps to Reproduce

1. Open a fresh VS Code chat in the Claude Code extension on remote-SSH (laptop -> Linux VM via vscode-server) with permissionMode: bypassPermissions, model claude-opus-4-7 1M.
2. Invoke a slash-skill that takes a ~3 to 4 KB prompt and runs 10 or more tool calls (Bash, Read, MCP servers). Both my repros used /triage against a structured SNOW ticket input.
3. Wait for the upstream stream to stall mid-turn (Streaming stall detected: >= 30s gap), which on the corporate Prisma Access / Zscaler network path happens once or twice per long turn in my measurements (39 stall events in one workday, peak 131.5s).
4. Let the model produce its final assistant text (typically 5 to 6 KB of markdown with mixed RU and EN, multiple fenced code blocks).
5. Observe: the JSONL session file gets the assistant entry written (with attributionSkill: "<skill-name>"), but the VS Code chat panel stays truncated at the user prompt. No toast, no banner.
6. Try Developer: Reload Window and re-open the same session. The truncated render persists across reload.
7. Open the same session via CLI in a terminal pane on the same VM: claude --resume <sessionId>. The full assistant text is visible there.

Roughly 2 to 3 of every 10 long skill-scoped triage turns hit this for me; short non-skill turns (post-skill chat replies in the same session) always render fine.

Claude Model

Opus (claude-opus-4-7, 1M context)

Is this a regression?

I don't know

Last Working Version

Unknown. The closely-related Unhandled case toast class was claimed fixed in 2.1.142 by claude[bot] auto-close on #58984 / #59054, but multiple users (bornsl0ppy, SpencerBelleau, kitbeaupre-boop) confirmed the toast still fires on 2.1.142 in the #58897 thread. One user (heidkaemper) reports 2.1.143 works for them on macOS, but I am hitting the render-miss class (no toast) on 2.1.143 with the signature above.

Additional Context

• Extension: anthropic.claude-code-2.1.143 (and earlier anthropic.claude-code-2.1.140)
• Spawn: confirmed in extension log, version: 2.1.143, native binary at <ext-path>/resources/native-binary/claude
• Permission mode: bypassPermissions (not Auto mode, so this is not the toAutoClassifierInput path mentioned in #58984)
• Host: Windows 11 (Azure AD Joined laptop) connecting via VS Code Remote-SSH to Linux VM running vscode-server; extension runs in the remote extension host
• Network: corporate Prisma Access / Zscaler proxy in front of api.anthropic.com (high stall rate, likely SSE buffering)

Related issues

• #58897 (OP for the Unhandled case class, closed-as-fixed-in-2.1.142 by claude[bot])
• #59054 (duplicate, closed; my earlier 5th-repro comment is in the thread)
• #58984 (duplicate, closed; author notes Reload Window re-renders for them, which does NOT match my case)
• #55863 (open; structural sibling: extension recognizes message subtype, inputStream.enqueue, no webview renderer branch). The attributionSkill: "<skill-name>" field on the not-rendered entries is the equivalent signal here.
• #59030 (open; duplicate label, different trigger: Monaco editor worker)

Asks

1. Reopen the underlying tracking issue (or scope a new one) for the render-miss class specifically. The toast and the silent render-miss are likely two outcomes of the same renderer fragility, but only one of them is currently marked fixed.
2. Confirm whether the webview switch in webview/index.js (the QB1 assertNever pattern from #58897 OP) has an explicit branch for assistant turns with attributionSkill set, or whether those fall through to a no-op default.
3. Document a reliable workaround. CLI resume works for me, but I cannot expect non-CLI users to recover their truncated conversations this way.

Happy to share full session JSONLs and extension logs privately.