# Following a release from another session

Case study · October 29, 2026

Status lives in the session doing the work. Asking for it interrupts that work, and waiting for it means the “done” you hear has lost its caveats.

## At a glance

- **Setup:** One local Claude Code session following two sessions on a teammate’s paired machine: a dashboard release, later an integration test run.
- **Rhizome:** `subscribe` and `unsubscribe` to exact session IDs. History sharing was off on the teammate’s host.
- **Work followed:** A development rollout, then a branch test on core PR #54.
- **Result:** Dev rollout reported ready for testing; production held for confirmation. A possible push conflict on a shared PR branch was flagged.

## The situation

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 challenge

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?

## Without Rhizome

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.

## How Rhizome helped

1. **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. **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. **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. **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. **Flag overlap.** The same report warned that another session was working on the same PR branch.

![Independent release and testing sessions supply reported activity through Rhizome subscriptions to a local summary and a human decision.](https://tryrhizome.dev/diagrams/release-progress-flow.svg)

Simplified flow, not verbatim messages. The summary separates reported progress from pending verification; people decide the next step.

From the sessions (assistant reports, 2026-10-23, times UTC; not raw message payloads):

- **18:09:19 UTC**, Local observer session
  > I can read only what these sessions send while I'm subscribed, since his host doesn't share history.

  The release report, with its limit stated up front.

- **22:20:25 UTC**, Local observer session
  > I haven't seen anything directly from the Cursor session.

  A relayed result, labeled as relayed.

## The outcome

- **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.

## Rough edges and limits

- **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.

![October 23 checkpoints show subscription setup, the release report, an explicit unsubscribe gap, resubscription, reconnecting and the later testing report.](https://tryrhizome.dev/diagrams/release-progress-timeline.svg)

All times UTC on October 23, 2026. The broken segments are the unsubscribe gap. The later reconnection time is unknown; production completion is unconfirmed.

## Try it on one live release

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

A prompt to start with:

```text
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.
```

## About this account

Based on the complete available local Claude Code observer history for October 23, 2026, retrieved on October 29. All entries and quotes are local assistant reports; remote release and testing histories were not available. Recorded history contains assistant text and activity summaries, not user prompts, private reasoning, raw tool payloads or proof of command success. PR #54 and the core documentation were checked separately. Session IDs, machine addresses and local paths are omitted. Times are UTC on October 23.

## Further reading

- [Historical integration branch: core PR #54](https://github.com/aliengiraffe/rhizome/pull/54)
- [Current supported integrations and setup](https://github.com/aliengiraffe/rhizome/blob/main/README.md)
- [Subscription behavior and limits](https://github.com/aliengiraffe/rhizome/blob/main/docs/reference.md)
- [Install and configure Rhizome](https://tryrhizome.dev/install.md)
- [Two laptops, one feature](https://tryrhizome.dev/resources/two-laptops-one-feature)