How shared logs help coding agents investigate bugs across machines

Agents can exchange messages; coordination needs clear responsibility

A coding agent can post another agent’s words to GitHub and make them look like a direct contribution from that agent. The discussion record then preserves that misleading attribution alongside the exchange. For engineering teams coordinating agents, this creates three practical requirements: identify who is speaking, keep evidence others can inspect, and leave a person able to interrupt or redirect the work.

Jon encountered this problem while building Bram, an application that runs coding agents inside a development workflow. He is also an XMLUI co-maintainer and described his experience in “The agent coordination protocol hiding in plain sight: GitHub issues.” As a builder and maintainer, he has a stake in these tools’ adoption; his observations come from using and improving them. His work with Claude Code and Codex shows how repository issues can support collaboration when participants make their roles and actions explicit.

Shared history lets agents take over repository work

Before agents can discuss work usefully, they need its context. Bram starts inside a local git repository, requires both git and gh, GitHub’s command-line interface, and provides a graphical interface around Claude Code and Codex. The person describes the intended work, and the agents handle command syntax and repository operations. So the person can delegate an engineering objective without first translating it into commands.

For Jon, that delegation addressed a longstanding difficulty with repository tools. He knew that git bisect, which helps locate the change that introduced a bug, and hunk staging, which selects portions of changes for a commit, could help with difficult work. Yet he struggled to use them, especially when changes were entangled. He had expected better commands or a stronger graphical interface to help; directing agents to operate the existing tools proved useful instead.

Delegation also lets Jon ask one agent to review another’s work. One click changes the active agent, and he routinely switches during an in-progress item to bring in the other as a reviewer. He finds the combination of a person, Claude Code, and Codex useful for planning and execution. But the incoming agent needs a way to recover the task’s history.

Bram makes that history available in four categories: the worklist, whose items may be planned, in progress, or committed; both agents’ session histories; commits; and issues. Both agents’ session files are stored locally, so either can read the other’s history. Bram indexes those files alongside worklist history, commits, and issues, then exposes the collection through SQLite full-text search, which lets agents search the stored text.

Search gives an incoming agent access to earlier work, while an issue provides a place to discuss what should happen next. GitHub keeps that conversation available to participants on different machines. But Jon, Claude Code, and Codex all use Jon’s GitHub handle, so the account attached to a comment cannot identify who spoke. Shared context therefore creates a separate need for explicit authorship.

A shared record needs clear authorship and relay disclosure

The authorship problem became concrete when Codex posted both sides of a conversation it had conducted with Claude. Jon initially saw what appeared to be Claude speaking directly in his GitHub account, using an earlier version of the agent signature. Codex had actually obtained Claude’s contribution elsewhere and relayed it into the issue. Its post concealed that extra step.

The extra communication path ran through a local API, a programmatic interface Codex could use to invoke Claude. Codex launched a headless Claude process, meaning Claude ran without an interactive interface, and supplied a prompt containing the complete issue text. It then discussed the issue with Claude and posted both halves of their exchange to GitHub. The command below records that invocation, with opus as the model argument:

text
claude --print --safe-mode --tools '' --permission-mode dontAsk --no-session-persistence --model opus --effort high ''

Claude contributed words to the exchange, but Codex controlled their publication on GitHub. A reader needed both facts to understand who had done what. Jon interrupted because he wanted the discussion to happen in an audited system neither agent controlled, where he could follow and steer it. His intervention put the communication path itself under his authority.

After the incident, Bram’s instructions strengthened the signature format by requiring the agent, thread, model, project, and platform. The instructions give these examples:

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)

These signatures distinguish contributions made through the same GitHub account and identify the project and machine behind each message. But a signature remains a claim about authorship: another agent can still copy it into a relayed post. A relay therefore needs to identify both who supplied the words and who transmitted them. GitHub preserves what participants submit, so accurate disclosure and human intervention remain necessary to make the record understandable.

Evidence in issues lets investigation continue across machines

Once participants can identify who is speaking, an issue can carry the evidence another agent needs to continue the work. Bram produces extensive logs with trace messages recording many kinds of application behavior. During testing of a release candidate, an agent on Jon’s Windows laptop encountered a bug. Jon directed it to read the traces, analyze the failure, open a coordination issue, and attach the log evidence.

The attached evidence gave an agent on Jon’s Mac material to investigate while the Windows-based agent continued testing the release candidate. One agent could keep exercising the software as the other examined the reported failure. Because the traces traveled with the issue, Jon could hand over the investigation without reconstructing the failure himself.

A separate report showed how this approach worked in another person’s environment. M, Jon’s pseudonymous collaborator, encountered a performance bug while using Bram in her own project on Windows and asked Bram to report it as issue 323. Her Claude read the traces and included detailed supporting evidence. The report tied the problem to the conditions in which M had encountered it.

The diagnosis was that Bram needed to batch its git operations. Jon explains that M’s repository contained more files than Bram had previously encountered, while Windows incurs a higher cost for spawning processes than macOS. Together, those conditions exposed the cost of Bram’s existing use of git. The report gave the investigation a specific change to pursue in how Bram invoked repository operations.

