Windows (MSIX): clicking a Claude Code notification leaves the app window painted-frozen until you click inside it

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code

What's Wrong?

On Windows, clicking a Claude Code desktop notification raises the app window but leaves it painting-frozen: the content on screen is a stale frame and no new frames are produced. The renderer is alive and running script — it just never paints. It stays that way until you click inside the window. Mouse movement and the scroll wheel do not release it.

The window is not busy and it is not hung. The app's own instrumentation already detects the condition and logs it as mainView paint probe: page runs script but produced no frame, outcome: 'no_raf', with the renderer's page-visibility still reported as hidden while the window is visible, focused and not minimized.

It does not come back on its own. I held one occurrence for over five minutes without touching anything and it never recovered.

What does and does not release it

| action while frozen | result |
|---|---|
| click inside the window | repaints immediately |
| drag the window by its title bar | repaints immediately |
| move the mouse over the window | nothing |
| scroll wheel over the window | nothing |
| wait | nothing (held >5 min) |

A title-bar drag does not deliver input to the renderer, but it does involve a mouse press, so it does not separate "the window moved" from "a mouse button was pressed".

What Should Happen?

Clicking the notification raises the window and it repaints immediately, as it does when the window is raised by Alt-Tab or by the taskbar button.

Error Messages/Logs

Full record from %LOCALAPPDATA%\Claude\logs\main.log, from a freshly restarted app:

mainView paint probe: page runs script but produced no frame
{ trigger: 'show', outcome: 'no_raf', probe_count: 4, elapsed_ms: 3718,
  raf_ms: null, cadence_frames: 0, cadence_timer_lag_ms: 906,
  paint_entry_count: 2, first_paint_ms: 768, first_contentful_paint_ms: 768,
  document_age_ms: 212648, bounds_were_stale: false, since_dom_ready_ms: 213958,
  renderer_visibility_state: 'hidden', renderer_has_focus: false,
  boot_ui_ready: 'frame', boot_placeholder: false, static_composer: 'absent',
  inner_width: 1946, inner_height: 1391,
  window_visible: true, window_focused: true, window_minimized: false,
  window_opacity: 1, system_idle_s: 0,
  view_width: 1946, view_height: 1391, content_width: 1946, content_height: 1391,
  view_visible: true, background_throttling_allowed: true,
  born_hidden: false, born_hidden_reason: null, surface: 'code' }

renderer_visibility_state: 'hidden' while window_visible: true, window_focused: true, window_minimized: false is the defect in one line. Every record I captured is identical in shape: view_visible: true, renderer_has_focus: false, static_composer: 'absent'. All are no_raf; the probe's view_hidden outcome never fired.

There are 20 such records in my log across two days. The probe can emit more than once per episode, so treat 20 as an upper bound on the number of freezes rather than a count of them.

Steps to Reproduce

1. Open a Claude Code session in the desktop app.
2. Cover the Claude window completely with another window. Do not minimize it. Leave it a few seconds.
3. Let a turn complete so the idle / "Claude finished a task" notification appears.
4. Click the notification.
5. The window is raised and focused, but the content is a stale frame.
6. Nothing changes until you click inside the window.

Two distinctions are essential, and both are easy to miss:

• Minimizing does not reproduce it. Only "visible but fully occluded" does.
• Only the notification path is affected. Raising the very same occluded window with the taskbar button or Alt-Tab repaints instantly.

I reproduced this deliberately five times, every time.

Claude Code Version

2.1.246, as bundled in the MSIX desktop app. The app logs [CCD-autoupdate] Disabled: MSIX install, so the bundled version tracks the MSIX package rather than npm; npm's latest at the time of filing is 2.1.247.

Platform

Claude Desktop app on Windows — MSIX / Windows Store package Claude_pzs8sxrjxfjjc, version 1.37937.3.0. Electron 42.10.0, Node 24.18.1. Probe surface: 'code'.

Operating System

Windows 11 Pro 10.0.26200

Additional Information

Control matrix. Five variants, each with CPU sampling and a check of the probe log:

| how the renderer was hidden | how the window was raised | result |
|---|---|---|
| occluded (visible, not minimized) | notification click | frozen — held >5 min, released by a click |
| occluded (visible, not minimized) | taskbar button or Alt-Tab | instant, no probe record |
| occluded (visible, not minimized) | second-instance activation (app launched again while running) | instant, no probe record |
| minimized | notification click | instant, no probe record |
| minimized | second-instance activation | instant, no probe record |

It is not a busy hang. I sampled per-process CPU every 250 ms through a 73-second freeze. Deltas across the whole freeze:

| process | CPU-seconds over 73 s |
|---|---|
| renderer | +0.16 |
| GPU process | +0.09 |
| main | +0.25 |

Nothing is spinning. This only establishes "not a busy hang" — an idle GPU process is also what you would expect from a window Chromium believes is genuinely occluded.

Things I ruled out

• Not caused by background/stealth-relaunch startup. Early samples all had born_hidden_reason: 'background_launch', so I fully quit the app and relaunched it normally from the Start menu. The payload above is from that clean instance (born_hidden: false, born_hidden_reason: null, first_paint_ms: 768, renderer 3.5 minutes old) and it still reproduces. Confirmed twice.
• Not session size. Reproduces on a brand-new short session.
• Not load. See the CPU table.

This is a black-box investigation from outside the app, so I am not proposing a fix.

Temporary workaround for anyone hitting this. If your window looks frozen after clicking a notification, click once anywhere inside it — it repaints immediately. To avoid it altogether, raise the window with Alt-Tab or the taskbar button instead of clicking the notification.

Related issues (none are duplicates)

• #84684, #84009 — same class of defect (rAF suspended while hidden), but in the Browser pane, not the main app window. Both closed.
• #79220 — Windows MSIX compositing, and a report that Chromium command-line workarounds cannot be applied under MSIX packaging.
• #85521 — desktop app GPU process behaviour while backgrounded.