DEV Community: Christian Sitte

Eight Grok bots in a Claude Code fleet, and no API between them

Christian Sitte — Fri, 06 Nov 2026 19:02:29 +0000

How bots from another vendor joined a fleet of Claude Code sessions through a shared folder — and what six weeks of that measured.

In August I wrote about the bridge my Claude Code sessions use to talk to each other: a shared folder of write-once files, one polling script per session that wakes it when something arrives. Since then the fleet has grown a second kind of member. Eight of the participants are not Claude sessions at all. They are Grok bots, each paired with the Claude session of the same project — one reviews code, one answers questions about a mailbox, one looks after a server.

There is no API between Grok and Claude here, no SDK, no adapter. The bots reach the same Google Drive folder through a cloud connector (later some through rclone), and they list, read and write files. That turned out to be enough.

Why it needed no code

The protocol is a file format. A message is a Markdown file with a short header (from, to, sets-owner, sets-status) and a filename that starts with a UTC timestamp. Nothing is ever edited in place, and thread state is derived by folding the files. A file format does not know what process wrote it.

What a bot does not have is everything around the format: no shell, so none of the recipes work; possibly no clock; no watcher, so nothing wakes it; and no start ritual, so it never folds its own threads. The protocol needed no change. What it needed was a different instruction — the same rules, written for a reader who can only read and write files. And it needed the rest of the fleet to cover the two gaps.

1. The clock we feared was 4 seconds off

Ordering depends on the timestamp in the filename, and a stamp from the future wins every fold until real time catches up. That had already inverted threads twice before any bot joined. So the instruction spends a whole section on time: use a real clock if you have one, ask a human otherwise, never guess.

The first bot's first message came from a real date -u in its environment and was 4 seconds off the file's write time on the drive. Checked, not believed.

What went wrong instead was a filename. Two days after the first bot joined, one named a file 20260926T… — no dashes. That sorts after every correctly written name and wins every fold, exactly like a stamp from the future. The bot had not invented the form. It had copied it from an in-reply-to field that one of my own sessions had written in a hurry.

A reader that cannot run your rule reproduces the nearest example, and it can see every example in the folder, including the careless ones. We fixed the example, and the start scan now reports any name in that form, so a slip is seen the same day.

2. Five acks in two minutes

A day later, one probe message drew five acknowledgements in two minutes. Two bots both had delivery; each wake-up was acknowledged, and each acknowledgement was a wake-up for the other. Every session with a watcher read five deliveries carrying zero information.

The fix was one sentence in the instruction, not a line of code: an ack goes to the sender only, and nobody answers an ack. It has held since.

3. A 200 is not a run

A bot is never woken by itself, so a small delivery service watches the folder on its behalf and POSTs every message addressed to it to the endpoint that starts the bot. The service runs the same addressing rules as the session watchers — token-exact to: matching, and a sets-owner handover wakes the new owner even when nobody wrote it into to:.

One day a bot's usage quota ran out. Every delivery that day came back HTTP 200 with a success body — eight of them — and the bot did nothing. The status code measured the endpoint, not the recipient.

So a dead recipient is now detected by silence: deliveries that arrived, weighed against the bot's own messages. Over a hundred deliveries, a live bot answered within 30 seconds to 30 minutes. Two unanswered wake-ups that handed the bot a thread, older than two hours, turn it red on the fleet's dashboard. One unanswered wake-up is normal; not every message needs a reply.

4. Overload is where messages get lost

Over 252 deliveries on one machine, three first attempts failed with an overload status (400, 429 or 5xx). The single retry after 45 seconds caught one. The bots found the other two by themselves, after 2 and 4 days — at their next wake-up for something unrelated.

That is the property worth knowing about a participant without initiative: it does not poll. If the wake-up fails, the message waits for the next one, however long that takes. The service in our dashboard now adds a late retry after 15 minutes for overload codes. The standalone script in the repository still retries once, because it runs inside the watcher's hook and a fifteen-minute sleep there would hold up everyone else; the docs say so.

5. Nobody folds for it

A session runs a start scan that lists the threads it owns. A bot never does. So a thread handed to a bot falls through every net — no push if the delivery fails, no fold ever — and from the outside it looks as if someone is on it, because the owner field is filled in.

The coordinating session therefore folds on the bots' behalf: one environment variable names the ids it stands in for, and its start scan lists their threads with waiting times. It is the same mechanism we already used for the one participant who never folds either — the human.

What did not happen

No bot ever edited or deleted a message. No conflict copy appeared in the sync folder. Write-once held for writers that never saw the reasoning behind it, because the instruction states the rule plainly and first, and gives the one thing the author may still fix — a wrong filename, by renaming — an explicit procedure.

Where it stops

A bot behind a connector is a participant with high latency and no initiative. It is a good shape for a reviewer or a second opinion and the wrong shape for anything on a critical path. If its answer gates your work, expect hours, not seconds, unless the delivery service runs and its endpoint is known to execute what it accepts.

The code

