One memory: Claude Code's auto memory and the wiki

Claude Code keeps a memory folder per repository on your machine, called auto memory: a MEMORY.md index and one file per memory (user_role.md, feedback_testing.md, ...) that Claude reads at the start of every session and writes as it works (Claude Code's own description). No other agent and no teammate ever reads that folder, so what one session learned stays with it, and the wiki becomes a second memory next to it.

Added in v0.236.0 In a checkout that has an orboto project, the wiki is the one memory. orboto connect and orboto mcp install --session-reporting move the local folder into the project wiki, switch auto memory off for that checkout and archive the folder. They do it without asking and print every step. This page covers what happens, where each file goes, who can read it and how to undo it. The wiki itself is described on Knowledge base for agents.

What connect does

In a checkout with an orboto project, orboto connect (its step "local memory") and orboto mcp install --session-reporting run these four steps in this order:

1. Check the settings file. The local settings file Claude Code reads for the checkout (see Which settings file) must be a JSON object, so a file with comments in it fails, and its folder must take a new file. If not, the run stops here with the reason: nothing is imported and nothing is archived.
2. Import. orboto knowledge import-local moves the folder into the project wiki (see What goes where). Every import prints a receipt line on stderr.
3. Turn auto memory off. "autoMemoryEnabled": false goes into the local settings file. Every other key and array of the file stays, and a second run changes nothing.
4. Archive the folder. It is renamed to <folder>-imported-<UTC time> beside itself, for example memory-imported-20261103T101500Z. Nothing is deleted, Claude Code no longer reads the archive and you can still open it.

A refused or failed entry in step 2 stops the sequence: the folder and the setting stay as they are, the summary names the files, and the next run picks up the rest (see Entries that are refused or fail). If the local file already says "autoMemoryEnabled": true, orboto treats that as a decision of yours. orboto connect and orboto mcp install --session-reporting then leave the file, the folder and the wiki as they are and say so; --auto-memory off overrides the true. orboto knowledge import-local on its own still moves the memory into the wiki in that case, but the folder stays where it is, because Claude Code keeps reading it while auto memory is on.

autoMemoryEnabled is Claude Code's own setting. When it is false, Claude Code does not read from or write to the auto memory folder. orboto writes it into the local settings file and not into the shared .claude/settings.json: the local file is yours alone, Claude Code keeps it out of git and applies it over the shared file, so a teammate who does not use orboto keeps auto memory. The environment variable CLAUDE_CODE_DISABLE_AUTO_MEMORY still outranks the file for one session, in either direction.

Without a project, nothing changes. A checkout with no orboto project gets no setting and no import, and auto memory stays on: the wiki is not that checkout's memory. orboto connect says so in its output.

What goes where

orboto knowledge import-local reads the top-level Markdown files of the memory folder and sends each one through the same routes a person or an agent uses to write knowledge (knowledge add, page create and append-section), as you. The secret check, <private> passages, receipts, embeddings and the session's audit therefore apply as for any other write.

• Who reads what. Sources and the Working agreements page live in the project wiki, so everyone who can read that wiki reads them, and so do external accounts when the wiki is visible to them. Only user_* files and files without a known name or type stay private to you. Look through the folder before the first run, and wrap anything that should not reach the wiki in <private>...</private>: the passage is removed before anything is stored.
• Frontmatter. A file's name becomes the title of its page, else the file name is turned into one (project_release_window.md becomes "Release window"). Its description is placed first in the body. When the name has no prefix, type decides; if either the name or the type says user, the file is a user file.
• Long files. A file over 45,000 bytes is split at line ends into numbered parts. Each part becomes its own source, page or section, with "(part 2 of 3)" in its title.
• Skipped, not failed. MEMORY.md, empty files, files that are not Markdown or not UTF-8 text, folders (only the top level is read) and a file that is private throughout. Hidden files are not listed at all.

orboto knowledge import-local
skipped          MEMORY.md -> - - MEMORY.md is the index of the other entries, not knowledge of its own
imported         project_release_window.md -> source ACME-D41 "Release window"
imported         reference_ci_job_logs.md -> source ACME-D42 "Ci job logs"
imported 2 of 3 entries of /home/you/.claude/projects/-home-you-work-widgets/memory into the ACME wiki with 2 receipts; 0 already imported, 1 skipped, 0 refused, 0 failed
the folder is archived to /home/you/.claude/projects/-home-you-work-widgets/memory-imported-20261103T101500Z (never deleted); `orboto knowledge import-local --path /home/you/.claude/projects/-home-you-work-widgets/memory-imported-20261103T101500Z --dry-run` lists every entry
auto memory is off in /home/you/work/widgets/.claude/settings.local.json (autoMemoryEnabled false) - the wiki is this checkout's one memory; `orboto connect --auto-memory on` turns it back on

Each receipt line goes to stderr and names its undo (orboto knowledge undo <receipt code>). An entry is never imported twice: every page and section ends with a line ref lm-<hash>, built from the file name, the part and the content without its private passages, so a second run reports already_imported. A file you edited after the import counts as a new entry and is imported again.

orboto knowledge import-local --dry-run                # print the plan, write nothing, not even the personal space
orboto knowledge import-local --path /backup/memory    # a folder somewhere else
orboto knowledge import-local --project ACME --json    # name the project yourself, the result as JSON

The command runs in a checkout that has an orboto project, or with --project KEY. Without either it stops with exit code 2. Run on its own in a checkout with a project, it does steps 1 to 4 above, also when --path names that same folder. With another --path, or with --project in a checkout without a project, it imports and archives that folder and leaves the setting alone. The exit code is 0 when every entry landed, was there already or was skipped, and 1 when one was refused or failed.

An agent without the CLI reaches the same function as POST /knowledge/import-local through orboto_api_call; the in-app chat has no local folder to read.

The personal space and who can read it

Added in v0.236.0 The files that stay yours go into a personal space named "Personal memory: <your name>", created by the first import. It is a restricted space with a lock icon.

• Who is a member. You, and the account that creates the space. That is you, or an agent account you created yourself under your own profile (it needs the agent:create-own permission). An agent account that an administrator created for you, or reassigned to you, does not count until you set its owner yourself. The account stores who set its current owner, so no audit retention window changes the answer.
• An existing space gains no member. If the space exists and the importing account is not a member, its personal files are refused with the reason, and the folder stays. If the space does not exist yet, only you or your own agent account creates it. Either way, import with your own login: orboto knowledge import-local.
• Who cannot read it. Teammates, guests and other accounts cannot open the space or its pages, find them in search or in the list of spaces, or see their titles in the receipt list or in an agent's handoff digest. A mention of a teammate in such a page notifies nobody who cannot read it.
• It is never a wiki. Linking it as a project's wiki space, or turning the wiki on for it, is refused with 409 errors.docs.personal_space_not_wiki.
• Who still reaches it, as for every restricted space. A workspace super-admin reads every space. A full backup, a workspace export and the GDPR export include it. An administrator with admin:users:write can issue an API key for an account below their own authority and so act as you or as your agent. The space is no promise of confidentiality against these roles.

Entries that are refused or fail

An entry ends as one of imported, already_imported, planned (dry run), skipped, refused or failed. A refused or failed entry counts as a failure: the exit code is 1, the folder and auto memory stay as they are until every entry is in the wiki, and the summary names the files:

the folder stays where it is and auto memory stays on until every entry is in the wiki; refused: project_hosts.md; failed: none - fix them and run `orboto knowledge import-local` again

• A secret outside a private passage. A file with a secret-shaped value (a key, a token, a password) is refused on your machine and never sent. Take the value out of the file, put it in the credential vault and reference it, or wrap it in <private>...</private>, then run the command again.
• The wiki refuses the write. For example, the personal space does not list the importing account, or the account may not edit that wiki. The entry is refused with the server's reason.
• A server error. The entry is failed and the next run tries it again.
• A request that does not get through (no login, a network error) stops the run with the error. Nothing is archived and auto memory stays on. Batches already sent are in the wiki, and the next run skips them.

Each run imports only what is missing, so repeating the command after a fix is safe.

Which settings file

Claude Code reads the local file .claude/settings.local.json at the root of the git repository, and for a worktree at the root of the main checkout, so every worktree session of the checkout reads the same value. orboto writes it there. Claude Code names the exceptions in its settings documentation: outside a git repository, when the repository root is your home directory, on Windows, or when the repository root or its .git or .claude entry is not owned by your user. orboto follows them:

When orboto cannot place the file, it imports nothing, archives nothing and leaves auto memory on, and says why.

Which folder

The memory folder is, in this order:

1. CLAUDE_MEMORY_DIR, orboto's own override.
2. autoMemoryDirectory from the Claude Code settings (managed, local, shared or user file).
3. <CLAUDE_CONFIG_DIR or ~/.claude>/projects/<project>/memory/, where <project> is the name Claude Code derives from the repository (the main checkout's path, shared by every worktree), or the value of CLAUDE_CODE_PROJECT_DIR_NAME when Claude Code honours it: only beside CLAUDE_CONFIG_DIR, as 1 to 64 letters, digits, hyphens or underscores, and no Windows device name such as con.

When no folder exists at that place, connect says where it looked and why. A checkout without a memory folder still gets auto memory off, since the one-memory rule is about every later session. A folder somewhere else is imported with --path.

Turn auto memory back on

orboto connect --auto-memory on               # writes true, which later runs keep
orboto mcp install --session-reporting --auto-memory on
orboto connect --auto-memory off              # off again, also over a true
orboto mcp uninstall                          # removes the false orboto wrote

orboto mcp uninstall removes a false it finds in the local settings file, so auto memory is on again there. An archived folder is not moved back; copy files out of it if you want Claude Code to read them.

What changes for the agent and the completion check

Added in v0.236.0 With auto memory off, the Stop hook sends autoMemory: "off" with its check. The environment variable CLAUDE_CODE_DISABLE_AUTO_MEMORY wins; otherwise the hook reads the setting the way Claude Code does, highest first: the managed settings files of the machine (managed-settings.json and managed-settings.d/*.json), the local file, the shared file and the user file. Managed settings that reach Claude Code by MDM, the Windows registry or the claude.ai console, and a --settings flag of the running session, are not files the hook can read: it reports what the files say.

• The item is gone. The completion check no longer lists "knowledge written locally, not in the wiki", because there is no local memory to owe the wiki. It also disappears from GET /agents/session/unfinished and from Live.
• An earlier pending write is settled once. A local memory write that was pending before the switch is closed by one knowledge.local_off entry in the knowledge audit log, and the local badge in Admin -> Agents -> Live clears.
• Where auto memory is still on, the item works as before. Its advice now also names orboto knowledge import-local as a way to move the whole folder.
• The agent never asks. Moving local memory is not a destructive action and no change of scope: it prints what it did, every import has a receipt, and the agent keeps the list and the receipts out of its reply. From then on it files durable facts straight into the wiki.

Troubleshooting