Found while verifying #13. Pre-existing — reproduces identically on origin/main, unrelated to the --zoom work.
Symptom
findmy devices sometimes emits the location as the name and the name as the location:
$ findmy devices --no-log
Home • 3 days ago
Omar's AirPods Max [0 mi]
Home • 6 days ago
Omar's AirPods Pro [0 mi]
NE 36th St, Redmond • 5 hr. ago
Omar's MacBook Pro [7 mi]
Expected (and what the same binary prints on a later run):
Apple Pencil Pro
Home (3 days ago) [0 mi]
Omar's AirPods Max
Home (6 days ago) [0 mi]
findmy device <name> then fails with no device matching "iphone" in sidebar even though the device is listed, because the parsed names are locations.
Not an OCR problem
The OCR is clean in the failing runs — names at x=133, subtitles at x=136, consistently:
213 133 "Omar's MacBook Max"
246 136 'This Mac'
324 133 "Omar's iPad"
353 136 'Home • Now'
431 133 "Omar's iPhone"
464 136 'Home • 1 min. ago'
The row-pairing logic in ParseDevices is what mis-associates them.
Likely contributing factor
macOS 26's floating sidebar is narrower than the panel the parser assumes, so map labels bleed into the sidebar x-band and become spurious row candidates. From the same capture, all at x < 700:
116 625 'NORTHGATE'
321 598 'AKE'
419 660 '5'
484 598 'RIDIAN'
729 595 'tke'
794 663 'Park Arboretum'
That would explain the intermittency: whether it fails depends on what the map happens to be showing beside the sidebar. detectSidebarRight narrows using the tab pill, but evidently not enough here.
people and items have not been observed failing this way, though items does occasionally emit a wrapped location line as a row (Prospect St NW. Washinaton • 3), which may be the same underlying issue.
Environment
macOS 26.6.2 (25G83), findmy built from 1065b27.
🤖 Generated with Claude Code
https://claude.ai/code/session_01VDD6P9ft7DNNbrXpNWvCsk
Found while verifying #13. Pre-existing — reproduces identically on
origin/main, unrelated to the--zoomwork.Symptom
findmy devicessometimes emits the location as the name and the name as the location:Expected (and what the same binary prints on a later run):
findmy device <name>then fails withno device matching "iphone" in sidebareven though the device is listed, because the parsed names are locations.Not an OCR problem
The OCR is clean in the failing runs — names at x=133, subtitles at x=136, consistently:
The row-pairing logic in
ParseDevicesis what mis-associates them.Likely contributing factor
macOS 26's floating sidebar is narrower than the panel the parser assumes, so map labels bleed into the sidebar x-band and become spurious row candidates. From the same capture, all at x < 700:
That would explain the intermittency: whether it fails depends on what the map happens to be showing beside the sidebar.
detectSidebarRightnarrows using the tab pill, but evidently not enough here.peopleanditemshave not been observed failing this way, thoughitemsdoes occasionally emit a wrapped location line as a row (Prospect St NW. Washinaton • 3), which may be the same underlying issue.Environment
macOS 26.6.2 (25G83),
findmybuilt from1065b27.🤖 Generated with Claude Code
https://claude.ai/code/session_01VDD6P9ft7DNNbrXpNWvCsk