Sharing a whole tab: incident response as a shared surface

One pane tails logs, one runs the agent, one pokes prod. ##share tab turns the whole incident workspace into something the team can watch.

Incidents have a geography. Anyone who's been on call knows the layout by heart:

• one pane tailing the error logs,
• one pane where you're poking the service — curl, kubectl, psql,
• one pane where (these days) an agent is grinding through "when did this start and what shipped right before it?"

That layout is the investigation. The logs give you symptoms, the shell gives you experiments, the agent gives you a parallel line of inquiry. Context lives in the arrangement.

And then someone senior joins the incident call and says: "what are we looking at?"

So you share your screen, and the geography dies. They see one window at video resolution. You alt-tab, they lose the logs. You zoom the logs, they lose the agent. The most context-rich fifteen minutes of the incident get narrated instead of seen.

Share the surface, not a window

In rysh, the unit of sharing doesn't have to be a single pane:

##share tab

This shares the whole tab — every pane in it — as one shared entity on your upstream server. Responders subscribe from their own machines:

##upstream shares
##upstream subscribe <shareID>

…and the tab's activity streams to them, live, in their own terminals. The log tail, your shell experiments, the agent's tool calls — the entire investigation, not a keyhole view of it.

##share list shows what you're sharing; ##unshare tab ends it when the incident is over. (There's also ##share panegroup if the right scope is one column of the layout, not the whole tab.)

Why the tab is the right unit for incidents

Sharing a single pane is perfect for pair-debugging one problem. Incidents are different: they're multi-threaded by nature, and the threads matter in relation to each other.

The moment the agent says "deploy 7f3a21 touched the retry logic" matters because thirty seconds earlier the log pane showed retries spiking. If observers only see one pane, they get facts. If they see the tab, they get the correlation — which is the thing that actually cracks incidents.

There's a structural reason this works well in rysh: every pane already publishes its output as separate streams (shell output, agent output) over NATS, and a tab is a first-class actor that knows its panes. Sharing a tab means forwarding those per-pane streams through the same share machinery a single pane uses — each share registered with the upstream, streamed over workspace-scoped subjects (ws.{workspace}.share.{shareID}.output), with the server's proxy enforcing mode and subscriber checks on every message. Same trust model, bigger aperture.

The incident-channel pattern

How this plays out in practice — a pattern we think of as the glass-walled war room:

1. The IC (or first responder) builds the tab. Logs pane, shell pane, agent pane. This is what you'd do anyway.
2. ##share tab — in view mode. Drop the share ID in the incident channel. Anyone who needs context subscribes. Nobody asks for a recap; the recap is scrolling past in their terminal.
3. Watchers stay watchers. View mode means the VP who wants to feel informed cannot type into your prod shell. This is a feature. Arguably the feature.
4. Escalate one pane, not the world. If a specific responder needs hands-on — say, to drive a diagnostic while you write the status update — share that one pane in control mode. Smallest sufficient grant.
5. Unshare at resolution. Shares are incident-scoped, not standing access.

The agent pane deserves a special mention here. During an incident, an agent can chew through the grunt work — diffing recent deploys, summarizing log patterns, checking whether that config flag changed — while humans handle judgment calls. But an agent no one can see is an agent no one trusts at 3am. In a shared tab, the agent's every tool call is visible to every responder. It's not a black box whispering to one engineer; it's a colleague working in the open.

What this is not (yet)

Honesty section, as always:

• Not a recorded, replayable incident timeline. Subscribers see the live stream in their panes. Persistence of what they saw is their scrollback. A first-class incident replay would be a natural extension — if you'd use it, tell us.
• Not presence-aware. You don't see who's subscribed hovering over which pane. Coordination still happens in your incident channel.
• The stream is readable text, not pixels. Full-screen TUIs on the sharer's side stream as readable text to observers — good for logs and commands, not a remote-desktop replica.
• Scrollback hygiene applies. Everything printed in a shared tab reaches subscribers. Prod incidents involve sensitive output; scope shares deliberately and unshare promptly.
• You need an upstream — rysh.ai's hosted one or your own; the server is self-hostable and the agents run on Claude with your own API key, so the whole loop can live on your infra.

The bigger point

Most incident tooling is about communication — channels, pages, status docs. The actual work of the incident happens in terminals, invisibly, and gets communicated secondhand.

Sharing the working surface itself removes a translation layer. The team stops asking "what did you find?" and starts saying "I saw what you found." With agents joining incident response, that visibility stops being nice-to-have — it's how a team learns to trust what the agent did while everything was on fire.

If your team carries a pager and is experimenting with agents in ops, you're exactly who we're building this with. We're taking on design partners — hands-on onboarding, direct founder access: rysh.ai/design-partner

Related: ##share pane: pair-debugging with a human and an agent at once · View vs control: two trust levels for a shared terminal