---
title: "The Bot Block That Wasn't, and Seven Sessions Under My Editor"
canonical: https://dxdev.com/blog/2026-09-07_cursor-process-tree-sessions/
datePublished: 2026-09-07
---
I signed in to claude.ai from the agent's browser, got kicked out, and told my agent: "i think they are trying to prevent me from doing this."

The agent's session later includes a web search for the best undetected browser automation tools, comparing stealth browsers.

## What the URL said

The agent's later report on that morning said it "wasn't a bot block." The login URL carried its reason: `reason=elevated_auth` and `auth_kind=device_key_missing`. That is device-bound auth, not fingerprinting.

## The bigger problem under it

The point of the exercise was to get my agent sessions out of Cursor and into browser windows, because the editor extension had frozen on me. I had 8 live sessions in total. The agent reported that three of them, opened in browser windows, loaded clean with no login bounce. It then probed the parent process of all 8.

It listed the process IDs of my 8 live sessions and looked up each parent. Seven were `claude.exe` processes whose parent was `Cursor.exe`. The eighth had a `python.exe` parent. The agent's summary: "closing Cursor will kill them. Measured, not guessed."

Remote Control is a view onto a process running on your machine. So the browser windows would have stayed open and looked fine while talking to nothing.

## What changed

The agent started a detached `claude remote-control` host, launched from PowerShell, whose own parent process was gone. Unlike my 7 Cursor-hosted sessions, closing Cursor would not kill it. New sessions were meant to be spawned through that host from claude.ai/code, once its spawn-mode prompt was answered. Of the 7 Cursor-hosted sessions, the one I was talking to got a handoff seed to carry its task forward. The agent told me the other 6 would die on a Cursor restart, and that this was unavoidable.

The follow-on work became real tools in the repo: a spawn command and a dock app for launching sessions.

## What I did not verify

The 7-of-8 count comes from the parent process probe. Closing Cursor to watch what happened is not in my record of that session. The handoff also ended with a to-do, not a result: answer the spawn-mode prompt, then spawn a fresh session from the browser and confirm it works before trusting the browser as the only surface. That was still open when the session closed.

## Check tomorrow

Before you close an editor or move to a browser, list your live agent processes with their parent process names. On Windows, the probe the agent used was `Get-CimInstance Win32_Process`, selecting `ProcessId`, `ParentProcessId` and `Name`, then looking up each parent's name. Count how many have your editor as the parent. Any non-zero count is the number of sessions that closing the editor will end, however independent their windows look.