Forking

Forking copies someone else's published folder into your workspace, where you can edit, extend and republish it without asking anyone. The copy is a plain set of files in your account. It has no ongoing relationship with the original, and there is no way to pull later changes from it.

Fork a folder

Open a published folder at its /s/<token> page and press Fork to My Files. You must be signed in, because the copy has to land in a workspace. Forking applies to whole published folders only; a share link has no fork button.

Where the copy lands:

• At the top level of the workspace you are currently in. In a team workspace the fork belongs to the organization. In your personal workspace it belongs to you. See Personal and Team.

• Under the original name plus (forked). Forking handbook gives you handbook (forked). Fork the same folder twice and the second copy is numbered, handbook (forked) 2, because two root folders cannot share a name.

Rename it straight afterwards if you like. Nothing about the fork depends on the name.

What the copy carries

Three of those need more detail.

Version history does not travel. Your copy's first version is the moment you forked it, and versioning records everything from there. You cannot roll a forked file back to a state that existed only in the author's workspace.

Canvas boards are rewritten. A .canvas board references other files and does not contain them, so a plain copy would point at files in someone else's workspace. The fork rewrites each board's references to the copies in your tree, and a forked board opens with its nodes intact.

What forking does to the original

The original folder is untouched, and the author keeps the only editable copy. Two counters move:

• The share's fork count goes up, which is visible on the community card and feeds its trending score, see Community.

• A fork entry appears in the activity feed, naming you and the folder.

The author cannot revoke a fork. Unpublishing the original leaves every existing fork in place.

Publishing a fork

A fork is yours, so you can publish it with Public Folders like any other root folder. It becomes a separate share with its own URL, its own votes and its own comment thread. Nothing links the two shares, so if your work builds on someone else's, credit them in the folder's README.md; there is no other place for it.

From an agent or the CLI

fork_folder takes the share id, which is the id field from list_community_folders, not the /s/ token from the URL. It needs the community:write scope.

{"shareId":"share-id-123"}

monofile community list --sort trending --limit 5   # prints an id per folder
monofile community fork <shareId>

curl -X POST https://www.monofile.ai/api/tools/fork_folder \
  -H "Authorization: Bearer $MONOFILE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"shareId":"share-id-123"}'

The response tells you where the copy landed and how big it is:

{
  "folderId": "clx456",
  "folderName": "handbook (forked)",
  "fileCount": 12
}

To read a published folder without owning a copy, skip the fork. public_bash runs read-only ls, tree, cat, grep and find over any published folder, and the /s/<token> page offers Download ZIP to anyone, signed in or not.

Next steps