A cron-driven Playwright scraper using the WebKit engine produced mysterious audio from the speakers and unexplained borderless white 1280x720 windows floating over other apps, despite the driver being launched with --headless --no-startup-window. The run also hung for 5+ hours on a job expected to take under a minute, keeping the windows on screen. There is no error output — the failure is silent; the only symptoms are the windows, the audio, and the elapsed time.

A CLI tool fails to update its own config file with "EPERM: operation not permitted, rename 'config.json.tmp.XXX' -> 'config.json'" even when running as the file's owner with rw permissions and outside any sandbox. Standard permission checks (ls -l, ownership) show nothing wrong, so the error looks like a sandboxing or ownership issue and sends debugging in the wrong direction.

Internet is crawling (single-digit Mbps or less) and the user blames "the Wi-Fi", but the Wi-Fi link is measurably healthy: strong RSSI, high negotiated PHY rate, and a 2-3ms ping to the default gateway with zero loss. No local process is consuming bandwidth. Standard Wi-Fi troubleshooting (channel changes, band switching, moving closer to the AP) is wasted effort because the bottleneck is entirely on the WAN side. The failure looks like a LAN problem to the user because that is the only part of the path they can see.

A machine swaps to death daily and the browser is suspected, but Activity Monitor / ps only show dozens of anonymous "Helper (Renderer)" processes — there is no CLI mapping from process to tab, so people restart the whole browser blind and the leak comes back within minutes.

A macOS machine intermittently freezes, becomes unresponsive, or has to be force-powered-off, and the user reports it as a crash. Standard checks mislead: `~/Library/Logs/DiagnosticReports/` may contain zero crash reports (bug_type 109), `pmset -g therm` shows no thermal throttling, and Activity Monitor shows nothing obviously wrong after the fact because the evidence is gone once the machine reboots. Per-process RSS also understates the problem badly for multi-process apps — a browser reported as "400 MB" in a sorted process list may actually be 40+ processes totalling 6 GB.

On macOS, a GUI app that was running in fullscreen appears to still be open after being quit or force-quit: Mission Control keeps showing a tile for it in the Spaces bar at the top, often rendered as a solid black thumbnail with the app's name under it. The app is actually fully dead — `ps aux | grep -i <app>` returns nothing, `pgrep` exits 1, and the app is absent from `lsappinfo list` — but the ghost Space persists across Mission Control invocations, making users think the process is stuck.

Editing a config file fails with "EPERM: operation not permitted" on the rename step of an atomic write (tmp file → target), even though `ls -l` shows the user owns the file with write permission. Standard permission debugging (chmod, chown, parent dir perms) finds nothing wrong.

A Mac feels suddenly slow but a single `top` sample shows mostly idle CPU, making the cause look invisible. The slowdown is transient and the obvious tools give misleading readings (top's first sample always reports 0% CPU per process; memory looks "full" but is actually fine).

Browser gets Google's "unusual traffic" reCAPTCHA page constantly (plus the benign f.txt download side effect) even though the browser config looks fine. Easy to misdiagnose as extensions, VPN, or carrier CGNAT when the real cause is the user's own scheduled scrapers (e.g. Google Trends via pytrends, headless Playwright jobs) hitting Google from the same IP, poisoning its reputation for interactive browsing too.

React throws 'Hydration failed because the initial UI does not match what was rendered on the server' or 'Text content does not match. Server: X Client: Y' when using SSR frameworks (Next.js, Remix, Gatsby). This happens when the HTML generated on the server differs from what React generates on the first client-side render. Common triggers: (1) Using Date.now() or new Date() in render — different timestamps on server vs client. (2) Accessing window, document, localStorage, navigator — these don't exist on the server. (3) Conditional rendering based on browser state (window.innerWidth, matchMedia). (4) Random IDs or Math.random() in render output. (5) Browser extensions that modify the DOM before React hydrates. (6) Using typeof window !== 'undefined' incorrectly in render. (7) Different locale/timezone between server and client.