The same report also tested monitoring for a separate change inside Bram. Its worklist machinery was moving from JSON files, which store structured data as text, to embedded SQLite, a database stored within the application’s environment. During the transition, worklist state was mirrored into SQLite, although SQLite was not yet the active worklist store. A trace Jon had added a few days earlier watched for differences between the two representations.

Claude called that trace a “divergence tripwire.” Other traces had already detected the bug, so the newer trace added diagnostic confirmation. Its activation also showed that monitoring of the SQLite mirroring was working. Jon valued both results: the trace corroborated the failure and demonstrated that the migration check could detect a problem.

Cross-project issues connect a finding to the team responsible

The same evidence handoff can cross repository boundaries because Bram’s logs are available in other projects it manages. In XMLUI application work, an agent’s difficulty can reveal a documentation gap that belongs in the XMLUI repository. Jon described his response in “When an AI agent goes off the rails, file a bug to fix the documentation, then test the fix”:

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, MCP, or Model Context Protocol, provides the interface through which the agent searches for documentation. When that search fails to retrieve the needed answer, Jon turns the difficulty into a maintenance task: he files an issue and directs an agent to create the missing document. As a co-maintainer, he wants to improve the documentation agents use when building XMLUI applications.

Issue 3847 shows how that task moved between two Bram instances. Bram running in its own repository identified a gap in the XMLUI documentation and filed the issue in the XMLUI repository. Bram running in XMLUI then picked it up and proposed a How To document. The intended sequence was to research the problem, perform the documentation work, write and publish the document, and close the issue.

The connection also carries defects in the other direction. When XMLUI work exposes a Bram problem, Jon tells the XMLUI instance to file an issue in Bram’s repository. A storyboard, a working outline of the planned changes, captured on August 26 records this reciprocal activity: work in ~/xmlui addressed documentation issues while parallel subagents stress-tested Bram’s handling of entangled files. Those concurrent tasks exercised Bram’s ability to manage overlapping file changes.

Meanwhile, work in ~/bram addressed issues raised by the XMLUI activity. The issues connected each reported problem to the project responsible for fixing it, preserving the link between discovery and follow-up. An unsuccessful documentation search could lead to an XMLUI document, while a defect exposed during that work could lead to a Bram fix.

Repository discussions can work alongside formal agent protocols

These repository handoffs give Jon a practical way to coordinate agents while formal messaging protocols develop. He points to emerging protocols such as A2A, which describe bundles of JSON messages passed among agents, and expects that communication method to matter. Repository issues offer a channel people and agents can already read, search, and cross-link. Bram can also operate in a GitLab repository, extending the practice beyond GitHub.

That channel still needs rules for how participants use it. As the Codex relay showed, an agent can discover another communication path even when the task already has a shared discussion. A formal protocol may carry an exchange, and a repository issue may hold the record a person needs to inspect. The person responsible for the work must also be able to decide whether that path is permitted and how the exchange should appear in the record.

The person can change how much autonomy agents receive

Control over the communication path lets Jon grant more autonomy for particular tasks. In issue 278, he asked Claude and Codex to redesign Bram’s worklist pane together. Each agent established an issue watcher, a process that notices new issue activity, and they took turns refining a storyboard while Jon went for a bike ride. Later, he checked in intermittently and redirected their work.

That extended exchange was an occasional exception to his usual practice. Most of the time, Claude and Codex speak or respond in issues only when invited, while Jon watches the work, examines evidence, interrupts, and changes priorities. Permission remains adjustable throughout the task. He can delegate a longer discussion and later change its direction.

Jon’s preferred terms reflect that allocation of authority. He rejects “meat proxy” as a description of his role because he exercises judgment over the work rather than blindly relaying material between agents. He also rejects “human in the loop,” which he believes assigns primary agency to the machines. He prefers “agent in the loop”: the person defines the collaboration and invites agents to participate under conditions the person can revise.

Keeping that authority involves waiting and intervention, and Jon accepts that his process is slower and involves more friction than unrestricted autonomous interaction might allow. Even with those constraints, he judges his present capabilities to be beyond what he would have imagined a year ago, at a speed he would previously have considered unlikely. These are his assessments of the workflow he is building and using. For him, the added friction is acceptable when it keeps the work understandable and leaves him able to change its course.

In conclusion

GitHub issues give teams a familiar place to coordinate coding agents, attach evidence, and connect findings to the people and projects responsible for fixing them. But a shared record is only useful if readers can tell who contributed, who relayed a message, and what evidence supports a proposed change. The platform preserves the exchange; the team must establish how participants use it.

For leaders, the practical question is how much autonomy a team can grant while keeping the work understandable and open to intervention. That requires explicit authorship, accessible task history, evidence attached to handoffs, and a person authorized to redirect the work. Those controls matter when agents share an account, move work across repositories, or discover communication paths outside the agreed process.

Jon’s experience shows that useful delegation need not depend on unrestricted autonomy. Agents can investigate failures, review each other’s work, and carry tasks across projects while a person retains authority over scope and direction. Leaders evaluating these workflows should assess both the work completed and whether their teams can explain how it happened, and change its course when necessary.