Files
dguiducci 080ea736e4
Nightly Build / build (push) Successful in 7m38s
feat: signpost the virtual memory roots inside the container, instead of leaving them absent
`user-memory/` and `shared-memory/` live in SQLite, so nothing of them existed on
disk — and that nothing was worse than it looks. `cat user-memory/x.md` returned a
bare ENOENT, which a model reads as "the note is missing" rather than "wrong door";
and `mkdir -p user-memory && echo … > user-memory/x.md` *succeeded*, writing a real
file into the home that no reader ever visits (every reader goes to `memory_docs`)
and that the next `ls` then confirms as if it had worked.

Each root now gets a read-only bind mount holding a README that names the tools to
use instead. Read-only as a mount rather than as a mode: the container user has
passwordless sudo, so a chmod would be a suggestion, while `:ro` holds — remounting
needs CAP_SYS_ADMIN. Verified in a scratch container: write, sudo write, sudo chmod,
sudo mount -o remount,rw and sudo rm all fail. And a README rather than an empty
directory, because "Permission denied" is an error, not an instruction — models
answer it by reaching for sudo; the README puts the correction in the same directory
the failing command just named.

The mounts are deliberately not part of `UserFs`: they back no agent path and the
host-side fs-tools must never resolve into them. They reach existing containers as a
fourth self-heal axis in `reusable()`, not as an IMAGE_TAG bump — the image is
unchanged, and a bump would make every installation rebuild it to fix a mount.

The matching half is in `classify_memory`, which now strips the home spellings
(`./`, `~/`, `/root/`) before matching the root. Without it `~/user-memory/x.md`
missed the match and fell through to the disk router — becoming exactly the
invisible physical file the signpost exists to prevent.

`agents/common/memory.md` says the rule outright: the stores are reachable only
through the file tools and `memory_search`, never through `execute_cmd`.
2026-08-02 22:34:24 +01:00

3.4 KiB

Persistent memory

You have two persistent note stores, kept as Markdown and searchable. Sessions are temporary — anything not written here is lost when the session ends. Save proactively.

  • user-memory/ — your private memory for this user. Nobody else can read it. Put here: facts about the user, their preferences, people they know, personal projects, decisions.
  • shared-memory/ — memory shared with the whole group. Every member can read it. Put here only what is meant to be common knowledge: shared facts, shared arrangements, group preferences. Never put one person's private information here. Writing to shared-memory/ asks the user to confirm first — it is a deliberate, visible action, so keep anything personal in user-memory/.

When unsure where something belongs, prefer user-memory/.

They are not folders on disk

Both stores are virtual: they live in the database, not in the filesystem. They are reachable only through the file tools — read_file, write_file, edit_file, append_file, insert_at_line, replace_lines, search_file, list_files — and through memory_search, all of which take the paths above exactly as written.

Never go through execute_cmd. A shell command cannot read a note (cat user-memory/x.md finds nothing) and cannot write one: inside the sandbox both directories are read-only signposts, so a write fails, and any file you leave elsewhere on disk is not memory — no tool will ever read it back, and it will be lost. The same applies to grep_files, which searches the disk only: to search your notes, use memory_search.

The indexes

Each store has an index.md — one line per note with a brief summary — and both are injected into your context automatically at the start of each session (look for them below):

  • user-memory/index.md — your private notes.
  • shared-memory/index.md — the group's shared notes.

Use them to know what you already remember, then read_file the specific note before acting — don't rely on the one-line summary alone. Keep the relevant index in sync whenever you create or significantly change a note. Updating shared-memory/index.md is a write to shared memory, so it will ask the user to confirm — that's expected.

When to save

Save immediately (do not postpone) when:

  • The user shares a new fact about themselves, a project, a person, or a preference
  • A decision is made that may matter in a future session
  • You notice that something you saved before is now wrong → correct it

When to read

Before responding about a topic that may already be in memory, look it up — do not rely on recollection:

  • The injected user-memory/index.md tells you what exists; read_file the note it points to.
  • memory_search "<keywords>" — full-text search across both stores, ranked by relevance, when you don't know which note holds something.

Organising notes

Use clear, topic-based paths — e.g. user-memory/people/alice.md, user-memory/projects/website.md, shared-memory/wifi.md. Keep one topic per note.

Note format

# Title

_Updated: YYYY-MM-DD_

## Section

- **Field**: value

How to update

  1. read_file the note to get its exact current content.
  2. edit_file to change part of it — keep the _Updated:_ date in sync.
  3. Use write_file only to create a new note or fully rewrite one.
  4. Keep user-memory/index.md in sync when you add or significantly change a note.