The main agent Chrome owned its windows, and every one of them was filed as the author’s, so no lane would touch any of them. It was a recurring wrong-Chrome confusion, and this was the root cause.
What the lookup assumed
Window ownership was decided from the Chrome binary. The main agent Chrome runs the author’s binary, but it launches against an agent profile. The lookup only looked at the binary, so each window the agent Chrome owned came back as his.
Resolving on the profile
Ownership now resolves on the profile. The profile tells you whose window it is, and that is the whole fix.
While we were in the launch paths, we also killed the “Restore pages” bubbles at all three of them. We had found 11 of 35 agent profiles carrying crash markers, and those markers are what raise the bubble.
Moving off the editor
We moved the author off a frozen editor extension and onto the browser. The agent Chrome had to be signed into claude.ai first, and it kept getting kicked out. We diagnosed the kick-out as device_key_missing, which is elevated auth, not a bot block.
We also proved that closing the editor kills 7 of 8 live sessions, because they are children of its process. To get them out from under it, we opened three sessions as chromeless Chrome --app windows. We also started a detached claude remote-control host, so new sessions can be spawned from claude.ai/code.
What the outside reviews said
A review that day said to keep the separate agent identity, pilot Stable Chrome with an agent-owned profile, then build identity locking and session lifecycle. The build-ready identity and session lifecycle spec was delivered complete.
We also wrote a brief on undetected browser automation. It recommends chrome-devtools-mcp --autoConnect against the author’s real Chrome, with nodriver replacing Chrome for Testing for unattended work.
Cleaning up the screens
Six sessions now sit on one portrait screen, and the overlap on the browser display is cleared.
AI Skills
Use this lesson with the AI assistant you already use
The main agent Chrome runs the author's own Chrome binary, so a lookup that decided window ownership from the executable path filed every agent window as the author's. No lane would touch windows filed as his, which caused a wrong-Chrome confusion that kept returning.
Paste the prompt, share only the context needed to answer it, and treat the result as a draft for your review. Do not include confidential information or let an AI assistant make changes without your approval.
Optional: for a visual report and saved memory, run /dxdev first.
Don’t have it? Get it at dxdev.com/skills/dxdev. The prompt works without it.
dxdev LESSON · paste into your AI coding agent
LESSON: Resolve Ownership From The Profile Identity, Not From The Shared Executable
SOURCE: dxdev.com/blog/window-addressing-by-identity
WHAT HAPPENED: Window ownership was decided by reading the Chrome binary, on the assumption that the agent Chrome and the author's Chrome were separate installs. In fact the agent Chrome launches the author's binary and is pointed at agent territory only by the profile it runs against. The lookup therefore saw the author's Chrome and filed the agent's windows under the author, so they went unmanaged. Ownership was changed to resolve on the profile. Checking the profiles then showed 11 of 35 agent profiles carried crash markers that cause the Restore pages bubble, and those bubbles were suppressed at all three launch paths. A separate sign-in failure in the agent Chrome was first read as a bot block but turned out to be device_key_missing, an elevated auth identity problem of the same class.
THE RULE: When the same executable can run under more than one identity, key ownership on the identity the process runs as, such as the profile, and never on the program that happens to be running. Before acting on an ownership answer, ask which identity the thing is running against, not which program it is.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
1. Identify every place where ownership or routing is decided from an executable path or binary name, and confirm none of them can be satisfied by two different identities sharing that binary.
2. Launch a window or process from a shared binary under each of your identities and verify the lookup attributes each one to the correct owner rather than to the binary's default owner.
3. When an error looks like a block or a bot check, confirm whether the real cause is a missing or insufficient identity credential before treating it as a detection problem.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.
