Before every change, Otto keeps an encrypted copy of the old state, deduplicated by checksum, and only ever deletes into a trash can. Writing outside your working folder always goes to approval first, at every autonomy level.
Contents
Docs overviewFiles · Filing, versions & deletion
Nine tools, one working folder
Everything Otto does with files runs through one of nine tools. They work in your own working folder — not in a second, separate store.
The nine tools
- View locations
- Shows the folders Otto knows about.
- Search files
- By name or content, across known locations.
- View folder
- Lists the contents of a folder.
- Project map
- A tree overview of a project, with a note when there is too much to show in full.
- Read file
- Text, PDF (with OCR for scans), Word, Excel, PowerPoint, OpenDocument, RTF, EPUB; images are looked at.
- Write file
- Replaces the whole content or creates a new file — always keeps a version of the old state first.
- Create folder
- Creates a new folder.
- Delete file
- Moves the file to Otto’s own trash can, recoverable for thirty days — never final.
- File versions
- Lists earlier states of a file and restores one of them.
Standalone office tools
Otto writes Word, Excel and presentation files with its own code — no installed Office, no account, no cloud. This is also the only way these file types get a version history at all.
The working folder — for writing, not for reading
For WRITING there is a fixed boundary (the “path guard”): allowed are your user folder and the folder you set as the working folder — even if that folder is on an external drive. Key files such as SSH and GPG keys, git hooks, autostart folders and your system’s startup files stay locked at all times, even inside the allowed area. If Otto writes outside that area, it asks first — regardless of the autonomy level and regardless of whether “delete without confirmation” is switched on. For READING this boundary does NOT apply: “read file” has no allowed area and will in principle open any path a task names. A narrower, separate block for a short list of unambiguous secret locations (SSH keys, cloud credentials, `.env`, among others) only kicks in once the current run has already read foreign content — an email, a web page, the screen. If you ask for such a file yourself, directly, you get it unchanged — it is your device.
Known gaps in this documentation build (as of 26 Sept 2026)
- There is no automated test for “view locations” or “file versions”.
- In the Files window, filtering, sorting and resetting the view are without their own test.
Next: Standing orders, schedule & states Back to the overview