Team Projects
Projects are how a team organizes its knowledge base. Every project in a team workspace has an access level, and every member's reach into it follows their role.
Project access
Every project in a team workspace has an access level that decides who can find it:
| Access | Who can see it | When to use |
|---|---|---|
| Team — default | Everyone in the team, according to their role | Most team work — the open, shared knowledge base |
| Invite-only | Only the teammates you invite to it | Sensitive topics — hiring, contracts, security reviews — or work you want to keep to yourself |
Changing a project's access
Open Settings → Projects. Each project lists its current access underneath its name. Click Edit Access, choose Team or Invite-only, and save.
Access can be changed at any time — it isn't fixed when the project is created.
Choosing who can see an invite-only project
An invite-only project gets a Manage Members button next to Edit Access. Use it to invite specific teammates. Anyone you don't invite can't find or open the project.
An invite-only project with nobody invited is visible only to you. That's the way to keep drafts or scratch work in a team workspace without the rest of the team seeing them.
bm project add --visibility does not work. The CLI accepts workspace, shared, and private and then ignores them — every project is created Team-visible regardless. It is also not possible to read a project's access level back from the CLI. Set access in the app instead, and confirm it there. Tracked in basic-memory#1343.Working with team projects
Once you're part of a team, projects show up everywhere you work:
- In the app — Select the project in the sidebar.
- In your AI assistant (MCP) — your assistant's project list spans every cloud workspace you can access, so it reaches team projects without extra setup.
- In the CLI —
bm project listshows projects across all your workspaces.
Workspace commands
# List the cloud workspaces available to you
bm cloud workspace list
# Set the default workspace for CLI and MCP routing
bm cloud workspace set-default acme
You can also target a specific workspace when creating a project, either from the CLI (--workspace) or from MCP (create_memory_project(workspace="acme")).
Targeting a team project explicitly
If a project name exists in more than one workspace (say, research in both your personal and team workspaces), resolution prefers your default workspace — or asks you to disambiguate. To be explicit, use a workspace-qualified memory URL:
memory://acme/research/architecture-decisions
The form is memory://<workspace-slug>/<project>/<path>. From the CLI, pass --workspace on the command instead.
Bringing existing notes into a team project
When you join (or start) a team, you'll often want to promote work from your personal workspace into the shared one. Cross-workspace transfers are a copy workflow — export from the source, import into the target, verify, then optionally delete the original.
See Copy Content Between Workspaces for the project ZIP, single-note, MCP, and local-sync workflows, along with caveats around wikilinks, permissions, and share links.