Following a release from another session

A teammate was rolling out a dashboard release from a Claude Code session on his machine. Later that day, another of his sessions reported integration-test checkpoints for a Cursor CLI branch.

A local Claude Code session on another machine followed both. It didn’t launch or control that work; it received reported activity through Rhizome subscriptions and summarized it for its user.

The local user had to decide what happened next with the release, and needed answers without pulling the teammate out of a deploy:

• → State. Has the development release reached the tester, or is the build still blocked?
• → Done versus reported. Which items are finished, which are fixed but unverified, and which are still open?
• → Gate. Can production go, or is it waiting on a confirmation?
• → Overlap. Is anyone else pushing to the same branch?

The status existed, in a terminal on someone else’s machine. Getting it out usually looks like this:

• → Interrupt. Ping the teammate mid-deploy. He stops, reads his own session back, and summarizes it from memory.
• → Wait for the update. A Slack message eventually says “deployed”. It collapses “rolled out to dev”, “fixed but unverified” and “waiting on the tester” into one word, and production goes out on the wrong signal.
• → Paste terminal output. Someone copies a wall of logs into your session. Your agent now has raw output with no sense of what matters.
• → Miss the overlap. Two sessions pushing to the same PR branch find out at rebase time.

1. 01 Subscribe to exact sessions. At 17:31 UTC the local session subscribed to the teammate’s two live sessions by ID. A session name was a discovery clue, not evidence of what it was doing.
2. 02 Filter for what matters. After some noise, the user set the rule: stay quiet on routine events, speak up for failures, messages or overlapping work.
3. 03 Summarize by status, not by event. At 18:09 the observer reported the release state in buckets. Rolled out: development dashboard and API, with fixes for filter Apply, View Data and an out-of-memory load. Resolved blocker: a stale Docker/Next build cache. Pending: tester confirmation on a newly activated request, then production. Still open: multi-select filters, CI deployment work and an oversized build context. The second session had sent nothing, and the observer said so instead of guessing.
4. 04 Keep the source visible. At 22:20 the observer relayed a testing checkpoint that came from the teammate’s Rhizome session, not from the Cursor session itself, and said so.
5. 05 Flag overlap. The same report warned that another session was working on the same PR branch.

• → A clear release decision. Development was reported ready for the tester; production waited for confirmation. Nothing was rounded up to “done”.
• → A specific test checkpoint. Gateway fix 31594bb on core PR #54 with CI reported passing. Four activity events collected, and a queued message produced exactly one end-of-turn follow-up, which the receiving session treated as information.
• → Open items kept open. Delivery after a tool result, disabling follow-up delivery, desktop and two-device testing, docs and review were all still outstanding in that report.
• → An early overlap warning. The shared-branch warning came before any push. It flagged a risk; it didn’t prove a conflict was avoided.

This was branch testing, not shipped Cursor support. As of October 29, PR #54 was still open, and the core README documented Claude Code, Codex and OpenCode.

• → The agent overstepped. It widened its subscriptions to three local sessions, then unsubscribed from one without being asked. At 17:41 it acknowledged that and restored it.
• → Unsubscribing leaves a gap. At 18:09:34 it unsubscribed from all five sessions. When it resubscribed at 18:15, it couldn’t recover what happened in between, because the teammate’s host didn’t share history. Unsubscribing changes what you receive, not what the other session does.
• → Connections drop. At 20:46 both remote subscriptions were reconnecting. The observer couldn’t tell whether the machine was asleep or the network dropped, and the record has no exact reconnect time.
• → Reports, not proof. Everything here is what sessions reported. It doesn’t show that production shipped, and it doesn’t replace testing or review. No time savings were measured.

1. 01 Pair your machine with the teammate’s if the work runs elsewhere, and find the session whose progress you need.
2. 02 Subscribe to its exact session ID. Agree up front which events deserve a summary: blockers, handoffs, verification checkpoints.
3. 03 Ask for summaries that separate reported done, blocked, still testing and needs a human decision, with the source of each.
4. 04 When you stop following, treat the gap as unknown unless the other host shares history.

Subscribe to <session>. Stay quiet on routine events. Tell me when something
is blocked, handed off, or needs verification, and say which session reported it.