Chrome URL attributed from a background window

Bug: website time attributed to a site open in a background Chrome window, not the one I'm actually using

Setup: macOS 26.5.2, Rize 3.0.15, Chrome with 4 profiles and usually 2+ windows open.

Symptom: when a background Chrome window is parked on some site, Rize attributes large blocks of my day to that site — even while the foreground window (and often a different app entirely) is where I'm working. The site then bleeds into AI entry titles, reasoning, project attribution, and billable flags.

Concrete example, July 10: a background window sat on fieldtoreport.com for much of the day. Result — 8 of my 12 entries that day mention Field to Report in the AI title or reasoning, including these (entry IDs in case you can look up server-side):

• Entry 14558572 (3:05–3:44pm MT, 38m, billable): AI title "Review Platform Documentation - Field to Report" — my corrected description reads "Figured out how to grant emma lifetime access to dreamcatcher" (completely different client/project). The day view showed ~82% of the block attributed to Field to Report.

• Entry 14560191 (30m): AI title "Review Landing Page - Field to Report" — actual work per my description: "Troubleshooting loomola issues."

• Entry 14553551 (24m): AI title "Edit Project Documentation - Field to Report" — actual: Vayu Labs content research.

• Morning coding entries (14524640, 14529314) got "…while reviewing updates on Field to Report" appended to the reasoning, though the site was never in the foreground.

Independent corroboration: I run a separate local tool that screenshots the frontmost window every 5 seconds. For July 10 it shows ~14 minutes of genuine foreground fieldtoreport.com use, versus ~2 hours Rize attributed to that site (Rize's website list shows fieldtoreport.com at 2h30m for the week of Jul 10–17). I did do real Field to Report work that day in a different block (~15:30, local dev) — that part was attributed correctly; the problem is only the background-window bleed.

Likely mechanism (hypothesis): the active-site sampling appears to read the URL from a Chrome window that isn't the focused one when multiple windows/profiles are open. I hit an identical bug in my own tooling — AppleScript's front window on Chrome is the browser's internal z-order, which diverges from the macOS-focused (AXMain) window — and fixed it by matching the window by title. Sharing in case it helps.

Repro: 2+ Chrome windows across profiles → park a background window on any distinctive site → work in the other window / other apps → check what the day's entries attribute time to.

Happy to share more data (entry exports, timestamps) if useful.