SIGN IN SIGN UP

Let the user see and edit a bot's memory (#208)

A bot's MEMORY.md rides into every turn's system prompt and its
memory/*.md topic files steer what it believes, yet none of it was
visible anywhere in the UI — the user had to know the workspace path
and open the files by hand to see (or fix) what a bot had decided to
remember.

Three routes expose the files the workspace already owns:
GET /api/bots/:id/memory returns the WHOLE MEMORY.md (not the load
budget's cut — an editor must show everything, with `truncated`
flagging what the prompt loader would drop) plus a name+size listing
of memory/ topics; PUT writes it back, string-checked at the boundary
and capped at 256KB so a runaway paste fails with an explanation; GET
/memory/topics/:name serves one topic read-only. Topic names pass one
strict gate (single plain-markdown path segment, decoded before it is
judged) in both the route and the workspace helper, so no coat of
percent-encoding turns the route into an arbitrary-file read — the
tests plant real files at the traversal targets and prove every
encoding of ../ dies as a 400 before the filesystem is touched.

The Settings panel gets a Memory card in the existing card language:
collapsed by default (most visits never look, and expanding re-reads
so mid-session notes appear), a monospace editor with save + budget
warning, and the topic list opening into a read-only viewer. Keyed by
bot id so switching bots can never show one bot's notes under
another's name.

Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
M
Milind Soni committed
4a9d6540e8d621904d66718e548eee2df347ec10
Parent: ee21f40
Committed by GitHub <noreply@github.com> on 8/17/2026, 8:39:17 PM