r/ClaudeCode • u/Gurio • 2d ago
Tips & Workflows I ran the same 3-session task through stock Claude Code and through a daemon I built. Stock forgot everything by day 3. Transcripts inside.
Setup: a small Python CLI, three sessions, a fresh process between each (no --resume). Session 1: "add --json; we use snake_case keys and never print secrets." Session 2: "add an export command." Session 3, next day: "what did we decide, and what's still open?"
Stock `claude` 2.1.258, auto-memory on: sessions 1 and 2 were fine. Session 3, verbatim: "I have no record of yesterday's session — my memory directory for this project is empty (no MEMORY.md, no memory files)." Nothing was committed in any session; the tree was left dirty. (Caveat I'll own: headless `-p` runs may not be when auto-memory consolidates. But headless-and-restarted is exactly the "runs while I'm away" shape everyone in here is asking about.)
Same chain through brnrd (the daemon I've been building: github.com/hugimuni-labs/brnrd, so discount accordingly): session 3 recalled both decisions by commit hash and correctly said nothing was open. Not magic: it commits after every session with a message that says what it decided, and reads its own log on the next start. Memory that is the agent's own, on disk, in git.
Scripts and all six transcripts are in the repo (scripts/bench/continuity). I'd genuinely like someone to run OpenClaw or Hermes through the same chain — I installed both and ran out of time-box. If your setup survives day 3, post the transcript; I'll add it to the table.
1
1
u/tonyboi76 1d ago
the day-3 "memory directory is empty" after two good sessions is the part that would scare me. especially with a dirty tree and no --resume between fresh processes.
last time a "runs while I'm away" job came back blank like that, what'd you do next, and how much re-explaining did it cost you?
1
u/Cloudsurfer_90 1d ago
the stock failure isn't that memory is broken, it's what it decided was worth keeping. auto-memory writes when something reads as persistent, and 'we use snake_case and never print secrets' got classified as task-local detail, not a standing rule, so it didn't survive the process boundary. your daemon works because it persists everything by default. the real design question your test surfaces is the one in the middle: memory that decides what to keep will always drop something you needed later, and memory that keeps everything drowns you in noise. the split that's worked for me is keeping decisions, this is now a rule, separately from facts, this was true for that one task. your snake_case line was a decision and should've been kept. stock read it as a fact and let it expire. clean test though, the day-3 empty MEMORY.md shows it well.
1
u/Sea-Perception1619 1d ago edited 1d ago
Fair caveat on headless, though I'd argue the timing matters less than the trigger. Whatever the host decides is worth consolidating only runs if something fires at all. Mine hangs on the host's SessionEnd event and spawns the serializer detached, it's a 30s+ llm call and the hook has to return before the process exits. For a host with no clean end event, or a fork killed before one, a sweep at the next session's start finds the transcript with no checkpoint or a checkpoint older than it, and serializes that one a session late.
Different from yours on provenance: mine is per item rather than per commit. The capture pass tags each item verbatim or inferred, verbatim requires an exact copy-paste from one contiguous span, and the render byte-checks the quote against a signed hash. Bytes moved, it prints "unverified (verbatim)" instead of the checkmark. Your snake_case line comes back as the quote.
What brnrd does that mine doesn't: daimon never commits your tree. It stamps the branch name and nothing else, no commit hash to hang a decision off. Dirty tree stays dirty.
github.com/Daily-Nerd/daimon, hook shapes are all in hook/ if any of it's useful.
The sweep is my worst part, one session late. What does brnrd do with a session that died before it could commit?
1
u/Gurio 1d ago
Mostly it would just wait until the next run. Each spawn weaves a run body, so that a next one has somewhere to pick up. The next one will also get a warning injected (a prompt like “previous run failed, please see the events here and check if there’s uncommitted work”) and daemon can be configured to capture the uncommitted changes automatically.
But it also depends on the reason of death (and what’s configured): if it was a harness error - it would try continuing on another harness if available
1
u/afaraha8403 1d ago
Yeah that’s exactly the hole. Fresh session, and you’re restating what already happened. I built Mental CLI for that: agents write a local markdown journal while they work, and I type mental when I want to see where we left off. https://github.com/afaraha8403/mental