How scope is decided

Safe initiative starts with scope. Your assistant should resolve the normal case without making you pick a project every turn, and it should stop for one specific answer when two boundaries are genuinely plausible. Guessing is not autonomy.

The normal case

The folder you're working in decides. It was bound to a project the first time you worked there, and that binding is remembered. Connected clients that use the same validated mapping resolve to the same project without you selecting it again.

That's the whole mechanism, and it's right most of the time.

The resolved scope has several parts:

• the authenticated user;
• personal, team, or automatic account mode;
• the workspace;
• the project, when the request is project-specific;
• the validated folder mapping on a machine that can read the checkout.

Each part narrows what can be read or written. Choosing team mode does not override membership, and naming a project does not grant access to it.

When it isn't obvious

Three situations produce an ambiguous answer:

A folder above several projects. Running from ~/dev/ when each subdirectory is its own project — there's no single right answer.

A brand-new folder. Nothing to resolve yet. It offers to create a project.

A folder that looks like two projects. A monorepo split into several projects, opened at the root.

In all three your agent asks rather than guessing. Answer once and it's remembered.

Personal, team, and automatic mode

Personal mode prefers records that belong to you. Team mode works in the authorized shared workspace. Automatic mode uses the current context and surfaced candidates.

Mode is a routing choice, not an access bypass. A personal session can still read shared project material you are allowed to see when the workflow calls for it; a team view cannot expose someone else's personal transcript.

When the result seems to come from the wrong boundary, ask which account mode, workspace, and project are active before changing data.

Multi-project parents

Initializing from a directory above several known projects can surface its child projects. A request can then target the intended child by its resolved project identity.

Use that only after the parent has been initialized and the child list is known. A folder name that looks right is not enough evidence for a project-scoped write.

Checking or changing it

Ask "what workspace and project am I in?" before a sensitive write or when a result looks wrong. The answer should name both.

When the folder is unbound or ambiguous, tell the assistant which surfaced workspace and project to use. To change the folder's persistent binding, rerun setup from that folder or update the project association in the dashboard.

For a sensitive write, pass or confirm the exact workspace and project rather than relying on an old default. Reads can be retried; a decision or document saved to the wrong project is harder to notice.

Catch a boundary mistake before it becomes memory

You maintain the ContextStream product and a separate client repository. Both contain an auth directory, and both are open in different editor windows. You are about to record why the client uses a shorter token lifetime.

First ask which workspace, project, and folder mapping are active. The useful answer is specific enough to distinguish the client checkout from the product checkout. If it reports the product project, select the surfaced client project for the current request and repair the persistent folder binding before saving the decision.

The same check matters before indexing a confidential repository, creating a shared runbook, or opening a client-specific incident. A correct search result from the wrong project is still the wrong evidence, and a well-written lesson saved to the wrong boundary may never surface when it is needed.

Do not “fix” uncertainty by switching to team mode. Account mode chooses personal or shared context inside an authorized scope; it cannot decide which of two repositories you meant.

Why the wrong scope is worth noticing

Scope decides what surfaces and where new memory goes. Working an hour in the wrong project means an hour of decisions filed somewhere they will not be found. Asking for the resolved scope at the start of a session on an unfamiliar machine is a cheap habit.

If it doesn't work

It keeps asking. The folder has no stable binding. Rerun setup in that folder and choose the intended project.

It resolved to a project I've never heard of. A name match went wrong. Choose the correct surfaced project for the current request, then repair the folder binding through setup or the dashboard.

I want two folders to share a project. Bind both — a project can have several folders, which is how a split frontend and backend stay in one memory.

Team mode still cannot see a record. The record may be personal, in another project, or outside your membership. Mode selects a boundary; it does not widen permissions.

A child project name resolves ambiguously. Use the surfaced project identity rather than guessing from its name, then repair duplicate project records if necessary.

Next

• Workspaces and projects
• Working as a team
• What gets remembered
• How the agent partnership works