A variable created in project A appearing in B can be work contamination rather than useful sharing. I gave projects separate notebook services and kernels so identical variable names could retain different values. Separate document labels were insufficient; actual execution needed to demonstrate the boundary.
Separate the notebook document from live variables
A notebook file retains code and outputs without storing the entire live Python memory. Two files do not automatically imply two kernels, and copying a document does not clone variables. Document location and process ownership need separate decisions.
Each project runtime owns its notebook service with a project-qualified context key. That service tracks its kernel and execution identity. More than displaying several notebooks in one browser, the meaningful structure is which service and interpreter actually execute them.
Retain execution ownership for outputs and waits
Kernel state includes its key, child process, sockets, ready promise and current execution. A different key is not treated as the same live run. Reply IDs are also compared with the current execution where outputs are handled.
Equal cell names cannot establish output ownership. Late replies, stop and restart can otherwise let earlier results appear in a new screen. Documents and outcomes should remain distinct yet traceable to the execution producing them. Displayed text alone is not current-run success.
Check environment separation and memory separation independently
The notebook service starts its kernel through the project's interpreter. Different prefixes support environment separation, while distinct A and B values support memory separation. Packages and variables are different resources; one observation cannot establish every boundary.
Selecting the same saved login profile does not require sharing a kernel. A web session concerns service authentication, while a Python variable concerns local work execution. Separating useful session sharing from unwanted process sharing allows several projects to use one account without merging their local state.
Stopping one project must leave the other kernel intact
The existing isolation scenario creates equal-name variables and runs two kernels concurrently. It then interrupts a long cell in A while B reads its previous value and completes. This checks that cancellation does not casually destroy another project's execution and memory.
That success does not establish immediate cancellation of every arbitrary program. Kernels, external processes and already processed service effects have different lifetimes. Evidence must identify what stopped and what value the other execution retained. The outcome is stronger evidence than the appearance of a stop button.
Idle release preserves output without preserving variables
The current service can release an idle, nonbusy kernel after its configured interval. It keeps document and output while explaining that variables require execution again. Reducing memory must not imply that the previous live state still exists.
An old visible output therefore cannot prove a variable is present in today's kernel. I read the service, project wiring and existing fixture test without executing user cells or stopping a live kernel. This is not a fresh test of every idle-timing combination either.
Leave an accurate account of what can continue
When reporting a saved notebook, distinguish retained code and output from retained live execution. Copying projects and restarting the app raise the same question. Users need to know what must run again before continuing work.
I separated execution ownership instead of asking users to avoid collisions through different variable names. Familiar names remain convenient while project ownership of results stays explicit. Reports and data processing for multiple customers benefit from the same distinction between useful shared assets and memory that must remain independent.