Claude Code and Codex can have real-time conversation via Git

I'm seriously surprised he got as much traction as he did with those projects.

Beads was mostly fine at the beginning, but gastown was just a complete jank-stival

It almost never actually worked. The getting started never got you a project which was correctly configured - and if you did try to fix it... Well, it stopped working a few hours to days later when another vibe delivery crashed the party

Also, just keeping it open on idle - with no interactions - churned through the $100 subscription 5 hour session within roughly 2 hours. Just to reiterate: with no interactions beyond having the mayor open

I dimly remember someone mentioning that he used the users sessions to work on gastown itself. Dunno if that was true or fake news as that was just a random commentors claim - and I already moved on from that experiment by the time I read that.

They can write to their outbox, have it be sent to the other's inbox. A watcher can watch for new messages in the inbox and trigger the other agent to read it. You can have the thread Id of the messages correspond to the session id.

We don't need to reinvent things that Unix provides.

From a cursory look my impression is that it deviates from git too much and therefore I can't use my git knowledge to predict how it will behave. I'm quite rusty on git internals but afair .git/refs/ is great because you can do what you like in there but the downside is that it doesn't hook into the rest of the git structure.

So how does this work with branches, worktrees, etc...? Having a jsonl message log in .git/refs/h5i/msg seems very linear. Presumably you store commit refs in the json obj or context dag, but what if I rebase the branch and the original commits are dropped because they're not referenced anymore? Or say I follow the conversation and want to rewind a few messages and branch from there in a separate worktree, how does that work?

Your repo README does say:

- "It uses dedicated refs, so it doesn’t pollute your working tree or your normal branch graph."

- "Because these are Git objects, they are content-addressed, deduplicated, pushable, fetchable, and survive `git gc`."

- "Because the log lives in refs/h5i/msg, a conversation survives clones, machines, and branches — it travels with h5i share push / pull, and divergent sends from two machines union-merge with no message lost."

Therefore these look like design decisions and it would be nice to understand them better.

My first instinct would be to put most of what you have under .git/refs/h5i/ in a .h5i folder in the repo itself and manage some shadow branches under .git/heads/.h5i/ with multi-parent commits pointing at the context commit as well as the previous h5i message commit along with some hooks to handle rebases etc ... . That way battle hardened git machinery gets used and more importantly to me, I can leverage my existing git knowledge to understand dependencies. That would go against your "it doesn’t pollute your working tree or your normal branch graph" goal but I'm of the "explicit is better than implicit" Python school so I like to have the details exposed as long as I can filter them out easily (or by default).