Thanks for catching this. The diagnosis is correct and the fix is sound. I traced do_capture -> walk_accessibility_tree -> create_tree_walker and confirmed the UrlFilteredWalker decorator engages in the real capture path, and that Skipped(BlockedUrl) drops the whole capture (frame + elements) via the existing result: None gate, which is why your after-numbers go to 0/0. Lifting the matcher into screenpipe_a11y::url_filter so both legs share one implementation is the right call.

Two capture paths still leak after this PR though, both on the pixel side (the a11y text and the focused frame are properly handled now):

1. HD recorder is a third WindowFilters::new call site, still passing &[]. In crates/screenpipe-engine/src/hd_recorder.rs the recorder builds WindowFilters::new(&config.ignored_windows, &config.included_windows, &[]), and HdRecorderConfig has no ignored_urls field at all. So during an HD session, high-fps video of a blocked site is captured unfiltered (the HD leg has no a11y walk, so the decorator never runs there). The struct comment already claims "privacy parity with the event-driven capture loop" for ignored windows, so URL parity is a reasonable expectation it currently misses. Plumbing ignored_urls into HdRecorderConfig (it is built in vision_manager/manager.rs) closes it.

2. URL-only config skips SCK window exclusion. get_excluded_sck_window_ids early-returns empty when both ignore_patterns and include_patterns are empty, without checking ignored_urls. So a user who sets only --ignored-urls (no ignored/included windows) gets no exclusion of a blocked site sitting in an unfocused but visible window: its pixels still land in the full-monitor screenshot. The focused case is fine (the whole frame is dropped via the decorator). One-liner:

if window_filters.ignore_patterns.is_empty()
    && window_filters.include_patterns.is_empty()
    && window_filters.ignored_urls.is_empty()
{
    return Vec::new();
}

Neither is a regression (on main, ignored_urls did nothing at all), so this is already a clear improvement. I am happy to merge as-is and file a follow-up for the HD leg + the guard, or if you want to fold them into this PR that works too. Your call.

thanks for the careful trace — both confirmed and folded into this PR (72c3964), since they're genuine privacy leaks and the fix feels incomplete leaving the pixel side open.

1. HD recorder — plumbed ignored_urls through VisionManagerConfig → HdRecorderConfig → WindowFilters::new, replacing the &[] at the third call site. Mirrors the existing ignored/included-window parity, so the struct's "privacy parity" comment now holds for URLs too.

2. SCK URL-only guard — added && window_filters.ignored_urls.is_empty() to the get_excluded_sck_window_ids early-return, as you suggested. Worth noting why the one-liner is sufficient: once we don't bail, the loop calls is_valid(), which already invokes is_title_suggesting_blocked_url() — so the unfocused blocked window gets excluded by the title heuristic. No extra logic needed.

Neither is a regression (on main ignored_urls did nothing). screenpipe-engine + screenpipe-screen build clean. Ready for another look.