GetShareableContent/DisplayMissing error when recording a window on macOS 26.3.1

[dpaluy]

Description

When attempting to record a specific window, Cap shows an error dialog with the message: GetShareableContent/DisplayMissing.

Screen recording permissions are granted. Full-screen recording works fine — the error only occurs when selecting "Window" recording mode.

Reproduction

1. Open Cap
2. Select "Window" recording mode
3. Pick a window to record
4. Error dialog appears: "An error occurred — GetShareableContent/DisplayMissing"

Additional Context

• Cap version: 0.4.71 (0.4.71)
• Operating system, version: macOS 26.3.1 (25D2128)
• Device: Mac (Apple Silicon)

Screenshot:

cap-desktop.2026-03-09.log

[linear]

CAP-657

[tembo]

Thanks for the detailed report. I traced through the codebase to understand what's happening here.

The GetShareableContent/DisplayMissing error occurs in apps/desktop/src-tauri/src/recording.rs:116 when Cap cannot locate the display containing your selected window within macOS's SCShareableContent API response. The flow is:

1. When you select a window, Cap needs to determine which display it belongs to via Window::from_id(id).and_then(|w| w.display()) in crates/recording/src/sources/screen_capture/mod.rs:74
2. Cap then verifies this display exists in the SCShareableContent using display.raw_handle().as_sc(shareable_content.retained()) in crates/scap-targets/src/platform/macos.rs:181-187
3. If not found, Cap refreshes the content cache once and retries
4. If still missing after refresh, the DisplayMissing error is raised

The fact that full-screen recording works but window recording fails suggests the display lookup from the selected window (step 1) returns a display ID that doesn't match any display in SCShareableContent.displays().

This is likely related to macOS 26 (Tahoe) - there have been several reports of ScreenCaptureKit behavior changes in newer macOS versions (see issues #1535, #1110, #1166). Apple's ScreenCaptureKit has received updates that may affect how display IDs are enumerated or matched.

Potential workaround to try: Could you check if this happens with all windows or only specific apps? Some apps create windows that behave differently (e.g., floating panels, windows spanning multiple displays, or windows on a virtual display).

For maintainers: The display matching logic in DisplayImpl::as_sc() compares display_id().0 == self.0.id (comparing CGDirectDisplayID). On macOS 26, there may be a mismatch between the display ID returned by CoreGraphics CGWindowInfo and the display IDs reported by SCShareableContent.displays(). Adding debug logging in acquire_shareable_content_for_target to print the target display ID vs. available display IDs would help confirm this.

If you can share debug logs from /Users/{username}/Library/Logs/so.cap.desktop/, that would help narrow down whether the issue is with window-to-display resolution or the display-to-SCShareableContent matching.

[dpaluy]

Originally I tried to record Ghostty window.
I just tested other windows and whole screen and got the same error: GetShareableContent/DisplayMissing

This issue happens after I updated the Mac and also Cap app

[Lam-L]

Appreciate the tip! V4.0.0 works for me. And hope this bug can be resolved in future versions.

[m13v]

we use ScreenCaptureKit for screen capture in a macOS agent and hit similar issues on Tahoe. a few things that might help debug this:

SCContentFilter initialization changed behavior in macOS 26 - the display property can come back nil when filtering by window if the window is on a secondary display or if the display mapping changed (which happens after sleep/wake or display hotplug). the GetShareableContent call succeeds but the display association is missing.

things to check:

• are you creating the SCContentFilter with desktopIndependentWindow? on 26.3 this path avoids the display lookup entirely since it captures the window regardless of which display it's on
• if you're using the display-based filter, try refreshing the SCShareableContent right before creating the filter. the cached content can go stale after display configuration changes
• the fact that full-screen recording works but window recording doesn't points to the window-to-display mapping being the issue, not the permissions

if none of that helps, SCStreamDelegate error callbacks might give more detail than the dialog message

[m13v]

our ScreenCaptureKit capture implementation for reference: https://github.com/m13v/fazm/blob/main/Desktop/Sources/FloatingControlBar/ScreenCaptureManager.swift - handles display mapping, downscaling, and the JPEG quality adjustment for different capture scenarios