Building context-bridge with context-bridge
Version 0.12.0 was built and reviewed by five coding agents passing the same session between them through context-bridge.
Claude Code, Codex, Grok, Antigravity, and OpenCode all worked on the release. They implemented changes, reviewed one another’s work, challenged findings, and verified the fixes.
This was not a staged demo. It was the actual development process, and when a handoff failed, it interrupted my own work.
That was the point.
Why pass the review between agents?
The usual way to get a second opinion from another model is to open a new session and explain the problem again.
That sounds simple, but a summary rarely contains everything that matters.
The new agent does not know which ideas were already considered, which constraints cannot be changed, or why an obvious solution was rejected two hours earlier. It reviews your description of the work, not the work as it actually happened.
With context-bridge, I could hand over the active session instead.
The next agent received the decisions, failed attempts, unresolved questions, and current state of the repository. It could disagree with the work from inside the same context rather than reacting to a condensed version of it.
The difference was obvious.
Reviews became more specific. Agents stopped recommending tests that already existed. They did not repeatedly suggest designs that had already been rejected, because the reasons behind those decisions travelled with the session.
That made their disagreements much more useful.
The final bug
The last important issue was found in the tombstone logic.
Tombstones are what make bridge unlink safe. When an agent is unlinked, context-bridge leaves a marker behind so stale hooks from that agent become complete no-ops.
If this goes wrong, an agent started directly outside the bridge can silently adopt an old session again. It can also consume a delta intended for a session that is still active.
The implementation stored a single tombstone marker.
That was the bug.
Unlinking one session could overwrite the marker for another session that had been unlinked earlier. Under the right conditions, the older session could then become eligible for adoption again.
What we actually needed was a cumulative set of tombstones.
All five agents flagged the same problem independently during the final holistic review.
That mattered more to me than any individual finding. One model saying something looks wrong can still be noise. Five independent agents pointing to the same failure mode deserves immediate attention.
The bug was fixed, then reviewed again by all five agents before the release.
What I would not claim
I would not claim that five models are automatically smarter than one.
Many of the reviews overlapped. Some findings were wrong. Others were technically possible but irrelevant in practice. A few were delivered with much more confidence than they deserved.
The value did not come from collecting more opinions.
It came from giving each agent enough context to form a useful opinion, then comparing where they agreed, where they disagreed, and how they failed differently.
Independent agreement increased confidence. Disagreement increased coverage.
Human judgment was still required throughout the process.
It was not free either
Every switch has a cost.
Another CLI has to launch. The session has to move. The next agent needs time to inspect the current state. A complete review round across five agents is slower than reading a small diff yourself.
For a simple change, I would not do it.
Version 0.12.0 touched trust boundaries where failures could remain silent and affect someone else’s repository. In that case, the extra review time was worth it.
The bugs that unit tests did not find
The most valuable failures appeared only because I was using context-bridge for real work.
The first handoff to OpenCode hit E2BIG.
One Claude-to-Codex handoff was recorded as delivered even though Codex never received it.
An orphaned discovery server left a TUI connected to stale state.
These were not missing assertions in a unit test. They were failures at the boundaries between processes, CLIs, session state, and real usage.
They appeared when I was in the middle of a task, switched agents, and discovered that the context I needed was not there.
Using the tool to build the tool forced those failures into the open.
That is still the review pass I trust most: the one where I am the user, and the cost of the bug reaches me before it reaches anyone else.