[BUG] Desktop app: side panel / artifacts / file previews never composite — renderer reports artifactsPane + framebufferPreview "unavailable" (1.30096.5, Windows/MSIX)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Related to #78765 (open) and #81275 (open); #83997 was closed as a duplicate of #81275. I have searched existing issues — this specific failure isn't reported yet. Please read "How this differs from existing issues" in Additional Information before treating it as a duplicate.

On this machine, every surface routed to the desktop app's side panel currently fails to display — 6 of 6 observed render attempts failed on 2026-08-16/17 under v1.30096.5:

• Markdown / file previews: never appear. The file card renders; no panel ever opens.
• Artifact publishes: succeed, but no in-app preview ever displays.
• In-app Browser pane (mcp__Claude_Browser__*): the pane's WebContents demonstrably runs — navigate works, read_page / get_page_text return live content, and javascript_tool executes against a live localhost page — but computer{action:"screenshot"} always fails with the app's own "not compositing frames" error (see Error Messages/Logs).

So the engine is alive; the app never mounts or composites a visible pane surface.

Strongest current-state signal

Two live renderer processes carry a --desktop-features JSON payload reporting:

artifactsPane:                unavailable
coworkArtifacts:              unavailable
framebufferPreview:           unavailable
coworkBrowser:                unsupported (cowork_browser_disabled)
sidePanePopoutNativeViews:    supported
filePreviewNativeViewRouting: supported

Question for the team: is cowork_browser_disabled / artifactsPane: unavailable a server-side rollout flag, or client build state? It reads as the pane being routed through a native-view path while the pane features themselves are flagged off.

What Should Happen?

Markdown and file previews should open in the side panel; published artifacts should render an in-app preview; and computer{action:"screenshot"} should return pixels whenever navigate / read_page / get_page_text already succeed against that same tab.

More generally: the pane should composite without requiring a human to manually foreground it, since an agent session driving the pane has no way to do that.

Error Messages/Logs

Browser pane screenshot — reproduced 6/6 on 2026-08-16 and 2026-08-17:

  Screenshot timed out after 5s: the Browser pane is not displayed, so the page is not
  compositing frames. Display the pane and retry.

Renderer process --desktop-features flag payload (2 live renderer processes):

  artifactsPane: unavailable · coworkArtifacts: unavailable · framebufferPreview: unavailable
  · coworkBrowser: unsupported (cowork_browser_disabled)
  · sidePanePopoutNativeViews: supported · filePreviewNativeViewRouting: supported

Histogram of "[Preview] capturePreviewScreenshot failed ... not compositing frames"
from %APPDATA%\Claude\logs\main*.log, with the version then running:

  DATE        COUNT   RUNNING VERSION
  2026-07-24    24    1.24012.x
  2026-07-26     4    1.24012.x
  2026-07-27     6    1.24012.x
  2026-08-07    30    1.26832.0
  2026-08-16     5    1.30096.5
  2026-08-17     1    1.30096.5

Update history across the breakage window (local time):

  2026-08-14 21:33:46   1.26832.0 -> 1.30096.1
  2026-08-15 00:33:51   package for 1.30096.5 staged (not yet running)
  2026-08-15 15:36:03   [updater] Version changed since last launch: 1.30096.1 -> 1.30096.5
  2026-08-16 04:47      machine reboot

Note on ordering: five app restarts occurred on 2026-08-15 between 15:15 and 15:35 (none
crash- or updater-initiated, per Crashpad and updater logs) -- i.e. under 1.30096.1, while
already fighting the panel, BEFORE 1.30096.5 ever ran. Two more restarts followed. No
pane-render attempts are logged on 8/15 itself; the first post-update attempt was
2026-08-16 23:49:55, and it failed.

Steps to Reproduce

