---
title: "The Browser Kept Pulling Me Back In"
canonical: https://dxdev.com/blog/2026-06-29_browser-kept-pulling-me-back-in/
datePublished: 2026-06-29
---
# The Browser Kept Pulling Me Back In

Four to ten. That is how many automated work sessions I run at once, and the number stopped making sense the first time a browser window opened somewhere I could not see.

I did not start those browsers. The work did. It opened pages, filled in forms, took screenshots, and clicked through awkward admin pages that had no sensible shortcut. Most of the time, that was good news. If a person does not have to keep opening the same page and clicking the same buttons, the work can keep moving.

But the browser had a habit of failing in ways that landed on me.

Sometimes a window appeared off the edge of the screen, as if someone had set a chair in a room with no door. The work was still happening somewhere, but I could not see it. With several sessions running, one could also land in the same browser as another. Tabs and saved logins would be overwritten quietly. Nothing popped up to say that the work had been lost. It simply disappeared underneath the other session.

The worst version was more personal. A session could reach for the browser I use all day, then ask me to take control. That turned an unattended job into an interruption. I had to arrive in the middle of work I had not watched, with no idea what had already happened or why it now wanted my browser. The whole point was that the work was supposed to carry on without me. Instead, the browser made me the emergency backstop.

For a while, I treated this like a settings problem. I changed a flag, pointed at a different profile, and tried the next option. Each change helped a little, then a different problem appeared. I kept hoping there was one last switch that would make it behave. The cost was not a dramatic bill. It was half days of tweaking and testing, plus the steady irritation of being pulled back into work that was meant to be unattended.

The missed idea was simple: one job using one browser is mostly a setup problem. Many jobs using the same machine is a turn taking problem. I had a fixed group of numbered browser spaces already. I made it that way after separate browser profiles filled the system drive until the machine froze. The fixed group limited how many browsers could exist. It did not decide who got one, or keep two jobs from choosing the same one at the same time.

So I built the missing part: a manager that handed out browser spaces and kept track of them. It used a cross process lock. That sounds heavy, but it simply means two separate jobs must take turns when they reach for the same thing. Like a single key at the front desk, only one person can take it at a time. This stopped two sessions from grabbing the same browser and covering each other's work.

Then I separated those browsers from my own. Each numbered space uses a dedicated copy of the browser, kept away from the one I use for everyday work. That meant an automated session could not quietly wander into my personal browser. It also made saved logins behave more predictably, because each work space always came back to the same browser.

I fixed the part I could see, too. When a browser starts, the manager checks the real screens attached to the machine, leaves out the strip occupied by the taskbar, and puts the windows into a visible grid. It also ignores old remembered window positions, which had been sending windows off screen. If there are more windows than the grid can hold, the extras stack where they are still visible instead of vanishing into empty space.

There was one more ordinary detail that mattered: the saved login. A browser space is matched to the work it needs to do, so the next session can return to the same logged in place instead of starting over. That is not about making a machine feel clever. It is about avoiding the little repeat chores that add up and make a system less useful.

The result is not magic. I still tune it. Right now, the screen is set as a two by two grid so each browser gets a readable quarter of the display. That is a choice I can change in one setting. It belongs there. The important part is that the bigger problem, who gets which browser and what happens when several sessions arrive at once, no longer depends on luck.

I am glad I spent the time. This is load bearing work, which is a plain way of saying many other jobs depend on it. I use it every day. Leaving it unreliable would have added a small tax to everything on top of it, every single day.

The fix wasn't another flag. It was a lock: a fixed pool of numbered browser slots, handed out one at a time through a cross-process lock, so no two of the four to ten sessions running at once could grab the same slot, or reach for my own daily browser, without asking first. Anything you have already patched with a dozen separate settings changes is worth the same question: not which switch is wrong, but who actually decides who gets it next.
