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 all

On 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.