1. On Windows (MSIX install), run the Claude desktop app 1.30096.5 with the side/Browser pane not manually foregrounded.
2. Have the session write a Markdown file and open it as a preview → the file card appears, but no side panel ever opens.
3. Publish an artifact → the publish succeeds, but no in-app preview ever renders.
4. Drive the in-app Browser pane against any URL (a local http://localhost:<port> page is sufficient — page content is irrelevant):

• navigate → succeeds
• read_page / get_page_text → return live, correct content
• javascript_tool → executes against the live page

1. Call computer{action:"screenshot"} on that same tab → fails after ~5s with:

Screenshot timed out after 5s: the Browser pane is not displayed, so the page is not compositing frames. Display the pane and retry.

1. Repeat. On this machine it is 100% reproducible — 6 of 6 attempts failed across 2026-08-16 and 2026-08-17.

No project files, repo, or minimal code example are needed: steps 2, 3 and 5 fail independently of any file or page content, and step 4 proves the underlying WebContents is alive while the pane is not composited.

Claude Model

None

Is this a regression?

I don't know

Last Working Version

Unknown — no known-good version; same failure logged as far back as 1.24012.x (2026-07-24)

Claude Code Version

2.1.229 (Claude Code CLI); Claude desktop app 1.30096.5 (Windows MSIX)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

(Form notes: "Terminal/Shell" is set to Other because this is a desktop-app rendering bug, not a terminal-hosted one. "Is this a regression?" is I don't know — see the honest characterization at the end.)

Ruled out on this machine (each independently verified, read-only)

• Crashes: the Crashpad database has zero dumps, ever (reports/ empty, metadata 0 bytes); Sentry session.json status ok, errors 0. The app never crashes here — this is the key difference from #81275.
• GPU: the --type=gpu-process child is alive; no --disable-gpu* flags on any process; zero D3D11 / ANGLE / ContextLost lines in any log era. Twelve GPU process gone: { reason: 'killed', exitCode: 1 } events exist on 2026-07-23/24 only — none since, and none correlated with the current failures.
• OS / driver churn: no Windows updates since 2026-06-27; NVIDIA driver 595.71 dated 2026-02-26.
• Window geometry / config: no out-of-bounds geometry in any persisted state (window-state.json, config.json quick-window position); desktop-frame.paneStore.v1 in claude_desktop_config.json is empty defaults; Preferences / Local State contain no hardware_acceleration_mode or placement overrides.

Environment

• Claude desktop app 1.30096.5 (MSIX / WindowsApps), Electron 42.7.0, Chrome 148.0.7778.280, Node 24.18.0 (from Sentry scope_v3.json)
• Claude Code CLI 2.1.229 (updater-managed under %APPDATA%\Claude\claude-code\; 2.1.222 present alongside)
• Windows 10 Pro 10.0.19045 · NVIDIA RTX A5000, driver 595.71
• Displays: 2× DELL U2415, both portrait (1200×1920 logical), contiguous at (0,0) and (1200,0)

Impact / workaround

• All in-app visual delivery is dead in the current state; interactive artifacts are unusable in-app.
• Workaround: rendering everything in external Chrome works fine.

How this differs from existing issues

• #78765 — same 5s "not compositing frames" error string (see the 2026-07-27 comment in that thread), but that report is scoped to the Browser pane's screenshot/zoom path. Here every side-panel surface is dead, including Markdown/file previews and artifact previews, which never involve the screenshot tool at all. I'm adding a confirmation comment in that thread pointing here.
• #81275 / #83997 — root cause there is a GPU process crash (exit 101457950) that takes down the whole app. On this machine the app never crashes, there are zero Crashpad dumps, and the GPU child process stays alive throughout. Different failure mode.
• New evidence here that I haven't seen elsewhere: the --desktop-features renderer payload showing the pane features themselves flagged unavailable / cowork_browser_disabled while the native-view routing features report supported; plus a multi-version failure histogram (1.24012.x → 1.30096.5).

Honest characterization

The symptom recurs across at least 1.24012.x → 1.30096.5 and is 100% reproducible right now (6/6 on 8/16–17). It is not a clean single-version regression — which is why "Last Working Version" is unknown rather than a specific build.

Full read-only forensic detail (Crashpad/Sentry inventories, log greps, process flags, display topology, warning histogram) available on request.