I really need a tool that locks files for editing rather than just one for sending messages. Should the second machine's agent wait its turn until the file is free, or should it create its own branch of the file to merge later? With Loopsy, what we're getting is more like a mailbox system, but in my own setup, the lock would be the right approach in most cases.
I have a single rule listed in CLAUDE.md that just reads, "do not modify child project files from parent context." This is because the parent git repository only contains meta-files and automation, and the agent constantly forgets it during sessions, especially when switching machines. After about ten weeks, I added .sync-conflict-* files to my .syncignore.
For single files we’d need to build the lock key mechanism on top of the Loopsy context store.
> I know I might be reinventing the wheel, but I love that it just works.
Not calling _you_ a learner, just calling out to this -- when teaching people to program I've almost invariably told them to focus on getting something practical working.
I hope that a lot more people get to experience this pattern as a result of LLMs. With enough experimentation I'm excited for what creativity we draw out of people.
Curious how you think about the overlap with something like Tailscale, and where you see Loopsy being strictly better or worse.