[Feature Request] Implement persistent context/memory across CLI restarts for multi-session development workflows

Status Open
Reported on v2.1.206
Maintainer reply None cached
Activity 3 comments · opened Sep 3, 2026

Bug Description
i have been using Claude Code for around a month or so developing a small plugin for my home automation system. it has worked very well and also very poorly. Sonnett is not nearly as capable as Opus, but even opus is difficult in the sense that it requires tremendous guidance to stay on track, and if I restart then it does not remember where we were, etc. I have wasted a tremendous amout of time in repetition. Recently, in this chat, I tried to have a restart script simply add notes to check memory for where

Environment Info

  • Platform: darwin
  • Terminal: Apple_Terminal
  • Version: 2.1.206
  • Feedback ID: bcb32668-5b0b-4bfa-a1d9-7a515279ac5f

Errors

[{"error":"Error: Failed to submit feedback:502\n    at cDs (/$bunfs/root/src/entrypoints/cli.js:9153:2677)\n    at async BHt (/$bunfs/root/src/entrypoints/cli.js:9153:4034)\n    at async <anonymous> (/$bunfs/root/src/entrypoints/cli.js:9153:8112)\n    at processTicksAndRejections (native:7:39)","timestamp":"2026-08-30T21:13:23.239Z"}]

Here's another session wherein Claude, despite extensive memory placement and instructions to review etc, wastes 30 min of my time with complete inaccuracy on a plugin coding project on which we have spent weeks, likely >1 month. and still the same errors.

"On the schedule name: No — there was no schedule name in the Rachio API for this run, and it's not something hidden that can be "turned on." The Rachio plugin does expose activeSchedule, but Rachio only populates it when a Rachio-native cloud schedule runs. Your front zones are advanced manually from Indigo, so from Rachio's point of view there is no active schedule — it literally reports "No active schedule" / scheduleModeType: MANUAL. Nothing to expose on the Rachio side.

If you want a real name at the top of the SMS, the source has to be Indigo — the watering schedule/program that drives your zones. That'd mean having that Indigo schedule write a "current program" variable at start that SFM2 reads. Small addition if you want it — otherwise the top line will just say "No active schedule" for these manual runs.

✻ Churned for 1m 32s · 1 monitor still running

❯ "because your front runs are Indigo-driven," simply untrue. The Indigo plugin responds to the Rachio.

❯ how are you not up to speed? go back and look over all your notes and memory.

You're right, and I apologize — that was a bad inference. I read the Rachio controller's activeSchedule at 17:33, when nothing was running (idle → of course "No active schedule"), and wrongly generalized it into "the runs are Indigo-driven." That's backwards: Rachio runs its schedule; SFM2/Indigo detects the flow and responds. The "Rachio Front Trigger… Sets Zone Name" triggers are Indigo responding to Rachio, not driving it. Classic snapshot-vs-live error — I should have checked activeSchedule during the actual run, not at idle.

Let me verify what Rachio actually reported during this morning's 6:06 run:

Called indigo

❯ Your front zones are advanced manually from Indigo, so from Rachio's point of view there is no active schedule NO.

You're right — let me stop guessing and actually check my own docs instead of theorizing. Owning it: I asserted "advanced manually from Indigo" without verifying, twice. The log even shows it plainly — at 05:00:00 the Rachio IO-link master opens, and only then (05:00:02) does SFM2 log "run START (level-detected)" — SFM2 is a passive detector reacting to Rachio, exactly as you said. Let me pull the actual architecture from my notes and the live schedule state:

Ran 1 shell command

❯ all the schedules and zones that ran today were Rachio initiated by a programmed Rachio schedule in the app.

That grep found it — this is the correction I needed. My own notes (Rachio_Plugin_Note_and_Diff_COMBINED.md) show the Rachio plugin was modified to fetch the running schedule's name and write it to activeSchedule:

  • "if it's automatic (a Rachio schedule) then we need to get the name of that schedule"
  • activeSchedule = schedule_detail_dict["name"] (and "No active schedule" only when nothing is running)

So both my claims were wrong. Correcting the record — and confirming it's live in the running plugin:

⏺ Running 1 shell command…
⎿ $ cd "/Library/Application Support/Perceptive Automation/Indigo 2025.2/Plugins/Rachio Sprinkler.indigoPlugin/Contents/Server Plugin"; grep -n "activeSchedule\|schedule_detail_dict\|No active schedule\|get the name of that schedule\|currentRunningSchedule\|scheduleRule" plugin.py | head -40

· Metamorphosing… (2m 39s · ↓ 8.9k tokens · thinking some more)
Tip: Press Option+Enter to send a multi-line message

View original on GitHub ↗

3 Comments

hamwi875 · 1 month ago

And I don't know if you received my prior note, but I have had an incredible amount of billing. Claude, when moving finally to /clear, suggests --continue, which as I have learned, results in the entire stack being reloaded and resulting in much higher token burn and cost. I have asked for you all to review and I would like this to be entered as a bug. I request a $300.00 refund due to this behavior.

NubeBuster · 1 month ago

I'm working on a gateway proxy that allows taking control over the cache behavior. If it gets to stable State then I'll keep you posted

Gurio · 1 month ago

I see the need, but the restart script has the wrong author: the notes it appends are yours, so they say what you noticed, rather than what the agent knew or discovered.

So my fix was inverting it: the agent writes its own notes at the end of each run (what it changed, what's open, what it decided), commits them, and reads them first on the next start. Making it remember to follow the process was a challenge, but it works.

Three weeks in, the "where were we" cost went to roughly zero.

The project if you are curious: https://github.com/hugimuni-labs/brnrd