I wanted to reuse a well-prepared workspace for new work. Carrying its live Python process and variables along would make the new project inherit execution state it did not create. I treated copying as a decision about what may be inherited and what must begin afresh, rather than merely a way to multiply folders.
Keep an incomplete copy unavailable for execution
Copying prepares the source runtime, requests notebook flushing and draft capture, and creates a new project identity. The new workspace remains copy-pending while its pieces are prepared. That prevents partially copied documents and settings from being treated as a complete execution environment. Original and peer runtimes keep their ownership.
Requesting draft capture does not prove preservation of every unsaved state on every service. It prepares material the capture route can support. Capture coverage and copy completion are separate claims: successful folder copying cannot restore a state that was never captured in the first place.
Reconnect familiar documents through new identities
Each source tab receives a new identifier, and retained memory references are mapped to the new identities. Unassigned accounts get new empty profiles; deliberately selected saved accounts may continue referring to the shared session. Retaining an account connection is not the same operation as duplicating cookie files into a new folder.
New tabs carry layout information such as address, title and pinned state. Their changed identities still require the new project context for subsequent work. Continuing to operate the original tab because the copy looks familiar would defeat isolation. Reconnecting relationships matters as much as carrying over documents.
Copy the notebook document separately from kernel memory
The notebook document is encoded and imported through the target service. Import refuses an executing target, shuts down its kernel and saves the decoded document. There is no route for handing over the source process handle or global Python variables. A saved document does not imply a live copy of its earlier memory.
Asset copying excludes the notebook file itself, runtime folders, interpreter state, package cache and previous-history entries. The document uses its dedicated import path while runtime intermediates stay out of ordinary asset transfer. Defining exclusions prevents remnants of an earlier run from looking like new execution evidence.
Package copying is not complete environment portability
The target receives a new Python virtual environment. On the current Windows path, project-local installed packages are copied into it. This shares no live kernel and retains the architecture that can read common base dependencies. Carrying package files is not proof of equivalent environments across operating systems.
Native extensions, dependency conflicts and settings pointing to outside files need separate checks. Workspace copying filters some repositories, large dependency folders and authentication-storage files, but that filter is not a universal secret scrubber. Publishing a copy or moving it to another machine requires a different review from local workspace reuse.
Check that assets survive while live variables do not
The existing isolation scenario imports a source-created local package and reads an input file from the copied project. It checks the new environment prefix and asserts that a variable created in the source kernel is absent from the copied globals. Asset reuse and fresh memory are verified together rather than inferred from the copy button.
This article explains the implementation using that test code and historical QA evidence. It does not copy the current user workspace or rerun the original application tests. Owned fixtures establish those specific conditions, not exhaustive portability of all packages, documents or external services.
Do not leave a failed copy looking ready to run
A copying error enters cleanup for the new controller, kernel, reservations and workspace. The original and peer executions are outside that cleanup scope. If cleanup also fails, both errors are reported. Inert partial files may remain for recovery, but the code aims to avoid exposing an incomplete copy as an executable project.
Completion therefore means more than an increased folder count. Identity mapping, material preparation and state persistence must settle before the copy becomes usable. I see workspace copying as preparing a verifiable new starting point rather than inheriting an entire previous execution. Paused copied reservations deserve their own closer examination.