User Guide
Everything you need to run Unli Rice, in the order you will need it. Ten sections and a tool reference. If you want what Unli Rice is rather than how to use it, start on the product page.
Contents
1. What Unli Rice is
Unli Rice is a local note log that your AI tools share. Claude, Codex, Cursor, Antigravity — every agent you connect reads and writes into the same log, so you stop re-explaining the same context to each one in turn.
They connect over MCP, the Model Context Protocol: a standard way for an AI tool to reach something outside itself. In practice it means you paste one block of settings into each tool once, and that tool can then read and write your notes. You will see MCP used as shorthand throughout the rest of this guide and inside the app.
The log is append-only: writes add, they do not overwrite, and every write records which agent made it. Removing anything is something only you can do, by hand, and it is covered below. It runs on your Mac, and the notes stay there unless you move them.
2. Set it up
Open Unli Rice for the first time and it asks you one question: which tool do you use? Claude, ChatGPT, Cursor, or something else. Answer it and you get the block for that tool, already filled in. You do not have to go looking for a settings screen, and you can reach the same thing later from the Connect screen if you add another tool.
Then the app waits, and tells you when your tool has actually connected. You do not have to guess whether it worked.
Where the block goes
You paste it in yourself, into a file belonging to that tool. Unli Rice shows you the exact file for the tool you picked, because it is different for every one of them:
- Claude Code —
.mcp.json, in a project folder you choose - Claude Desktop —
~/Library/Application Support/Claude/claude_desktop_config.json - Cursor —
~/.cursor/mcp.json - Antigravity —
.agents/mcp_config.json, in a project folder you choose - Codex / ChatGPT —
~/.codex/config.toml
A leading ~ means your home folder. In Finder, press Cmd + Shift + G and paste the path to go straight there.
There is no single MCP config format, and this trips people up. Four of those five files are JSON, where the block goes inside an mcpServers object alongside any servers already there. Codex / ChatGPT is TOML instead — ~/.codex/config.toml, where the block is a [mcp_servers.unlirice] table. The app gives you the right shape for the tool you picked, so copy the block it shows you rather than one you saw somewhere else. If you add a tool that is not on the list, Unli Rice picks the format from the file extension you point it at.
Unli Rice never opens or edits that file. It hands you a block and you paste it. Whatever is already in there stays exactly as it is, and nothing on your machine is changed on your behalf.
Or point a tool at the folder instead
Some tools read local files rather than speaking MCP. For those there is nothing to configure: Unli Rice keeps a workspace folder at ~/Documents/Unli Rice/ and you point the tool at it. You can pick a different folder on the same screen. If pasting config blocks is not something you want to do, start here.
The one thing that catches everyone: a tool reads its configuration when it starts up. One that was already running will not see Unli Rice until you quit it completely and open it again. If the status on the Connect screen does not change, restart the tool first. If it still does not connect, check that the block landed in the right file, and in the right place inside it — inside the mcpServers object for a JSON file, or as its own [mcp_servers.unlirice] table in config.toml.
3. Tell your agents who you are
An agent that knows nothing about you gives you generic answers and re-asks the same questions. This is where you fix that once instead of at the start of every session. Two separate features, with confusingly similar names.
House Rules — how agents should behave
The instructions every connected assistant reads. Three are built in: Standard Memory, balanced conventions for a shared multi-agent memory; Codebase Memory, aimed at architecture decisions, migrations, verification and handoffs; and Minimalist. Edit one, or import your own.
Choosing a preset never writes to your notes by itself. It is a draft until you apply it. The editor shows the character count and an approximate token count, labelled as an estimate because tokenizers differ between models — these are words every agent pays for in every session, so it is worth seeing the size.
The Profile Builder — who you are and what you are working on
A wizard that turns your situation into the context agents are handed: your name and role, your mission, the persona and tone you want them to use, formatting preferences, the principles you work by, your stack defaults, your dos and don’ts, and a list of your projects with a one-line description and a status each. You can add per-platform overlays too — the built-in ones cover Apple and Web — so rules that only apply to one kind of work stay attached to that work.
Four templates to start from: Studio Standard (the author’s own setup, generalised, and the recommended starting point), Solo Developer, Writer / Researcher, and Minimalist. Take all of a template or the parts that fit.
No personal information about anybody ships with the app. The templates carry placeholders you replace — a name field reading “Founder”, a project called “Flagship App” described as “replace with your own”. The Studio Standard template is the shape of the author’s setup, not its contents. Nothing in Unli Rice knows who you are until you tell it, and what you tell it stays on your Mac.
Guardrails are the part worth the time
Inside the builder, guardrails are hard rules rather than preferences — the things you want refused rather than weighed. The built-in examples give the flavour: never add engagement-maximizing patterns; no ads and no trackers; stay inside the active project’s folder; if a fix has not worked after two attempts, stop and write up what was tried instead of looping on variations.
Write yours the same way. A guardrail phrased as a preference gets traded away against something else the moment an agent finds a reason.
Your first two notes
A brand-new, empty log is seeded once with two short notes tagged guide. They exist because an empty list teaches you nothing about what a note here is for, and because the janitor only proposes a tag once that tag is already in use on a few notes — so on a genuinely empty log it would have nothing to work with and would look broken. They are ordinary notes. Archive them once you have read them; they are seeded once and will not come back.
4. How to think about a note
A note has a title, a body, tags, and links. Link one note to another by writing its title in double brackets — [[Wiki: index]] — and Unli Rice keeps the connection in both directions. A link to a note that does not exist yet is fine; it marks something worth writing.
Every write also carries a source: the name of whoever made it. claude, codex, antigravity, you. This is what makes a shared log readable later, because it separates a conclusion an agent reasoned its way to from a line a machine put there. Two sources belong to the app itself and no agent should borrow them: janitor and ingest.
5. What can and cannot delete
This is the part that surprises people, so it is better stated here than discovered later. The short version: no agent can delete anything. You can.
What agents can do
- Appending never replaces. Adding to a note puts text at the end. Earlier content, including another agent’s, stays where it was.
- Archiving is as close to deleting as an agent gets, and it is reversible. It hides a note from the default listings and nothing more.
- Every note carries its own history. Open the event timeline for any note and you get each change, who made it, and when.
- Structural changes are proposed, not applied. An agent that suspects a duplicate or a contradiction raises a flag for you. Raising a flag changes nothing by itself.
This is not a matter of agents being asked nicely. Deleting is not in the set of things they are able to express: the tools they are given are built from the safe layer, and the code that can remove history lives outside it.
What you can do
You can purge a note, from the app, by hand. It is deliberately yours alone — it never runs on a schedule and no agent and no background job can reach it.
Even then it is gentler than it sounds. Every event belonging to that note is written out in full first, and the whole log is copied to a backup before anything is rewritten, so a purge can be restored and the result is identical to what you had. What a purge genuinely destroys is the log’s continuity — those lines are no longer in the live file — rather than the content itself.
The point of all of it is that you can trust what the log says happened. A record that anything in the system could quietly rewrite is a record you would have to verify some other way.
6. The three layers
Notes are not all the same kind of thing, and knowing which one you are holding is most of reading the log well.
- Raw files. Verbatim copies of whatever was brought in — documents, session transcripts — kept in a folder beside the log. You do not read these day to day: the index entries below point at them, and a recovery snapshot preserves them along with the log.
- Index entries. The
Session:andDoc:notes, one per raw file, written automatically. These are machine-built descriptions, not conclusions. They tell you whether a file is the one you want. If it matters, open the file. - Wiki hubs. Notes titled
Wiki: <topic>, written by a reasoning agent. Each says what exists for a topic and where the real authority is. This is the only layer with judgement in it, which is also the reason it is the layer that goes stale.
Start at the note titled Wiki: index. It exists so you do not have to read a corpus of hundreds to find the four notes that matter.
7. The panes
Notes. Search, read, tag, and open any note’s history. Search is keyword matching over titles, bodies and tags.
Repos and the branch graph. A view of the git repositories you have pointed Unli Rice at: which branches exist, and which commits are on no remote anywhere.
To-Do. Nothing here is stored, and nothing can be ticked off. Every item is computed from the state that makes it true, so an item disappears when the work is genuinely done — push the commits and “on no remote” goes away on its own. It reads each project’s memory.md for a declared next step, and falls back to the last published repository snapshot when it cannot get a live read, which is why an item can be labelled “as of the last snapshot”. A stored checklist drifts from reality the moment someone does the work without ticking the box. Deriving is how this one stays honest.
Trust Center. Read-only checks: whether the log and its folder are writable, which MCP clients have checked in, whether a recovery point exists, and what the background worker is doing. Client check-ins record the client’s name and version, timestamps, the tool name, and whether it succeeded — never tool arguments, and never note content.
Notices. Problems the app found on its own, such as a chosen folder it can no longer reach.
House Rules and the Profile Builder. What connected agents are told about you and how to behave. See telling your agents who you are.
Profiles. Separate note logs, each in its own folder, with one marked as the master. A way to keep unrelated bodies of work apart — not a way to change how agents behave.
Automation. Background work: bringing in documents and sessions from folders you have nominated, and the janitor.
8. The iPhone app
Unli Rice Capture is a satellite, not a second copy of the app. It records audio and transcribes it, and it takes typed notes.
It also mirrors your repositories and your to-do list. The items themselves are read-only — you cannot tick one off or change it from the phone, because they are derived on the Mac from the state of your repositories. What you can do is tap an item and write a note against it: what you type is appended to that project’s note, stamped with the project, the item, and the time. The phone reads the list and writes notes about it. It never edits the list.
The Mac holds the log. The phone syncs its own per-device shard into it, which is what lets both write without either one clobbering the other.
9. Your data
The log is one append-only file with your raw sources beside it. You can point Unli Rice at a different folder for it, and the app tells you which one it currently has open.
Recovery points
A snapshot copies the event log byte for byte, together with your raw files and the small settings belonging to that log, and checksums all of it with SHA-256 so it can be verified later. Restoring never replaces your current log. It appends only the events that are missing and copies only the files that are absent, which keeps the append-only rule intact and means a restore cannot cost you anything you already had.
What the janitor may do
The background janitor can add a tag or raise a flag. That is the whole list. It cannot archive, retitle, merge, or resolve anything. A tag it added is a suggestion — remove it if it is wrong, and it will not put it back. A flag it raised is a proposal waiting for you.
10. When something looks wrong
A tool I connected does not appear. Restart that tool completely so it reloads its configuration, then confirm the block is inside the mcpServers object of the right file. Configuration is read once, when the session starts.
Notes I expected are missing. Confirm which log the app has open. It reports this, and it is the first thing to check rather than the last. A banner about a corpus that is unreachable or stranded means what it says, and it is specific: it names the path, and for a stranded log it tells you how many notes are in it that the log you are on does not have. Nothing has been lost in either case.
The to-do list looks out of date. It is derived, so it is only as fresh as what it derived from. Publish a new repository snapshot, and give any project you care about a memory.md with a next step in it — that is what turns a cached item into a live one.
Nothing is being brought in automatically. Check that background routines are switched on, and that the folders you want scanned have been granted. A folder has to be chosen through the file picker before the app may read it.
11. Tool reference
What a connected agent can do over MCP. Every write takes a source, so the log stays attributable.
Verified against unli-rice@1f49c0f on 2026-09-04.
| Tool | What it does |
|---|---|
search_notes | Keyword search over titles, bodies and tags. Substring matching, not semantic. |
list_notes | Lists notes, most recently updated first. |
get_note | Fetches a single note by id. |
create_note | Creates a note. Always a new one — it never overwrites an existing note. |
append_to_note | Adds content to the end of a note. Never replaces or removes what is already there. |
tag_note | Adds a tag. |
untag_note | Removes a tag. This is how you correct a tag the janitor got wrong. |
archive_note | Hides a note from default listings, with a reason. Reversible, and the closest to deleting that any agent can get. |
unarchive_note | Brings an archived note back. |
flag_for_review | Queues a concern for you — a suspected duplicate, a conflict, a proposed merge. Never applies the change itself. |
pending_reviews | Lists every unresolved flag across all notes, oldest first. |
resolve_review | Marks a flag resolved, once you have decided what to do about it. |
note_history | The immutable event history for one note, oldest first, with attribution and timestamps. |
transaction_log | Raw recent events across the whole log, most recent first — the audit trail. |