[Bug]: Chrome SnapShots omit accessibility data on macOS when window titles differ

Before submitting

• I searched existing issues and did not find a duplicate (checked September 9, 2026).
• I included enough detail to reproduce or investigate the problem.

Area

apps/desktop

Steps to reproduce

1. Enable SnapShots and app text in T3 Code Nightly on macOS, with the requested system permissions granted.
2. Open a page in Google Chrome using a named browser profile.
3. With Chrome frontmost, capture a SnapShot using both Shift keys and send it in a thread.
4. Inspect the captured-window metadata: it contains the app name and window title, but no accessibility field.

Reproduced on multiple sites, including a local web app and X. SnapShots of T3 Code and System Settings included accessibility trees on the same machine.

Expected behavior

Include Chrome's available accessibility tree alongside the screenshot.

Actual behavior

The screenshot succeeds, but accessibility data is silently omitted. The captured window and accessibility window have different titles despite having the same process and bounds.

In a direct inspection of the affected Chrome window (profile label anonymized):

Source	Window title
CoreGraphics capture	Issues · pingdotgg/t3code
Accessibility API	Issues · pingdotgg/t3code - Google Chrome – Profile

Both windows had bounds { x: 0, y: 33, width: 1470, height: 857 } and the same PID.

findAccessibleWindow in apps/desktop/src/snapShot/snapShot.ts requires an exact normalized title match as well as matching bounds. On macOS, the Chrome suffix prevents a match, so the reader returns no accessibility context.

Impact

Major degradation or frequent failure: Chrome SnapShots consistently lacked structured app text in this configuration, although screenshots remained usable.

Version or commit

Reproduced on 0.0.41-nightly.20260908.1387.

The installed 0.0.41-nightly.20260909.1426 bundle was also inspected and retained the same title-matching behavior; an independent end-to-end reproduction on that newer build was not performed.

Environment

• macOS 27.0, build 26A5425a
• Apple Silicon (arm64)
• Google Chrome 152.0.7977.77 (arm64), named profile

Logs or stack traces

Direct matcher/worker test against the installed build:

Exact accessibility title matches: true
Page-only capture title matches: false
Worker with exact accessibility title: hasData=true, format=element-tree, nodes=186

Chrome's internal accessibility dump also contained page elements. Launching Chrome with --force-renderer-accessibility=complete did not resolve the missing Snapshot context.

Workaround

A local patch accepts Chrome's macOS title suffix while retaining the existing bounds checks and ambiguity rejection. Eight focused matcher checks passed, including rejection of unrelated titles, incorrect bounds, and ambiguous matches.

After applying the patch, an actual Chrome SnapShot sent through T3 Code included an element-tree with browser controls and page navigation. The payload reported truncated: true, so this confirms restoration of accessibility capture, not capture of the entire page.

A possible upstream fix is to accommodate this title difference without weakening window identity checks. Related feature implementation: https://github.com/pingdotgg/t3code/pull/8103.

Start in apps/desktop/src/snapShot/snapShot.ts at findAccessibleWindow and inspect how title and bounds matching selects the accessibility window. Run or extend the focused matcher checks described in the issue, including unrelated-title, bounds, and ambiguity cases. Done means Chrome SnapShots retain accessibility data without weakening window identity checks.