The idea
Allow multiple clients to attach to the same session simultaneously, while preserving native terminal scrollback (shpool's killer feature).
Why this doesn't exist yet
Today, tools force a choice:
- shpool: native scroll, but single client
- tmux/screen/zellij: multi-client, but virtualized screen (no native scroll)
The reason is typically that multi-client requires a virtual terminal to sync screen state across clients. But shpool's architecture as a thin PTY proxy opens a different path.
Proposed architecture
Shell → PTY → shpool daemon
├→ Client A (input + own scroll buffer)
└→ Client B (input + own scroll buffer)
- Input: all clients send keystrokes to the same PTY stdin (shell doesn't care who's typing)
- Output: daemon fans out the PTY output stream to all connected clients
- Scrollback: each client's terminal emulator buffers independently — no virtual terminal needed
- No virtual screen: shpool stays a thin PTY proxy, native scroll preserved
Design challenges
| Problem |
Possible approach |
| Window size conflict (clients have different dimensions) |
Use smallest common size, or let each client handle overflow locally |
| Input interleaving |
Accept it (same as tmux shared sessions — users coordinate) |
| Output fanout |
Buffer per-client with backpressure so a slow client doesn't block others |
| Disconnect handling |
One client dropping shouldn't affect others or the session |
Why shpool specifically
This fits shpool's philosophy — minimal session persistence without a full multiplexer. Multi-client attach would make shpool useful for pair programming and monitoring, without sacrificing native scroll.
No other tool offers this combination today.