Making projects independent raises a practical question: must every project require another login? I wanted a saved account to be reusable while working materials and execution state remained with each project. Without naming exactly what is shared, it is easy to overstate both convenience and isolation.

Define what choosing the same account means

When several projects choose the same saved profile, they use the same Northstar login session. Existing authentication on the site can be reused, but logout and expiry for that account are shared too. Separate project names do not create separate external account states.

This also differs from importing a Chrome account or its cookies. That connector was removed; the current flow has the person sign in directly inside a normal Northstar profile. Historical connector documents are not instructions for the present system. I checked both the owner of the shared session and the version of the implementation.

Separate shared sessions from project-owned material

Tabs, bound execution targets, selected attachments and notebook assets belong to their projects. Python processes, Jupyter variables, local packages, edited plugin definitions, schedules and result records do as well. Reusing a login cannot justify replacing those with one global last-used value.

For example, attaching material in one project must not automatically insert it into another project's run. Entering a site with the same account differs from selecting the material for this request. The more convenient account reuse becomes, the more clearly the current execution's data boundary needs to remain visible.

Respect an intentionally unassigned account

Account selection is optional. Quietly connecting an unassigned tab to a default or recent login could begin work under an identity the person did not choose. Unassigned keeps the meaning of a separate empty session. A person can sign in directly or select a saved account later; absence of a selection is already a valid state.

A project can list several saved accounts for one platform, but that does not make one tab use all of them simultaneously. An actual tab needs a particular session connection. Separating the accounts available to a project from the account used by this tab makes the selection interface easier to understand.

A displayed label is not live authentication proof

Reading a name in the account catalog cannot establish that a site's authentication remains valid. Discovering a login trace, obtaining a display name and observing current authentication are distinct. Letting a person supply a label when no header can be observed is also different from automatically identifying the exact account.

If the page asks for human verification or reauthentication before execution, that state needs a handoff. A stored account is not a reason to ignore it or export credentials into another profile. Convenient retention of a normal login session is different from bypassing a site's expiry policy.

Copy a project without cloning live execution

Copying creates new tabs and a working folder, notebook documents and settings. It can retain the account connection, but not a live process or kernel variables. Copied reservations remain paused so the new workspace does not immediately perform the same external actions.

Saying copy everything without these distinctions can lead someone to expect completed work to run again or live variables to carry across. I needed an explicit list of what remains linked and what is newly created. Shared login is one part of copying, not a promise to clone an entire running execution.

Explain the actual extent of independence

Brand-specific workspaces sharing one external account can still share service limits and logout effects. Conversely, choosing different accounts does not create complete isolation of the host disk or operating-system permissions. I do not describe project execution boundaries as a security sandbox or a guarantee of separate identities on every service.

The evidence is the current account/project connection code and historical owned-environment tests for shared sessions, unassigned isolation and separated kernels. I did not log actual accounts out again for this article. An adopter should be able to explain both the shared resource and its shared effects. Account convenience and the conditions protecting work belong in the same description.