`##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 — the whole conversation, shell output and agent output — is now a live share on your upstream server. ##share list shows the share ID; hand it to your teammate.

On their machine, in their own rysh session:

##upstream shares
##upstream subscribe <shareID>

Everything your pane emits now streams into theirs, prefixed [remote:alias] so it's obvious what's local and what's remote. 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 lets your teammate 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 (there's one per session, a child of the workspace actor) spawns an UpstreamShareActor for that share. It subscribes to your pane's local shared-output stream and forwards it to a NATS subject on the upstream server:

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 subject and feeds text into their pane with the [remote:alias] prefix.

The server in the middle isn't a dumb pipe. Its NATS proxy layer enforces three things on every message: the share mode (a view-mode share hard-rejects inbound commands — it's not a client-side politeness check), the subscriber's status (you have to actually be subscribed to that share), and a command blocklist for control-mode shares. Workspaces are isolated from each other at the NATS subject level, 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 rysh-server — use ours at rysh.ai or run your own; the whole stack is self-hostable, and 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.