PowerShell Kept Blocking New Sessions: When Your Window Grid Doesn't See Non-Agent Windows

The always-on window grid was placing new session windows at 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 I had open for something unrelated.

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 would hand a brand-new session window that exact rectangle and cover the terminal completely.

I noticed it the obvious way: opened a utility terminal to check something, walked away, came back to a Claude session staring back at me where PowerShell used to be. First pass at a fix, I tried teaching the registry to remember PowerShell specifically, tag it as a known exception on adoption, skip 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 I use was going to keep punching through until I hand-enumerated all of them, which isn’t a fix, it’s a todo list that never closes.

The actual problem was that the grid only knew about its own windows. It needed to know about all windows.

So the real 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. That flips the model from “track what I 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: 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.

Same night, closing out that ticket surfaced a second one by accident. I’d asked why /close was still running the full test suite, roughly 6,000 tests, on every pre-close, and that question 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 real 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, just sitting there. I 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, the xdist parallel gate, test tiers, the testmon inner loop, a nightly full run, general hygiene, are still unstarted.

Neither fix was large. But 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, not by bug. The registry wasn’t wrong, it was just answering a narrower question than the one placement actually needed to ask.

dxdev LESSON · paste into your AI coding agent
LESSON: Place Against Live Reality, Not Only Your Own Registry
SOURCE: dxdev.com/blog/2026-09-18_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.