Copy Content Between Workspaces

You'll often want to promote work from your personal workspace into a team workspace, or pull team content back into a personal one. Today, this is a copy-then-(optionally)-delete workflow rather than an atomic move — you export from the source, import into the target, verify, and only then remove the original if you wanted a true move.

Before you start

A few things to know about any cross-workspace copy:

• You need read access to the source project and write access (editor or owner) to the target project.
• Imported content takes on the target's permissions. It picks up the target workspace's project visibility, sharing rules, and member access. Source-side permissions don't follow it.
• Share links don't follow content. Existing Shared Notes links live on the original. If you want a shared link in the new location, create one there after importing.
• Wikilinks are preserved as text. A [[Wiki Link]] only resolves in the target workspace if the linked note is also present there. For best results, copy linked notes together so the graph stays intact.
• Verify before you delete. Treat the source as a backup until you've confirmed the imported content looks right in the target.

Copy a whole project

The safest workflow for project-sized content. You'll end up with a clean copy in the target workspace with all folders and notes intact.

Copy a single note or small batch

For one note or a handful, the simplest path is download + upload.

Copy with MCP

MCP doesn't expose an atomic cross-project or cross-workspace move. Express it as read → write → (optionally) delete instead. Your AI assistant can drive this for you, or you can run the tools directly.

read_note("source note", project="source-project")
write_note("Note Title", "<content from read_note>", "target-folder", project="target-project")
delete_note("source note", project="source-project")   # optional, only after verifying

A few notes on this pattern:

• Pass project on each call so the read and write hit the right place. In a team setup, use a project-prefixed permalink or workspace-qualified routing to be unambiguous.
• For many notes, loop the read/write pair — there's no batch move, but the pattern is straightforward to script.
• Don't delete_note until the new copy is in place and verified. Treat this as copy-then-optional-delete, never as a transactional move.

See the MCP Tools Reference for full parameter details on each tool.

Copy via local sync (power-user)

If both projects already have local sync set up, you can move files in the filesystem and let bisync push them up:

1. Run bm cloud bisync for both projects so each is up to date locally.
2. In your file manager (or with cp -r), copy the notes or folder from the source project's local path into the target project's local path.
3. Run bm cloud bisync --name <target-project> to push the new files to the target workspace.
4. Verify in the app, then delete from the source side and bisync again.

This is the fastest option when you have lots of notes and both projects already sync to your machine.

What about renaming or restructuring?

Within a single workspace, you can rename and move notes and folders freely from the app or with move_note. Cross-workspace, do the copy first, then reorganize on the target side.

Related

• Teams — workspaces, roles, and project sharing
• Web App — projects, downloads, and imports
• Cloud Sync — bidirectional sync setup
• Shared Notes — public links for individual notes
• MCP Tools Reference — read_note, write_note, delete_note