Tutorial
Memory & sessions
The point of codel00p is that one session makes the next one better. Here is how a conversation becomes durable memory, and how to pick it back up later.
Capture what it learned
After useful work, the run proposes memory candidates from what happened. Inside the chat, /memory shows the approved memory currently in context. To review the new candidates, open another terminal (or /exit first) and approve the ones worth keeping:
codel00p ...scope memory list
codel00p ...scope memory approve <memory-id>Approved memory is loaded into every future chat automatically. Start a new session later and run /memory to see it already in context, so the agent does not relearn what you just taught it.
Name and resume a session
Every chat is saved under a session id, shown in the banner and via /session. Pass --session-id to give it a stable name, then resume later with the same id:
# start a named session
codel00p ...scope agent chat --session-id refactor-auth --tool-set all
# come back to it tomorrow
codel00p ...scope agent chat --session-id refactor-auth --tool-set allOn resume codel00p prints Resumed conversation with N prior message(s) and continues where you left off. Inside a chat, /sessions lists every saved conversation and /reset starts a fresh one without leaving.
Inspect sessions from outside
You do not need to be in a chat to look at past work:
codel00p ...scope session list
codel00p ...scope session show <session-id>session list shows each conversation with its source, message count, and event count; session show prints the stored records. That is the full loop: chat, let it work, keep the memory, and resume. Next, read Architecture to see how a turn actually executes under the hood.
Note
Sessions and memory live in the SQLite file you pass with --memory-db, scoped to the organization and project flags. The file is yours; nothing is uploaded.