`##pane listen`: when one pane watches another work

One command subscribes a pane to another pane's output streams. It's tail -f for conversations — and the primitive agent teamwork is built on.

Unix got composition right once, forty years ago: small programs, connected by streams. build | tee | grep. The pipe made processes composable.

Then we built terminal multiplexers and forgot the lesson. Panes sit side by side for decades, perfectly isolated, sharing nothing but your attention. tmux's best offer is pipe-pane dumping raw bytes to a file — a fire hose and a bucket.

Rysh panes aren't just shells; they're conversations with agents in them. So rysh gives them the pipe they deserve:

##pane listen <id|alias>    # subscribe this pane to another pane's output
##pane unlisten             # stop

Type it in any pane, name any other pane (panes have given-names — Ctrl+P r or ##pane name — so it's ##pane listen builder, not a UUID hunt). From then on, the target's output flows into your pane, live.

tail -f, but for a colleague's work. Including when the colleague is an AI.

What actually flows

When you run ##pane listen, a listener actor is spawned under your pane. It subscribes to the target's output streams one mode at a time — shell, AI, chat, ## system output, external — plus their history, and republishes what arrives into the matching streams of your pane. That's why the work shows up live, and why it stays sorted: the target's AI answers land in your AI stream, its shell output in your shell stream.

Be clear about what this is: observation, not a security boundary. The listener reads the same output the source pane shows, raw output included, and nothing on this path redacts it. Treat listening like looking over someone's shoulder — only listen to panes whose output you'd be fine seeing on your own screen. ##pane unlisten ends it at any time.

The morning this becomes indispensable

Watching a long-running agent without babysitting it. Your deploy pane runs a slow, chatty rollout. In your main working pane: ##pane listen deploy. Keep coding; the rollout narrates in your margin. ##pane unlisten when it's boring again. No pane-hopping, no split you'll forget to close.

Watching an agent work, not just its summary. Put the builder agent in one pane and run ##pane listen builder from another. Every prompt, tool step and answer the builder produces streams into the second pane as it happens — you see the work, not a summary pasted in afterwards. That second pane is the natural seat for a reviewer, human or agent, and the transport that pipeline events build on.

One ops pane following a stack. Point a pane at the service pane you care about right now and it narrates in your margin; ##pane unlisten, then listen to the next one. (A pane listens to one source at a time; a new listen replaces the old one.)

Events ride the same stream

listen has a second life: it's the transport for rysh's pipeline events. Lines beginning with ##> bypass the PTY entirely and are published as clean event lines on the source's output.

The listener actor treats them specially instead of just displaying them:

• ##>event:print:<payload> — forwards the payload into the listening pane, clean.
• ##>event:ai:softdev:<language>:<phase> — triggers the listening pane's agent with the prompt for that phase.
• ##>event:sh:softdev:<language>:<phase> — runs the phase's mapped shell command in the listening pane (for Go's unit_testing phase: go test -v ./...).

One honest limit: the listener has a 50 KB context buffer meant to carry the source's recent output along with a triggered prompt, but as the code stands, ordinary output doesn't reach that buffer. Don't count on the triggered agent having seen the preceding work.

Subscribe to a colleague, and their milestones can become your triggers. That's an assembly line, built from two panes and one command — the full version of that story is the pipeline events article.

Composition, rediscovered

The actor plumbing is invisible but worth one sentence: listening is a subscription on the session's message bus, not a UI hack — which is why it works between panes in different tabs, and why a restored pane picks its subscription back up after a daemon restart.

Panes that can watch panes turn a multiplexer from a grid of isolated screens into a graph of connected workers. Unix composed processes with pipes. Rysh composes conversations with subscriptions — revocable, and one command long.

Correction (2026-09-28): an earlier version of this article said listening panes see only a redacted .sharedOutput stream, that credentials are redacted at the source, that ##private keeps output away from listeners, and that local listening and ##share share one trust boundary. None of that matches the code: the listener subscribes to the source's output streams directly, raw output included, and nothing on that path redacts. It also said triggered agents receive the source's recent output as context, that output streams into a reviewer agent's context, and that listening costs nothing when idle; none of those is verified. Those lines have been removed or corrected.

Rysh is early. If "a reviewer agent that watches the builder" sounds like your team's next workflow, become a design partner: rysh.ai/design-partner

Related: Pipeline events: an assembly line out of panes · Four output streams per pane