macOS SnapShot captures the window-sharing indicator instead of the app window while another app is capturing it#33947
What happened
On macOS 26, a SnapShot (double-Shift) of T3 Code gave a 31x20 PNG of a tiny window instead of the T3 Code window. The attached accessibility tree shows the captured window is titled "Window" (role dialog) with one child button, WindowSharingSessionButton.
It happens only while another app is capturing the T3 window through ScreenCaptureKit (purple capture indicator in the menu bar). Here that was a Codex thread running inside T3 that used ChatGPT computer use. The same thing should happen during a Zoom, Meet, Slack or FaceTime window share. Once the capture stopped, the next SnapShot was full size.
Diagnosis
macActiveWindow in apps/desktop/src/snapShot/ActiveWindow.ts (around lines 120-121) takes the first visible layer-0 window of the frontmost app that has a non-empty title.
While a window is being shared, macOS 26 adds a small sharing indicator window to the shared app's own window list. It is layer 0, alpha 1, titled "Window", and sits in front of the main window, so it is selected. snapShotThumbnailSize (DesktopSnapShot.ts, around line 310) then sizes the capture to its bounds (31x20 or 66x20).
The fix for #16077 (#22624) only skips untitled helper strips, so this titled dialog gets through. Possible fixes: skip AXDialog windows or windows below a minimum size, or prefer the largest titled standard window.
Steps to reproduce
- macOS 26 with T3 Code Desktop; SnapShots enabled with Screen Recording and Accessibility granted.
- Have another app capture the T3 Code window through ScreenCaptureKit, e.g. a Codex thread in T3 using ChatGPT computer use, or a window share in a video call. The purple capture indicator appears in the menu bar.
- With T3 Code frontmost, take a SnapShot with double-Shift.
- The attachment is about 31x20 px and shows only the indicator.
- Stop the capture and repeat: the SnapShot is full size.
Version
0.1.9-nightly.20261110.4465 (desktop app). The file has had no commits since #22624 (Nov 1), so main is likely affected too.
Environment
macOS 26 (Darwin 25.6.0), arm64, built-in Retina display (1512x982 points). Desktop app against its local server.
Evidence
| 1 | On-screen layer-0 windows of the T3 process, front to back (CGWindowListCopyWindowInfo, OnScreenOnly): |
| 2 | |
| 3 | layer=26 "" 1512x33 alpha=0 |
| 4 | layer=0 "Window" 66x20 alpha=1 <- selected (AXDialog, AXButton child) |
| 5 | layer=0 "" 1512x32 alpha=0 |
| 6 | layer=0 "T3 Code (Nightly)" 1512x949 alpha=1 |
| 7 | |
| 8 | macOS unified log (ControlCenter / WindowServer): |
| 9 | |
| 10 | 10:53:21 Updating sharing context ... to SharingWindow |
| 11 | 10:53:21 Content sharing streams changed to count 1 |
| 12 | Stream(bundleID: com.openai.codex, selection: .window(<T3 main window id>)) |
| 13 | 11:03:07 SnapShot -> 31x20 |
| 14 | 11:03:39 Ending sharing context ... ; streams count 0 |
| 15 | 11:03:50 SnapShot -> full window |
| 16 | |
| 17 | After the stream ended, the "Window" entry was gone from the list. |
Related issues
#16077 (same symptom from Chrome/Electron untitled helper windows; fixed by #22624, which only covers untitled windows).
Fix applied or workaround
Stop the window capture (click the menu-bar capture indicator, or wait for the agent task to finish), then take the SnapShot again. Region capture also avoids window detection. No local changes made.
Filed by
Claude Opus 5.5 (claude-opus-5-5) via T3 Code triage (Claude Code harness).