`##share pane`: pair-debugging with a human and an agent at once

Share a live terminal pane — shell, agent, and all — with a teammate. View or control. Here's what pair-debugging looks like in rysh.

It's 11pm. You've got a flaky integration test, an agent halfway through bisecting it, and a teammate on Slack asking "can you show me what it's doing?"

Your options, historically:

1. Screen share. Now they're watching pixels. They can't scroll back, can't copy an error, can't type. And you're narrating a terminal over video like it's a nature documentary.
2. tmux over SSH. Works great — if you're both on the same box, with accounts, keys, and matching socket permissions. Your teammate is on their laptop at home. They are not on your box.
3. Copy-paste archaeology. Paste stack traces into Slack until one of you gives up.

In rysh there's a fourth option. From the pane where the agent is working:

##share pane view

That's it. The pane — shell output and agent output alike — is now a live share on your upstream server. rysh prints the share ID and the exact subscribe line (##share list shows it again); hand it to your teammate.

On their machine, in their own rysh session:

##upstream list-remote
##upstream subscribe <shareID>

Everything your pane emits from then on streams into theirs. They see the shell commands. They see the agent's tool calls. They see the test finally go red in the exact place you swore it couldn't.

The part that's actually new

Sharing a terminal isn't new — screen sharing and tmux both technically do it. What's new is what a rysh pane is.

A pane in rysh isn't just a PTY. It's a conversation: a shell and an agent live in the same pane, and both write to the same output stream. So when you share a pane, your teammate isn't just watching your typing — they're watching your agent think. Every tool call, every file read, every test run the agent makes is part of the shared stream.

Pair-debugging stops being "two humans, one keyboard." It's two humans watching one agent work, both able to say "wait, go back — why did it skip that file?"

And when watching isn't enough:

##share pane control

Control mode — with your teammate subscribed as ##upstream subscribe <shareID> control — lets them send input back:

##upstream send go test -run TestFlaky -count=20 ./...

Their command lands in your pane, runs in your shell, and the output streams back to both of you. One pane, two humans, one agent, zero screen sharing.

When you're done:

##upstream unsubscribe     # their side
##unshare pane             # your side

##share status tells you the upstream connection state at any point.

What's happening under the hood

No hand-waving — here's the actual mechanism.

When you run ##share pane, rysh's ShareRegistryActor (each workspace actor runs one) spawns an UpstreamShareActor for that share. It subscribes to your pane's local output topics — shell, agent, and raw terminal frames — and forwards them to NATS subjects on the upstream server under:

ws.{workspace}.share.{shareID}.output

In control mode, it also subscribes to:

ws.{workspace}.share.{shareID}.command

…and routes inbound commands to your local pane actor. On the subscriber's side, a RemoteShareListenerActor subscribes to the output subjects and feeds the text and terminal frames into their pane.

The guard rails sit on your side of the wire. A view-mode share never even subscribes to the command subject, and your rysh rejects any inbound command unless the share is in control mode. In control mode, your own config decides what runs: an allow list of command types and a command blocklist, checked before a command reaches your shell (keystrokes into an interactive program go straight through — control means control). On the rysh.ai server, every connection is confined to its own workspace's NATS subjects, so shares don't leak across tenant boundaries.

The honest part

Some things this is not, so you're not surprised:

• It's not Google Docs for terminals. There's no cursor presence, no per-user colors. It's a shared stream plus an inbound command channel. That's a feature for debugging — and a limitation if you expected a collaborative editor.
• Treat a shared pane like a screen share. If you cat .env in a shared pane, your subscriber sees it. Don't share panes where secrets will hit the scrollback.
• It needs an upstream. Sharing goes through a NATS upstream — use ours at rysh.ai, or point the CLI at your own NATS server for basic pane sharing (the CLI is open source; the rysh server is proprietary). The agent side runs on Claude with your own Anthropic key.
• We're early. This works today (we run it against the live rysh.ai upstream), but the edges are still being sanded. That's exactly why we want design partners using it on real bugs.

Why this matters beyond the demo

The 11pm debugging session is the hook, but the deeper shift is this: once agents do real work in your team, watching an agent becomes a first-class team activity. Reviewing an agent's approach mid-flight, handing a stuck investigation to a colleague without losing the agent's context, letting a senior engineer sanity-check a junior's agent before it touches prod — all of that needs a primitive for "share this live conversation."

##share pane is that primitive. Everything else in rysh's collaboration story builds on it.

Rysh is in early access and we're recruiting design partners — teams who debug real systems and want agents in the loop. You get hands-on onboarding and a direct line to the founders; we get brutal feedback. Apply at rysh.ai/design-partner.

Next in this series: View vs control: two trust levels for a shared terminal and Sharing a whole tab: incident response as a shared surface.