With multiple projects, stopping can be more dangerous than starting. The visible project may differ from background work. Earlier I covered retaining a reservation's target. Here I follow resource ownership so stopping one execution does not interrupt another project's tabs and kernel.
Follow a project cursor rather than the selected window
ProjectHost carries workspaceId, profileId and tabId. Although projects use the same real BrowserHost, activeTab, visibleTabs and memory are read through that cursor. Selecting a tab outside the workspace or changing workspace identity is refused. Background selection also avoids taking the person's visible tab and focus.
This does not isolate every login in a separate process. Projects explicitly choosing the same account can share its session. An independent work cursor and shared account session are different choices. Calling the complete arrangement a malicious-code sandbox would obscure the actual ownership boundary that makes a scoped stop possible.
Stopping pages also requires an ownership predicate
StopPages filters for the cursor's workspace, a non-human owner and live contents before calling stop. It does not stop all loading in the visible window, including human tabs and unrelated workspaces. The predicate is part of the behavior, not merely a UI grouping preference.
Contents.stop addresses loading in those page contents. It does not undo requests processed by another server or terminate arbitrary Python code. Page, program and kernel remain different resources beneath a familiar stop command. I follow their separate connections rather than assign universal cleanup behavior to one function with a convenient name.
Bind program identity and notebook to the same runtime
Bootstrap keeps a controller, programRunner and notebook in each project runtime and resolves current through asynchronous project context. Dynamic access then reaches that runtime, rather than whichever global object the visible screen last selected. A program stop callback checks that the current task ID matches the one begun for that program.
The screen taskControl route selects workspaceTask, checks profile and workspace, stops that controller and interrupts its busy notebook. Without that scope check, changing screens could redirect a stop toward another kernel. This establishes the recipient of cancellation; it does not promise that every possible program cooperates instantly with interruption.
Make the unaffected execution the subject of the test
The existing project-isolation test gives two actual Python kernels different variables. A waits longer; B waits and prints with its existing project value. Both start, A receives stop, and B must retain the output B continues=B. The assertion inspects the execution that should remain alive, not only the one asked to stop.
That is stronger for this ownership question than checking A's stopped label alone. It uses an owned Electron profile and substituted web responses, not customer accounts or an assertion of noninterference across every external service. I reviewed the test without launching new kernels or interrupting the original work. Its specific retained-variable result defines the evidence.
Independent work also needs independent failure impact
Multiple project tabs alone do not establish independent execution. Runtime context, page-stop filters, program identity and kernel ownership must line up. A misdirected stop can remain invisible during normal success and interrupt another job at the moment control matters most.
The linked lane package is an independent example of execution-slot ownership and rejecting an old completion. It operates neither a kernel nor Electron. An adaptation must carry ownership down to each actual resource and verify both the stopped side and the side expected to continue. A maker should explain the impact boundary of failure and cancellation as carefully as the ability to start work concurrently.