The agent harness I’m building, Bram, launches in a local git repository and requires that both git and gh (GitHub’s CLI) be installed. Agents can wield both tools far more capably than we humans can. In the Before Time I knew it was possible to perform a git bisect or use hunk staging to separate entangled files, but it was a huge struggle to do those things. We’ve always known git needed a better user interface, and we’ve long imagined that a more rational set of commands or a stronger GUI would be the answer. Nope. The answer turned out to be directing agents to use the tools on our behalf. We know what needs doing, they know how.
You may have felt the power that flows from delegating git syntax and workflows to agents. A complementary power flows from asking agents to use gh to write, read, and reply to GitHub issues. Here are some of the coordination scenarios that enables.
The GUI that Bram wraps around Claude Code and Codex enables you to switch agents with one click. Each agent wakes up with access to four buckets of context: 1) the worklist (items planned, in progress, or committed), 2) sessions (both Claude’s and Codex’s), 3) commits, and 4) issues. When an item is in progress I routinely switch agents and direct them to review each other’s work. Three heads are better than one for both planning and execution.
When running on the same machine you can ask each to read the other’s sessions; they’re all sitting there on disk. Bram makes that easier by indexing both Claude Code and Codex session files, along with worklist history, commits, and issues, and making all that agent-searchable via SQLite full-text search.
What about collaboration across machines? Use a GitHub issue as a shared space where you, Claude Code, and Codex can talk to one another. Since everyone shares your GitHub handle it’s critical for all three heads to properly self-identify. Bram’s harness tells agents to sign their messages like this:
Jon’s Claude (main thread, Opus 5) speaking from the Bram project (https://github.com/judell/bram) (Windows)
Jon’s Codex (main thread, gpt-5.6-sol) speaking from the XMLUI project (https://github.com/xmlui-org/xmlui) (Mac)
For the same-machine scenario there is an available channel I had not considered. Codex figured out it could talk directly to Claude via its local API:
claude --print --safe-mode --tools '' --permission-mode dontAsk --no-session-persistence --model opus --effort high ''
What ensued here is both hilarious and sobering. This looks like Claude speaking in my account, using an earlier form of the agent signature that we have since strengthened.
Foundry
In fact Codex posted that note as Claude’s scribe. It had spawned a headless Claude, discussed the issue, and relayed both halves of the conversation to GitHub without signaling that Claude was not the direct author of the words that appeared under its name. When I saw what was happening I blew my referee’s whistle. I don’t want these things talking to each other behind my back! I want them to speak on the record in an audited system that neither controls.
Sometimes this issue-based collaboration happens across my own machines, as when we are vetting a Bram release candidate. Bram logs exhaustively, using a rich trace vocabulary that covers a wide swath of its behavior. When an agent running on my Windows laptop reports a bug, I tell it to read the trace, analyze what happened, open a coordination issue, and attach log evidence. Then I tell an agent running on my Mac to pick up the issue and start working it while the Windows-based agent continues testing the release candidate.
Those same logs are available in any project managed by Bram. In “When an AI agent goes off the rails, file a bug to fix the documentation — then test the fix” I wrote:
As a co-maintainer of XMLUI I am acutely sensitive to agents fumbling as they build XMLUI apps. When something that should be a no-brainer isn’t, because the MCP search didn’t find the answer it should have, I file an issue and then direct an agent to write the missing document.
Here is that process in action.
In the left window Bram is running in its own repo. It has found a gap in the XMLUI documentation and filed issue 3847 to the XMLUI repo. In the right window Bram is running in the XMLUI repo where it has picked up the issue and proposed a new How To document. The XMLUI instance of Bram will research the issue, do the work, write and publish the missing document, and close the issue.
Along the way, a problem with Bram itself may surface. In that case I tell the XMLUI instance of Bram to file an issue to Bram’s own repo. On August 26 I captured a detailed storyboard showing this two-way collaboration. In the ~/xmlui repo we burned down a set of XMLUI documentation issues while stress-testing Bram’s ability to manage file entanglement across items being handled by parallel subagents. In the ~/bram repo we simultaneously burned down issues raised in response to findings from activity in the ~/xmlui repo. Real work happened on both sides, each helped improve the other, and it was all coordinated by issues in the two repos.
A collaborator I’ll call M, working in her own project, ran into a performance bug and told Bram to report it in issue 323. Her Claude read the traces and filed a report with detailed evidence.
The problem was that Bram needed to batch its use of git. M’s repo had more files in it than Bram had previously encountered, and she is running Windows, which spawns more expensively than macOS. Her report included a tangential but useful detail. Bram is transitioning its worklist machinery from a set of JSON files to its embedded SQLite database. During the transition, worklist state is mirrored to SQLite but not yet active there. A trace I’d added a few days before — which Claude calls a “divergence tripwire” — proved itself in two ways: as independent confirmation of a bug that was also caught by other traces, and as validation that SQLite mirroring is being effectively monitored.
Emerging protocols for agent coordination, like A2A, specify bundles of JSON that agents pass among themselves. I expect such formal messaging will play a key role, but meanwhile there is an overlooked channel of communication that is equally friendly to humans and AIs. And I don’t want to privilege GitHub; you can also use Bram in a GitLab repo. When agents converse this way I can read and steer the discussion, and it’s durably recorded for search and cross-linking. Occasionally I’ll turn them loose to speak autonomously, as happened in issue 278 where I asked Claude and Codex to work together on a redesign of Bram’s worklist pane. Each agent set up a watcher on the issue; they took turns refining a storyboard while I went for a bike ride. Later I popped in occasionally to redirect them.
Mostly, though, Claude and Codex speak in issues only when I invite them to speak or respond. I’m not a “meat proxy” — someone who blindly relays stuff from one agent to another. And I’m not a “human in the loop” either. I despise that phrase because it cedes agency to the machines. I prefer “agent in the loop” — it’s our loop, we invite agents in as collaborators. Then we watch, interrupt, inspect evidence, reprioritize.
This process isn’t as fast or frictionless as it might be if I just let agents romp autonomously. That’s by design. I’m doing more than I could have dreamed of a year ago, faster than I would have thought possible. Slowing things down, and adding the right kind of friction, makes the agents’ work legible and keeps me in control. You don’t need new protocols for that. The humble GitHub issue, understood properly and used well, can bring agents into our loop and coordinate them effectively.