Claude Session Bridge

claude-session-bridge

[](https://github.com/csitte/claude-session-bridge/actions/workflows/ci.yml)

A durable, file-based message channel between long-running Claude Code sessions — plus a per-session watcher that **pushes** new messages into an idle session, and a launcher that brings a whole fleet back up after a reboot.

The whole mechanism is one sentence: **a shared folder of write-once files, and one small polling script per session.** No server, no daemon, no database, no lock.

Built and operated on a real fleet of ~15 sessions across two Windows machines since July 2026. Everything here is in daily use; the numbers in [docs/lessons.md](docs/lessons.md) are measurements from that fleet, not estimates.

Background: [*A running session is not a reachable session*](https://dev.to/csitte/a-running-session-is-not-a-reachable-session-34fc) — the three failure modes behind this design, in prose.

What that buys you

These are the properties that made us stop looking for something else. Where one of them came out of an incident, [docs/lessons.md](docs/lessons.md) has the incident:

• A message outlives everything. Reboots, crashes, a context clear, a session that was closed for a week. It is a file; it is still there, and the fold still computes the same state from it. Nothing lives in a queue or in memory.
• You can write to a session that is not running. It finds the message at its next start — and knows whether the ball is with it, because ownership is derived from the messages themselves. This is the one property no in-process messaging can give you.
• It crosses machines. The channel is a folder; ours syncs between a PC and a notebook. Same protocol, no extra component, no port, no account.
• An idle session gets woken, not left waiting. The watcher turns a new file into a notification that re-invokes the session — no human tapping windows.