UI stops redrawing after Ctrl+Click on an OSC 8 hyperlink; clicks are still processed and new windows never appear #20900

Windows Terminal version

1.27.2861.0 (Canary, x64)

Windows build number

10.0.26300.9711

Other Software

• Claude Code 2.1.319, which prints OSC 8 hyperlinks
• Device: Intel Core i7-1185G7, 32 GB RAM, Intel Iris Xe Graphics (driver 32.0.101.7085), one 60 Hz display
• Canary settings that affect rendering: theme: system, useAcrylic: false, useAcrylicInTabRow: false, rendering.disablePartialInvalidation: true, opacity not set (100%)

Steps to reproduce

1. In a tab running Claude Code, hover an https OSC 8 hyperlink it printed. The "Ctrl+Click link to open" tooltip appears.
2. Ctrl+Click the link.

This is the first occurrence, and I have not reproduced it. At the time, the Canary process had been running for 10 days with about 20 tabs and 1.1 GB of private bytes.

Expected Behavior

The tooltip closes and the UI keeps responding.

Actual Behavior

• The link opened in the browser.
• The tooltip stayed on screen. Tabs, the tab row, and window switching stopped responding.
• Typing into the focused tab still worked, and its text kept rendering.
• Minimizing and restoring the window removed the tooltip. The rest of the UI stayed frozen.
• Launching Canary again did not open a window. Typing in the existing window then stopped working too.
• Ctrl+Alt+Del, lock/unlock, and a graphics driver reset (Win+Ctrl+Shift+B) did not recover it. Ending the process did.

Trace findings

A WPR trace (GeneralProfile + CPU) covers about 20 s of clicking tabs, typing, and launching a new Canary window. The XAML layer processes input but never renders a frame:

Memory dump findings

The dump was taken while the UI was frozen.

• Every thread is idle. The UI thread is in GetMessageW, and XAML's render thread waits in CompositorScheduler::RenderThreadFrame → CWindowsServices::WaitForObjects.
• The dump doesn't contain any stowed exceptions.
• A windows.storage!MessagePumpThreadProc thread and a combase!CDllHost::STAWorkerLoop thread are idle in the process, consistent with the earlier ShellExecuteExW call.

Related code (main at 188822f)

• TerminalPage.cpp#L3317-L3327: Ctrl+Click on an https link calls ShellExecuteExW synchronously on the UI thread, from a dispatcher callback (TermControl.cpp#L3212). The comment there notes that ShellExecute pumps the UI thread's messages (GH#7994).
• AppHost.cpp#L1275-L1282: a new window calls ShowWindow only after a Low-priority resume_foreground. If XAML stops running dispatcher work, the window stays hidden, matching the invisible windows observed.

One hypothesis, unconfirmed: the nested message loop inside ShellExecuteExW re-entered XAML while it was processing the tooltip or pointer input, and left XAML's frame scheduling in a state where it never requests another tick.

Attached:

• canary-freeze-summary.txt: tick counts per process, Canary samples per thread, top UI-thread frames
• canary-freeze-ui-thread-tree.txt: UI-thread call tree (1,366 samples)

Frames in Terminal's own modules are module-relative addresses. PDB identities:

A full memory dump and the ETL are available privately on request.

canary-freeze-summary.txt
canary-freeze-ui-thread-tree.txt