4 hours ago, johner said:

Hi @Joly0

Sorry, I do accept, I let Claude and Codex do near all the work now, I have a reasonably good set of processes and controls, and this was a gap. It's working through merging and responding now.

Currently I have a private repo with significantly more content such as test harness, tools, build scripts etc. I only push what is needed to release where I can as there is a lot of noise other wise - Including hiding the multitude of commits, so I was getting it to 'batch up' for release. I've got it to recreate the sub-commits going forward.

Thanks for your submission, it's appreciated.

Thanks

John

Thanks, appreciate it. Also appreciate including me and the commits i did in the git history and as a contributor 😄

You should still look at that assets folder, the files in there are... hideous 😅 Still assume something regarding minification of those javascript files, not sure if that is actually needed, imo just bloats the commits

On 10/16/2026 at 3:57 AM, Marcin M said:

Hi Tere,

First of all, thanks for this plugin, it is awesome! I use it everyday and I understand it is a work in progress so I wanted to contibute with some ideas as it is very prone to storage failures, crashes and session mishandling. I had to recover multiple times and lost some sessions as they were not baked in time to be persistent. With little help from Ai to analyse the setup construct, here are my suggestions for concideration:

1. Re-register untracked homes automatically. The scheduled-bake and reconcile loops should discover homes from the persistence directory and the config, not only from manifest entities. A home with layers on disk but no manifest entry should get its entity rebuilt on the first supervisor tick, which is what the boot notification already claims happens.

2. Make the manifest survive a bad shutdown. Keep a copy of the manifest on a durable path or inside each baked layer, and rebuild it from the layers when the flash copy is empty or unparsable. Today one lost file silently disables every safety net.

3. Verify every bake after writing. Re-read the delta from flash, check size and the squashfs header, and only then record it. A zero-byte result should be deleted and retried, never left in the directory.

4. Skip or quarantine unmountable layers instead of failing the stack. One empty file should not push the whole home onto tmpfs. Log which layer failed and why.

5. Never report a no-op bake as success. "Skipped, empty" while the home is on the tmpfs fallback, and "busy" with exit code 2, must surface as a warning in the UI, not a green tick.

6. Refuse to run a workspace on the tmpfs fallback without a visible warning. The user should know that everything written in that state will be lost.

7. Default the writable layer to disk when the storage path is durable, and recommend moving storage off the USB stick on first run. RAM-backed homes should be an explicit choice with a clear warning, not the default.

I was also unable to change from ZRAM to disk, the move has failed. "Writable layer = Disk" can never complete on a home that contains any Claude Code transcript, because the post-bake wipe protects .claude/projects/* while the switch demands an empty upper. The switch should treat files proven identical to a baked layer as safe to drop, or move them along with the directory skeleton.

I hope this will help to make it even better!

thank you! I'm trying hard to move away from squashfs, so it only is used now for USB based home/agents, with internal boot I hope we won't need it if people have moved. Yes the migration has had a few issues, I worked through a numner with Claude, I'll get Fable on your feed back and get codex to double check. Thanks for your patience - i run the plugin on two unraid machines, with agents spread across them, talking to each other - it's fun watching them work together.