Sign up
View stargazers13Sign up

SnapShot shortcut cannot capture Xcode Device Hub on macOS 27#12103

openedSep 16, 2026byRrashidsg

What happened

On macOS 27, with a simulator open in Xcode's Device Hub, invoking the configured T3 Code SnapShot shortcut consistently fails with “Snapshot failed — The active window is not available for capture.” The reporter supplied a screenshot of the error.

Diagnosis

The desktop trace records DesktopSnapShotError during desktop.snapShot.prepareCapture, before macOS capture starts. In the installed revision, captureSource throws window-unavailable when activeWindow() returns no window. The macOS lookup takes NSWorkspace.frontmostApplication.processIdentifier and searches the on-screen CoreGraphics window list for a layer-0 window with that owner PID.

A read-only OS probe while Device Hub was frontmost returned Device Hub with PID -1 from NSWorkspace, while CoreGraphics listed its visible layer-0 window under PID 35409. That PID belonged to Xcode's DeviceHub executable. The mismatched PIDs explain why the lookup returns no window. The cause of macOS reporting PID -1 for Device Hub has not been determined.

Steps to reproduce

  1. Open a simulator in Xcode 27's Device Hub on macOS 27.
  2. Bring Device Hub to the foreground and invoke the configured T3 Code SnapShot shortcut.
  3. Observe “Snapshot failed — The active window is not available for capture.” The reporter says this happens consistently.

Version

T3 Code Nightly 0.0.43-nightly.20260916.1811 (ccf220be205f0e509021dbc8cbda90daa638e20d).

Environment

macOS 27.0 (build 26A428), Apple Silicon (arm64); Xcode 27.0 (build 27A266a); T3 Code desktop app. The t3 triage CLI ran under Node v26.8.2.

Evidence

text
12026-09-16 10:52:50 -05:00 desktop.snapShot.prepareCapture Failure
2DesktopSnapShotError: The active window is not available for capture.
3 at captureSource (.../apps/desktop/dist-electron/main.cjs:97112:23)
4
5NSWorkspace frontmost application: Device Hub, PID -1
6CoreGraphics on-screen layer-0 window: Device Hub, owner PID 35409
7PID 35409 executable: /Applications/Xcode.app/Contents/Applications/DeviceHub.app/Contents/MacOS/DeviceHub

Related issues

No matching issue found. #11713 also mentions Device Hub but concerns simulator installation detection, not SnapShot capture.

Fix applied or workaround

No T3 Code fix applied. A manual macOS window screenshot can be attached to the T3 Code composer as a workaround.

Filed by

Codex (Astra) via t3 triage.

RrashidggSep 16, 2026
Synced from GitHub

Screenshot attached: Image

Created issue with my wrong GH account

JJulius MarmingeSep 16, 2026

Triage

Confirmed on current main (ccf220be205f0e509021dbc8cbda90daa638e20d) and your Nightly 0.0.43-nightly.20260916.1811 — same commit. This is a real bug in macOS SnapShot window lookup, not a permission miss. Not already fixed, and not a duplicate of #11713.

What you reported. On macOS 27, with a simulator open in Xcode 27’s Device Hub, the SnapShot shortcut consistently fails with Snapshot failed — The active window is not available for capture. Your probe matches the failure:

text
1NSWorkspace frontmost application: Device Hub, PID -1
2CoreGraphics on-screen layer-0 window: Device Hub, owner PID 35409

On Xcode 27, Device Hub is the simulator UI. SnapShot cannot capture that surface while Device Hub is frontmost.

What the code does. Capture never reaches screencapture. The span is desktop.snapShot.prepareCapture.

  1. Lookup is PID-only. activeWindow("darwin") (apps/desktop/src/snapShot/ActiveWindow.ts) takes NSWorkspace.frontmostApplication.processIdentifier and walks CGWindowListCopyWindowInfo for a layer-0 window with that owner PID. No match → empty stdout → undefined.
  2. macOS treats -1 as “not running.” Device Hub is a nested app inside Xcode; frontmostApplication can still be named “Device Hub” while its PID is -1. No real window has owner PID -1.
  3. That undefined is the toast. captureSource throws DesktopSnapShotError({ operation: "window-unavailable" }). The window was already on screen under PID 35409; capture only needs the CG window id.
  4. Accessibility also needs the real PID. Always set owner.processId from kCGWindowOwnerPID, not from NSWorkspace.

Related, not duplicates

  • Open #11713 — Device Hub / empty simulator list during setup. Same product name, different stack.
  • Merged #8103 — shipped this PID-equality lookup (still current).
  • Open #11037 / #11325 — shortcut debounce / Chrome a11y after a window was already found.

Suggested fix

Keep the PID match when processIdentifier > 0. When it is not (Device Hub’s -1), fall back to the first on-screen layer-0 window whose kCGWindowOwnerName equals app.localizedName. Always set owner.processId from kCGWindowOwnerPID.

Do not “fix” this with more TCC, by treating Device Hub as unsupported, or by changing the toast copy alone.

Workaround

Attach a manual macOS window screenshot to the composer. Focusing any other app and invoking SnapShot still works; focusing Device Hub does not.

RrashidsgSep 16, 2026
Synced from GitHub

Thanks Julius. Cool if I take a stab at the PR based on your triage?