The Window Grid Said Slot 4 Was Empty and Buried a PowerShell Terminal

The always-on window grid was placing new session windows into 11 of 11 exact slots, 30px gap per cell, everything snapping into place. Then it started dropping new sessions directly on top of a PowerShell terminal we had open for something unrelated.

What the grid actually knew

The grid tracks slots, not screen contents. Every window it manages gets registered when it’s spawned or adopted: session ID, slot index, bounds. When a new session needs a window, the placement logic asks “which slots are free” by checking that registry, not the actual desktop. A PowerShell window sitting in slot 4 was never registered anywhere, so as far as the grid was concerned, slot 4 was empty. It handed a brand-new session window that exact rectangle and covered the terminal completely.

We noticed it the obvious way. We opened a utility terminal to check something, walked away, and came back to a Claude session staring back at us where PowerShell used to be.

The first fix, and the day it held

First pass, we taught the registry to remember PowerShell specifically. We tagged it as a known exception on adoption and skipped its slot. That held for about a day. Then a Cursor window landed in the same spot and got buried the same way.

The registry approach was reactive. Every new window type we use was going to keep punching through until we hand-enumerated all of them, which is a todo list that never closes. The grid only knew about its own windows, and it needed to know about all windows.

Asking the desktop instead

The fix, tracked in the ticket that had been open since the first PowerShell incident, was to have the placement pass query live window state before committing a slot, not just consult the registry. Before placing a new or adopted session, it now enumerates actual windows on screen, checks their bounds against each candidate slot, and treats any occupied rectangle as blocked, whether or not that window has a session ID attached. Registered or not, agent or not, if something is sitting there, the slot is unavailable. The model flips from “track what we own and place around the rest by luck” to “observe what’s actually on screen and place around that.”

Verification was a live dry-run. We opened a PowerShell window and a Cursor window in two of the eleven slots, spun up new sessions until the grid ran out of free real estate, and watched it route every new window into the remaining slots without ever touching the two occupied ones. Tests went in alongside that commit to cover the occupied-slot detection directly, rather than relying on the dry-run alone.

The second ticket that fell out of closing the first

Same night, closing out that ticket surfaced another one by accident. We had asked why /close was still running the full test suite, roughly 6,000 tests, on every pre-close. That led to a smarter-test-selection plan filed a couple days earlier.

Phase 1 of that plan, a git-mutation-guard hardening pass plus a test-isolation fix, turned out to already be built. An abandoned session from earlier in the week had written it and left it uncommitted in the tree. We reviewed it, ran it standalone (5/5 passing), confirmed it was already covered by a clean full run of all 6,044 tests, and committed it. Phases 2 through 6 are still unstarted: the xdist parallel gate, test tiers, the testmon inner loop, a nightly full run, and general hygiene.

Neither fix was large. The window grid one is the more useful lesson going forward. When a system’s model of “what’s out there” is scoped to only the things it created, every object outside that scope is invisible to it by construction. The registry was correct for the question it answered. Placement needed to ask a wider one.

If an automation places or manages things on a shared surface, check whether it looks at the surface itself or only at a list of what it created.

dxdev LESSON · paste into your AI coding agent
LESSON: Place Against Live Reality, Not Only Your Own Registry
SOURCE: dxdev.com/blog/window-placement-invisible-windows
WHAT HAPPENED: The grid had been successfully snapping managed session windows into 11 fixed slots with 30px gaps. It determined availability solely from its session registry, so unrelated PowerShell and later Cursor windows occupying a slot were absent from its model and were covered by new sessions. A PowerShell-specific registry exception briefly helped but exposed the reactive flaw: every unlisted application would remain vulnerable. The placement pass was changed to enumerate live on-screen windows and block any candidate slot whose rectangle is occupied, regardless of whether the window has a session ID. A live dry run filled the remaining free slots without disturbing PowerShell or Cursor, and direct occupied-slot tests were added.
THE RULE: When a decision depends on the state of a shared environment, observe the live environment at the decision point rather than inferring it only from objects your system created. A registry can supplement that observation, but it must not define the full set of possible occupants.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
      1. Before committing a placement, does the code enumerate current windows and compare each candidate slot's bounds with their bounds?
      2. Can an unregistered application window occupying a slot make that slot unavailable without adding an application-specific exception?
      3. Do automated tests directly cover occupied-slot detection for windows that have no session or registry ID?
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.