Git Relay gives AI sessions a shared project conversation

I wanted the AI session on my laptop and the one on my server to talk to each other without making me copy every message between them. They already shared a Git repository. That turned out to be enough for a small, useful relay.

The idea is straightforward: set aside a branch for messages, give each message an address, and let each session check for replies. The conversation stays with the project, where another session can pick it up later.

Why I needed it

My two sessions could see different parts of the same job.

The server-side session could inspect the deployed environment within its permissions. The local session had the development tools and a place to rehearse changes. Neither had the full picture.

A change could need both. The local side could prepare and rehearse it. The server side could answer questions about the environment it would eventually run in. I was carrying the questions and answers between them.

That works for a couple of messages. Once there are follow-up questions, file versions and checks to compare, I end up spending more time moving context than making decisions.

I wanted the sessions to handle that exchange themselves while I kept control of consequential actions.

A branch as a mailbox

We used a dedicated branch called claude/relay. The name is incidental; this pattern is not tied to a particular assistant. The important convention is that the branch is for communication and never gets merged into the application branch.

A message is a commit. Its subject starts with the destination:

[to-prod] Local rehearsal needs an environment check
[to-local] re <published-commit-sha>: compare the approved schema reference

The body explains what happened, what was checked and what the sender needs next. Replies refer to the published commit they answer, so you can follow the exchange in git log.

Each side uses a separate worktree for relay work. Git supports multiple working trees for one repository, which lets the relay branch stay separate from the checkout running the application. A worktree prevents an accidental branch switch in that checkout; it does not create a security boundary. Git worktree documentation

During an active exchange, a small watcher fetches the relay branch about once a minute and reports new messages. Connecting that output to an assistant notification depends on the agent runtime. Outside an active exchange, there is no need to keep polling.

A useful handoff

Here is a simplified, illustrative example of the kind of exchange this supports. A local rehearsal stops because its environment does not match the assumptions behind a proposed change. The local session sends a question about the expected schema instead of asking me to carry it.

The server-side session checks what it is allowed to inspect and replies with what it found, what it could not verify and the reference the local side should compare. If its access is limited, it says so. It does not turn a partial observation into a claim that everything is unchanged.

That distinction matters. The receiving session needs evidence it can evaluate, including the limits of that evidence, rather than an overconfident conclusion.

The exchange can also surface a precaution before the next step. A local rehearsal should not accidentally contact real users or external services. The sessions can flag that risk and prepare checks while leaving any consequential change for my approval.

Those are the details I want them to exchange. I can review the proposed next step without being the messenger for every question leading up to it.

Giving new sessions the same starting point

The relay becomes more useful when the rules live in the project instructions the assistants actually load.

That small section explains the roles, the relay branch, how to read and reply, and the limits on what a message can authorize. A fresh session should verify its environment rather than guess which role it has. It should also catch up on messages it has not processed, rather than assume the newest commit is a safe starting point.

This is the part I want to carry into Codex for Everything: a simple way for separate AI instances working on one project to share context.

They do not suddenly share a memory. Each still has to read the conversation, check its sources and understand what is current. But the next session has somewhere specific to look instead of depending on me to reconstruct the last one’s work.

A community session people can join

I also want this to work for a community project, where people bring their own AI sessions and join the work within the repository’s rules. A session could say hello with a participant and session ID, its role, the topics it can help with and the time it joined. Anyone following that project stream could catch up and see who offered to help.

A short “relay off” notice or an expected return time would be courteous, not mandatory. Silence would not prove that someone is online, available or gone. The conversation would remain in Git for the next session to read.

Tasks would need an address and an explicit acceptance. Joining the conversation would not grant permission to assign work, approve changes or merge code. Those permissions would come from the project’s rules and trusted approval process.

This is a proposed extension of the relay convention, not an implemented CFE community feature. The current polling approach gives eventual delivery while a watcher is running, not strict real-time presence or instant push. More participants would need scoped streams, filtering and limits on automatic replies, with capacity tested as the project grows. The practical guide sketches a minimal session protocol.

The boundaries matter

A peer message can provide information. It cannot become permission from me.

Deployments, service restarts, production writes, deletions, credential changes and merges still need the appropriate human approval. Even read-only work and preparing a file must fit the access and task scope that session already has.

That rule helps, but a sentence in a project file does not make forged messages harmless. Anyone able to write to the relay could submit misleading content. Repository permissions, verified identities where appropriate, least-privilege tools and real approval gates still matter. A commit’s author name alone is not proof of who sent it.

Sensitive files stay out of the relay. A private transfer channel carries approved files; a relay message can carry a non-sensitive reference, a size and a SHA-256 checksum when those details are appropriate for everyone with repository access. Even paths and identifiers deserve review. A checksum helps confirm that the received bytes match; it does not make a file safe or establish who supplied it.

Git history is persistent and can be copied. Keeping something off the main branch does not make it private.

When I would use it

This fits asynchronous handoffs between sessions that already share a repository. A question can wait for the other side, and the answer stays available for review.

For low-latency collaboration, direct agent messaging may be a better fit. Its logging and availability depend on the tool. Issue threads or another shared workspace can also work. The useful question is which channel the sessions can actually access and reliably revisit.

For this project, Git was already that channel. Adding a small communication convention let the assistants exchange the details while leaving the important decisions with me.

The companion guide explains how to adapt the pattern, including the catch-up and retry details that a minimal watcher can miss.

Read the companion guide: A practical Git Relay guide for AI coding sessions.

For the broader architectural idea, read The useful part is deciding where AI belongs.