Why I built a tab manager that can’t phone home

I’m one of those people who always has five or more browser windows open, six hundred tabs and up, at any given time. Not during a crunch. Always. It’s been my steady state for years, and in early 2026 I finally decided it was a problem to solve rather than a personality trait to manage.

Tabs are how I hold context. Articles half-read, tools mid-use, research threads I meant to come back to. Closing a tab feels like losing access, so nothing gets closed. And when I needed something I already had open, I did the thing everyone does: opened a new tab and searched for it again, adding one more to the pile.

I tried the existing tab managers. Every one of them wanted to change how I browse. New workflows, new metaphors, a whole philosophy of productivity I hadn’t asked for. I didn’t want to be reformed. I wanted my tabs saved somewhere findable, so I could close a window without it feeling like a small funeral.

So I built it. First as a personal Edge extension with the deeply imaginative name Edge Tab Saver, later renamed Session Run when it grew into something worth shipping. It’s live on the Chrome Web Store now, with a landing page at session.farm.

one refusal/

The first real decision wasn’t a feature. It was a refusal: the extension would never touch the network.

Session Run has no host permissions, no content scripts, no analytics, no accounts, and no network access at all. It asks for four permissions (tabs, tab groups, storage, and unlimited storage so the archive isn’t capped) and that’s the entire surface. A tab manager sees every URL you have open, and URLs carry more than people think: auth tokens, search queries, the names of things you’re worried about at 2am. The only privacy promise I trust from a solo developer is one the architecture enforces. Session Run can’t leak your data, because there is no code path that sends it anywhere.

This posture also made Chrome Web Store review painless. That part was luck, not planning.

boring on purpose/

The stack is vanilla HTML, CSS and JavaScript on Manifest V3. No framework, no build step. The whole extension is about 2,000 lines of code, and most of that is the dashboard.

For a solo project, every dependency is a future chore. I wanted something I could leave untouched for six months and still understand in an afternoon. There’s also nothing to compile: zip the folder, load it unpacked on any machine, done.

Storage got more thought than the interface did, at least at first. Everything lives in chrome.storage.local, but a naive “one big array of sessions” would make the dashboard slower with every save. So the data model is split: a lightweight index that loads instantly for the session list, and full session objects that load lazily when you expand one. A session card knows it holds 87 tabs across 3 windows long before it loads the tabs themselves.

the escape hatch/

Browser storage is durable right up until it isn’t. A profile reset or a bad sync can wipe years of saved sessions in a second, and I didn’t want a single point of failure. So every session also auto-exports as a markdown file to a folder you choose. One file per session, windows as sections, tabs as links. Readable by a human without any tool, parseable by any AI agent, and importable straight back into the extension if browser storage ever dies.

Getting the folder part right took an actual evaluation. Three options existed. The Downloads API is simple but fires a notification on every save and confines you to the Downloads folder. A native messaging host gives full filesystem access but requires installing a separate script, which is the step where most users quit. The File System Access API lets you pick a folder once, then the extension writes to it silently, with the directory handle persisted in IndexedDB so the permission survives restarts. I went with the third. It’s rare that the cleanest UX option is also the least work, and I remain suspicious of it.

the live view/

Somewhere in the middle of building, the product changed underneath me. Saving sessions turned out to be half the problem. The other half was the six hundred tabs still open.

So the dashboard grew a live view, pinned at the top: every open tab across every window, updating in real time as tabs open, close, and move. From there you can jump to any tab, close duplicates in one click (it keeps one of each), close everything from a domain, or sweep tabs into color-coded browser tab groups.

That view is now why I open the dashboard daily. The archive is insurance. The live view is the product. I didn’t plan that. Daily use decided it, which is the advantage of building the thing you’re the heaviest user of.

graph paper/

The interface is white, black, and one shade of yellow (#FFFF00), with border-radius set to zero everywhere. The rule I wrote down for myself: if it isn’t clickable or alive, it isn’t yellow. I mocked up three visual directions before landing here (a command center, a field of cards, a ledger), and the command center’s discipline won. Its rules got extracted into a small reusable CSS theme that now styles everything under the session.farm name.

Thirteen years of enterprise UX mostly taught me restraint. The dashboard exists for scanning hundreds of tabs, so visual density stays low and nothing decorates.

what it doesn’t do/

No cloud sync. No thumbnails, no AI categorization, no restoring a session as a full window. Some of that is scoped for Session Farm, a premium layer I’ve researched and planned but not started, where local-first stays and cloud and AI arrive as additive layers on top of the same data. Some of it may never happen.

v1 ships what I actually use. Session Run is free, on the Chrome Web Store, and runs on any Chromium browser. If you have a tab problem, you already knew it before this sentence.