The instruction the bots read (in English, without our names), the operator's side, and every number above are in docs/participants-without-shell.md at https://github.com/csitte/claude-session-bridge. The rest of the repository is the same as in August: protocol, watcher, launcher, MIT, Windows-first.

If you run agents from more than one vendor and they need to hand work to each other, try the folder before you try a framework. Anything that can write a file can take part.

A running session is not a reachable session

Christian Sitte — Fri, 14 Aug 2026 19:36:51 +0000

Six weeks of running ~15 Claude Code sessions across two machines, and the three things that actually broke.

I run a fleet of long-lived Claude Code sessions — one per project, two machines. They need to hand work to each other: "the schema changed, the docs session has to follow." Doing that by carrying messages myself does not scale past about three sessions.

What we ended up with is deliberately boring: a shared folder of write-once files. Every message is a new file named with a UTC timestamp. Nothing is ever edited in place, so two writers can never collide, and a cloud-sync folder becomes a safe transport — sync engines produce conflict copies when two devices edit the same file, which here cannot happen. Thread state (owner, status) is not stored anywhere; it is derived by folding the files and taking the latest one that sets it.

On top sits one polling script per session that turns a new message into a notification and wakes the session. That part is pure latency reduction: if it dies, delivery degrades to a scan at session start instead of breaking.

The interesting part is not the design. It is what went wrong.

1. A running session is not a reachable session

The watcher is armed by the session itself, on its first turn, following an instruction in its project memory. Our launcher restarted every session after a reboot with --continue and no prompt — which restores the session but runs zero turns. So the instruction never executed.

Measured after one restart: 12 sessions running, 1 watcher armed. Every window looked healthy. The push layer had quietly come to depend on the exact hand movement it was built to abolish, and we only found it by counting processes.

The fix is three lines — the launcher appends a small start prompt so exactly one turn happens per session. The general form of the lesson: if a capability depends on "someone will do X at session start", it dies silently at every cold start. Wire it into the thing that performs the start. And fence that prompt in — ours says, in effect, run only the start ritual, begin no task, change no file, send nothing — or a fleet of sessions will helpfully start working unattended.

There is a second form of this, which surfaced a day after I published — prompted by a comment on the upstream issue, from someone running a dozen autonomous loops over a shared append-only log. His version: a queue's length is not a delivery signal. Nothing in a log distinguishes "about to be processed" from "nothing is coming to collect this."

It reproduced here within the hour, and not where I expected. The mechanism was working this time. One thread had been handed off that morning — ball passed, owner set, the freshest activity in the whole index — to a session that was not running and had no watcher. Undeliverable until someone starts it by hand, with nothing anywhere indicating that. The signal existed the whole time: each watcher is an OS process, so an inventory of them answers "is anything armed to receive this" per participant. Nobody ran it, because the protocol document that senders actually read described the transport and the rituals but never mentioned that reachability was checkable at all — it pointed at a separate operations doc. The fix was one line in the mitigations list, not a mechanism. A diagnostic nobody is told about is not a signal.

2. Never type a timestamp

Files sort by the UTC timestamp in their name. Our recipe generated the filename and left the human-readable date: field inside the file to be typed by hand.

Measured after a few weeks: 92 of 407 messages carried a field that did not match their own filename — zeroed times, rounded minutes, local time with a Z appended. Twice that inverted a thread's fold: a closed thread read as open for half a day.

The fix was not discipline, it was removing the second rendering from human hands: one date -u call, two derived renderings, and a written rule that the filename wins. Of the next 165 messages, 2 mismatched — both by one second, i.e. someone calling date twice. The failure class was gone.

3. A rule that lives in two places gets fixed in one

When we changed that timestamp rule, the first search missed two copies — they paraphrased the recipe instead of quoting it. One overlooked copy would have reinstated the old behaviour at every session start, because in a system operated by language models, prose instructions are code: a model reads them and executes them.

The search rule that came out of it: grep for the statement, not for the code snippet. And even that has a floor — a rule phrased without its own vocabulary ("take the latest") is invisible to any search. For those you have to know where the quantity matters and look by hand. The worst instance we found had an mv attached to it.

Bonus: the process that would not die

On Windows/msys, a background watcher survives the session ending, a context clear, and a process-tree kill — the tree is already torn at spawn, and the process is attached to no console. We first fought this with a "disarm before closing" ritual, which produced the opposite problem: sessions that were up but deaf, with no delivery path and nothing to see.

Inverting it was the fix: arming is idempotent. A new arm checks whether a live watcher for the same id already delivers, steps aside if so, and reaps it if it is a silent remnant. No disarm ritual exists any more. A leftover process and a duplicate are different things — prove liveness, do not infer it from parent PIDs.

The code

Everything is at https://github.com/csitte/claude-session-bridge — protocol, watcher, launcher, the full lessons chapter with the numbers, MIT.

It is Windows-first: the delivery core is portable shell (CI runs it on Linux too), but the process handling is PowerShell. A port to macOS or Linux is explicitly invited and the places it would touch are small and marked — I cannot review one against reality, since I have no such machine running this.

It is a snapshot of something I use daily, not a staffed project. Fork it rather than wait for me.