Files and Folders

Every file you create lives at one path inside one workspace. That path is the same in the editor, in the assistant and over the API. This page covers how paths work, what the file tree can do, and what happens when you rename, move or delete something.

Paths

A path is workspace-absolute. It starts at /, names every folder on the way down, and ends in the file name.

/notes/2026/kickoff.md
/src/server/index.ts
/designs/hero.html

Folders live in the same tree as files, so a folder can hold files and other folders to any depth. There is no home directory and no drive letter. / is the root of the workspace you are in, and nothing exists above it. Agents, the CLI and the API address files by these same paths, so a path you read in the sidebar can go straight into a tool call.

The name decides the type. notes.md opens in the markdown editor, index.ts in the code editor, board.canvas on a canvas board. Monofile treats a file with no extension as markdown. The full map is in Supported File Types.

The file tree

The sidebar tree is the whole workspace, not a view of one folder.

Publishing and sharing also start here. Make Public on a top-level folder publishes it, and Share on a file creates a secret link. Both are covered in Share Links.

Renaming, and what follows the file

A file has an identity of its own that is separate from its name. Rename it and it is still the same file, so these all follow it:

• Version history and checkpoints. A rename orphans nothing, and the pre-rename versions stay in the file's History.

• Secret share links. A /l/ link keeps working after a rename, and keeps serving the same file.

• Canvas nodes. A board that embeds the file tracks it by identity, so the node keeps rendering.

Two things do change. The path changes, because it is made of the names above it. If the new name has a different extension, the editor changes with it. Monofile re-reads the type from the name, and warns you first when the change would swap one editor for another (.md to .ts, say).

Moving

Drag a row onto a folder to move it, or drop it on empty space in the tree to move it to the root. Monofile refuses two moves. A folder cannot go inside its own descendant, and nothing can move from one workspace to another. To get a file into a different workspace, copy its content across, or share the folder and fork it.

Deleting

Deleting a folder deletes everything under it, recursively. The version history goes with it, so you cannot undo a delete from History, and neither the assistant nor an API client can bring a deleted file back. That is why the assistant asks you to approve a destructive shell command before it runs, and why you can issue an agent key read-only. See Approvals and Scopes.

Getting earlier content back

Monofile keeps every write to a file, so you can restore earlier content:

• Open History from the tab actions menu to browse, preview and restore any earlier version. Restoring is itself a write, so the version you restored from is still there afterwards.

• Monofile keeps the 20 most recent automatic versions per file. A Checkpoint is a named snapshot that is never pruned, and you can take one for a single file or a whole folder subtree from the right-click menu.

How Versioning Works has the details, including what counts as a write.

Next steps