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.

When trying to screenshot, test, or automate interactions with a local HTML file via Playwright (including Playwright MCP), navigating to file:// URLs fails with a security error or the page loads blank. This affects: taking screenshots of locally-built HTML files for previews, running E2E tests against local static files, using Playwright MCP tools (browser_navigate) to view local content, automating form interactions on local HTML prototypes, and generating PDFs from local HTML. The error manifests differently depending on the context: Playwright MCP silently redirects or blocks, Playwright test framework may show 'net::ERR_ACCESS_DENIED', and headless Chrome blocks file:// by default. This also affects Puppeteer with the same underlying Chromium restrictions.

When building single-file web tools, personal dashboards, or local-first applications that don't need a backend server, the question of where to persist state comes up immediately. Options include: localStorage, sessionStorage, IndexedDB, cookies, Cache API, File System Access API, and even embedding state in the URL hash. Each has different size limits, APIs, and tradeoffs. The wrong choice leads to either over-engineering (setting up IndexedDB for 10KB of data) or hitting walls later (localStorage 5MB limit when storing images). This applies to: personal note-taking apps, bookmark managers, habit trackers, configuration tools, code snippet managers, and any tool where data lives on one device in one browser.