Window capture recording screen region instead of window content (0.4.84) #1754

Activity

1. mrfelton

   added

   bugSomething isn't workingSomething isn't working

   on Apr 22, 2026
2. linear commented on Apr 22, 2026

   

   linearBot

   on Apr 22, 2026 – with Linear

   More actions

   CAP-689
3. tembo commented on Apr 22, 2026

   

   temboBot

   on Apr 22, 2026 – with Tembo

   More actions

   Thanks for the detailed report. Looking at the codebase, I can see the architectural reason for this behavior:

   Current Implementation:
   For recording, Cap uses display-based capture with crop bounds (as_content_filter_excluding_windows) in crates/recording/src/sources/screen_capture/macos.rs:222-228. The window bounds are calculated relative to the display in crates/recording/src/capture_pipeline.rs:368-389 and used to crop the display capture.

   Contrast with Screenshots:
   Screenshots use sc::ContentFilter::with_desktop_independent_window() in crates/recording/src/screenshot.rs:859, which captures the window content itself regardless of what's overlaid on screen.

   Fix Direction:
   To get true window-only recording (not affected by overlapping content), the recording pipeline would need to use with_desktop_independent_window for window targets, similar to how screenshots work. This would require changes in ScreenCaptureConfig::to_sources() to create a window-specific content filter rather than a display filter with crop bounds.

   Related Context:

   • Issue Screen capturing crashes when capturing window of 2nd screen #836 covers window capture crashes on secondary screens, which may share some capture pipeline code paths
   • Issue fix(windows): Cap UI appears as black rectangle in studio recordings (window exclusion is macOS-only) #1737 relates to window exclusion being macOS-only

   The user notes this was working in a previous version before 0.4.84 - this would be worth investigating whether the behavior changed intentionally (perhaps for performance/stability reasons) or if there was a regression.
4. nexmoe commented on Aug 23, 2026

   

   nexmoe

   on Aug 23, 2026

   More actions

   Description

   This issue still reproduces with the newly bundled Cap CLI.

   When cap record start --window <window-id> targets a specific window, Cap records the display rectangle currently occupied by that window rather than the window surface itself. If the target is in the background or another window overlaps it, the foreground content inside that rectangle appears in the recording.

   I reproduced this in both instant and studio modes. In Studio mode, the Cap recording controls are also captured if that panel overlaps the target rectangle. Closing the controls and continuously raising the target window keeps the recording clean, which further indicates that the current path is a display capture plus crop.

   Expected behavior: --window <window-id> should capture the selected window independently of its z-order and occlusion.

   Actual behavior: background or occluding windows are captured wherever they overlap the selected window bounds. This makes unattended CLI window recording unreliable unless external automation continuously forces the target to the foreground.

   Reproduction

   1. List targets and note a window ID:

      cap targets --json

   2. Start a detached window recording:

      cap record start --window <window-id> --mode instant --path window-test.cap --fps 30 --detach --json

   3. Leave the selected window in the background, or place another application window over it.

   4. Stop the recording using the returned ID:

      cap record stop --id <recording-id> --json

   5. Inspect window-test.cap/content/output.mp4. The overlapping foreground application is visible inside the target window rectangle.

   6. Repeat with --mode studio; the same behavior occurs, including Cap controls when they overlap the target bounds.

   Additional Context

   • Cap version: Desktop 0.5.9; bundled CLI 0.1.0
   • Operating system, version: macOS 27.0, build 26A5388g
   • Device (optional): Apple Silicon (arm64)
   • Tested target: an Electron window, 1200 × 800
   • cap project validate reports the resulting projects as valid; this is a capture-source issue rather than a finalization/export failure.

   This is consistent with the display-capture-plus-crop implementation described above. The CLI now makes the limitation especially visible because --window is expected to support unattended, window-specific capture.

   👍React with 👍2Reacted by Matthew Don and Kyle Smith

   👀React with 👀1Reacted by Kyle Smith
5. knksmith57 commented on Sep 3, 2026

   

   knksmith57

   on Sep 3, 2026

   More actions

   Also experiencing the same thing and didn't realize this had changed/regressed until after smashing stop on a nearly hour long cap. I moved the target window ~120px left at the beginning of the workshop and... well, that entire session was trashed and had to be completely re-recorded. so that's a bummer.

   ❯ cap --version
   cap 0.1.0
   
   ❯ type -as cap
   cap is /Users/kyle/.local/bin/cap -> /Applications/Cap.app/Contents/MacOS/cap-cli
   
   ❯ plutil -extract 'CFBundleVersion' raw /Applications/Cap.app/Contents/Info.plist
   0.5.9
   
   ❯ system_profiler -json SPSoftwareDataType | jq --raw-output '..|.os_version? // empty'
   macOS 15.7.9 (24G830)
6. Markgatcha

   added a commit that references this issue on Oct 27, 2026

   fix(recording): capture the selected window itself on macOS

   ...

   b3a4b48