The first screenshot of Tabwar came from an automated browser test. It showed a working dashboard, two project workspaces, and a restored copy in the sidebar. The extension could switch from one workspace to another in the same window and back again in that test journey.
The first alpha dashboard, captured during the automated browser test on 15 October 2026. Client A, Research, and the restored copy are test workspaces.
That was progress from the previous installment, when the interaction was still a requirement in a brief. I had rejected separate windows for each workspace. During implementation, I also confirmed that pinned tabs should stay visible across switches and that Tabwar should have a dashboard plus a toolbar popup.
The AI assistant built the alpha around those directions. It was ready for me to install and try. The automated result gave us a starting point; my own browser session would soon give us a different result.
Installing it in my browser
The popup presented a note before enabling switching: Tabwar saves page links and tab order, but switching closes ordinary tabs. Unsaved forms and work inside a page may not return. Pinned tabs stay open.
The installed alpha's toolbar popup before switching is enabled.
That boundary matters for a tab manager. Reopening a URL is different from preserving everything happening inside the page. The notice makes that distinction visible before the first switch; whether it communicates enough still needs review in use.
The dashboard opened with my existing browser tabs available to capture. It showed 22 tabs ready, with an action to give them a workspace name.
The Getting started screen in my installed extension, before creating a workspace. These are my browser tabs, rather than the automated test setup.
My first saved workspace
I captured those tabs as “Tabwar project session.” The dashboard reported “Workspace created” and showed 22 tabs in the active workspace, together with a saved time.
My first saved workspace. Initial capture had reached the interface; switching away and returning was the next behavior to try.
Having the installed interface in front of me also gave me something concrete to judge. The layout looked very similar to what AI had produced for Sitefar: a left sidebar, a breadcrumb at the top, and help and resources near the bottom.
That is not necessarily wrong. Those patterns may work here. But the result felt like a template approach rather than something custom. I still need to think through what to improve in Tabwar's UI. I have not chosen a redesign.
Then I tried switching
I created a new empty workspace and switched between the two a couple of times. My tabs disappeared.
The original workspace, which had shown 22 tabs, now showed one. A message said a workspace switch needed attention. The interface offered “Resume switch” and “Keep current tabs,” and the Recovery tab showed three entries.
The first switching failure I reported from the installed extension. The recovery options are visible; successful recovery has not yet been confirmed.
The interface says the saved source and destination sessions are retained. I still need to find out whether I can recover the missing tabs. The screenshot does not establish what caused the failure, whether the original saved session is intact, or whether the loss is permanent.
What the passing tests had covered
The build record reports passing TypeScript checks, 13 engine tests, a production build, and one integration journey running the actual extension in an isolated Chromium profile. That journey captured a workspace, switched A → B → A, checked persistent pins and repeated activation, restored a snapshot copy, and verified saved links and a real JSON export/import.
It also stopped the actual background worker and reloaded the dashboard. That happened after a completed switch. It did not test killing the worker at every stage of switching. Browser-session ID changes and several failure conditions were exercised through a controlled adapter rather than full browser restoration.
Packaging had already needed a correction: the first CI run built the ZIP but skipped uploading it from the hidden output folder. The assistant found the missing artifact through an API check, fixed the upload configuration, and verified the artifact after a successful rerun.
Those results remain evidence for their specific checks. They did not establish that switching would behave reliably in my browsing session. The failure now needs investigation on its own terms.
Recovery is now a question from actual use
The alpha already contains recovery mechanisms. Before closing source tabs, it saves the outgoing session and records the intended switch. It stages destination tabs before completing replacement. Unique staging addresses help it rediscover a tab if work stops between creating that tab and recording its browser ID; a controlled engine test covers that interruption gap.
Snapshot restoration creates a separate workspace copy. “Keep current tabs” records the visible tabs in a recovery workspace. Those are implemented behaviors with test coverage, but they do not tell me yet whether my missing tabs can be recovered in this case. The staging mechanism is not an established explanation for this bug.
The immediate next step is to attempt recovery and investigate what happened. Stable-browser restart checks, broader interruption testing, and performance measurements also remain unfinished. This is still an alpha, and the UI has open questions of its own.
The first working build has given me a captured workspace, an initial design critique, and a switching failure to investigate. The outcome of recovering those tabs belongs in the next part of the record once it is known.
AI assistance: the assistant implemented and tested the alpha and helped draft this article from repository evidence and my observations. The product decisions and firsthand experiences attributed to me come from my own reports. This manuscript is awaiting my review.
