--- title: "Why our automated jobs kept opening browsers on top of each other" canonical: https://dxdev.com/everyday-ai/browser-kept-pulling-me-back-in/ datePublished: 2026-06-29 --- Four to ten. That is how many automated work sessions we run at once, and the number stopped making sense the first time a browser window opened somewhere we could not see. We 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 keeps moving. But the browser kept failing in ways that landed on us. ## Windows in a room with no door Sometimes a window appeared off the edge of the screen, like a chair set in a room with no door. The work was still happening somewhere, but we could not see it. With several sessions running, one could also land in the same browser as another. Tabs and saved logins were overwritten without any warning. Nothing popped up to say the work had been lost. It just disappeared underneath the other session. The worst version was more personal. A session could reach for the browser we use all day, then ask us to take control. That turned an unattended job into an interruption. We had to arrive in the middle of work we had not watched, with no idea what had already happened or why it now wanted our browser. The work was supposed to carry on without us. Instead, the browser made us the emergency backstop. ## Months of switches For a while we treated this as a settings problem. We changed a flag, pointed at a different profile, and tried the next option. Each change helped a little, then a different problem appeared. We kept hoping there was one last switch that would make it behave. The cost was half days of tweaking and testing, plus the steady irritation of being pulled back into work that was meant to run on its own. What we had missed was simple. One job using one browser is mostly a setup problem. Many jobs using the same machine is a turn taking problem. We already had a fixed group of numbered browser spaces. We 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 stop two jobs from choosing the same one at the same time. ## A manager that hands out the spaces So we built the missing part: a [manager that hands out browser spaces](/blog/stopped-babysitting-the-browser-then-built-the-missing-part/) and keeps track of them. It uses 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 hold it at a time. This stopped two sessions from grabbing the same browser and covering each other's work. Then we separated those browsers from our own. Each numbered space uses a dedicated copy of the browser, kept away from the one we use for everyday work. An automated session can no longer wander into our personal browser. Saved logins also behave more predictably, because each work space always comes back to the same browser. We fixed the part we could see, too. When a browser starts, the manager checks the real screens attached to the machine, leaves out the strip taken by the taskbar, and puts the windows into a visible grid. It 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. One more ordinary detail mattered: the saved login. A browser space is matched to the work it needs to do, so the next session returns to the same logged in place instead of starting over. That avoids the little repeat chores that add up and make a system less useful. ## What we still tune Right now the screen is set as a two by two grid, so each browser gets a readable quarter of the display. We can change that in one setting, and that is where it belongs. The bigger problem, who gets which browser and what happens when several sessions arrive at once, no longer depends on luck. We are glad we spent the time. This is load bearing work, which is a plain way of saying many other jobs depend on it. We use it every day. Leaving it unreliable would have added a small tax to everything built on top of it, every single day. When several automated jobs share one machine, ask who decides which job gets which browser, not which setting is wrong.