Broadcast Input

Broadcast mode lets you type in one terminal and send every keystroke, live, to a whole group of sessions at the same time. Run apt update && apt upgrade once and watch it type itself into all eight of your web servers simultaneously. It is the fastest way to do the same thing on many machines without a full workflow or an automation script.

Think of it like a conductor: you play the part once, and the whole section plays it together.

Broadcast is a desktop feature — it lives in the pill bar and works with the desktop tab / split-pane layout.

Turning broadcast on

There are three ways to enable it, and they differ in scope — which sessions receive your keystrokes.

How	Scope	When it shows
Broadcast chip in the pill bar (the radio icon)	The sessions in the current group — i.e. the terminals in the active tab’s split layout	Appears only when the active group has 2 or more live terminals
Ctrl+Shift+B	All connected (and connecting) sessions	Always
Command palette -> “Enable Broadcast Mode”	All active sessions	Shown when there are 2+ active sessions

The pill-bar chip turns orange while active and shows a count badge — for example a “3” means your keystrokes are reaching three terminals in the group. Broadcast panes also get an orange border, and the desktop status bar shows a “Broadcast (N)” indicator so it is always obvious that the mode is on.

The Ctrl+Shift+B shortcut is rebindable — see Keyboard Customization.

How the fan-out works

Broadcast sends your input live, one character at a time, not as a batch when you hit Enter. Here is the sequence:

1. You type into the focused pane. Those keystrokes go to its own shell as normal.
2. ZestSSH also writes the same bytes to every other connected target in the group.
3. By the time you press Enter, all the target shells already have the full command sitting at their prompt.
4. The newline is what actually executes it — on the focused pane, and (subject to the safety check below) on every target.

A few rules keep this predictable:

• Keystrokes never echo back to the pane you are typing in.
• Only connected targets receive input — a disconnected or reconnecting pane is skipped.
• Fan-out only happens from a pane that is itself a broadcast target. If you switch to a different group tab while broadcast is still armed for another group, typing in the new pane does not broadcast to the old group.

The destructive-command confirmation

This is the part that makes broadcast safe to use on more than a demo box.

When Dangerous Command Protection is enabled (it is a setting, on by default), ZestSSH watches the command line you are broadcasting. If a submitted line matches a destructive pattern — rm -rf /, mkfs, dd of=/dev/..., a fork bomb, chmod -R 777, piping a download into a shell (curl ... | sh), shutdown / reboot, and more — the Enter’s fan-out is held and a confirmation dialog appears before the command runs on the group.

That dialog is deliberately different from an ordinary confirm:

• It shows the exact command and why it was flagged.
• It lists every target host by name — the full blast radius, not just a count — so you can see exactly which machines are about to run it.
• The confirm button is click-only and nothing is autofocused, so the very Enter you just pressed to submit the command cannot also confirm the dialog. Cancelling is the easy path: Escape, click the backdrop, or press Cancel.

Two important details:

• The focused pane already ran the command — it was typed there in real time. The confirmation only gates multiplying the command across the other hosts.
• If you cancel, the targets are left with the command typed but un-executed at their prompts, and ZestSSH immediately sends Ctrl-U to wipe the line so a stray later keystroke cannot detonate it.

It also holds up against pastes: every line in a multi-line paste is checked, so a benign first line cannot smuggle an rm -rf on line three past the classifier. And if there is somehow no UI available to confirm through, broadcast fails closed — it will not fan a destructive command out unconfirmed.

Using broadcast in ZestSSH

1. Open the servers you want to operate on as sessions in one group (tabs split into panes, or simply several connected sessions).
2. Enable broadcast — the pill-bar chip for just the current group, or Ctrl+Shift+B for all active sessions.
3. Confirm the orange borders / count badge show the machines you expect.
4. Type your command. Watch it appear across the group.
5. Press Enter. For an ordinary command it runs everywhere at once; for a flagged destructive command, review the named-target dialog and confirm only if the blast radius is right.
6. Turn broadcast off with the same toggle when you are done.

Common mistakes — read this before you broadcast to prod

Broadcast is a power tool, and the classic disaster is running a command on a machine you did not mean to include. Treat every target in the group as “will definitely execute this.”

• Broadcasting to production by accident. If a prod box is in the group, it gets the command exactly like the rest. Do not mix prod into a broadcast group you use for bulk changes. Build a separate group containing only the machines you intend to batch, and double-check the count badge and orange borders before you press Enter.
• Forgetting it is on. The orange borders and the “Broadcast (N)” status indicator are your cue. A command you thought was going to one host is going to all of them. Disable broadcast the moment you finish the batch.
• Trusting the destructive-command check to catch everything. It matches a known set of dangerous patterns — it is a backstop, not a guarantee. An app-specific destructive command (terraform destroy, DROP TABLE, a script with a typo’d path) will not be flagged. You are still responsible for what you send.
• Turning off Dangerous Command Protection. Disabling that setting also removes the broadcast named-target confirmation. Leave it on.
• Driving interactive TUIs with broadcast. Fan-out is raw keystrokes. Programs that depend on per-host prompts, menu positions, or output timing (an interactive installer, vim navigation) can diverge between hosts. Broadcast shines for plain commands, not curses apps.

Free tier vs Pro

Broadcast is not itself a paid feature, but it needs more than one session to be useful, and concurrent sessions are capped on the free tier.

	Free	Pro (Squeezed)
Broadcast input	Yes	Yes
Destructive-command confirmation	Yes	Yes
Concurrent sessions to fan out to	Up to 4 on desktop / 2 on mobile	Unlimited

Larger fleets — broadcasting to a dozen servers at once — need Pro’s unlimited concurrent sessions.

Next steps

• Split Terminal — arrange the group of panes you want to broadcast into.
• Workflows — when you need ordered steps, failure handling, and logging rather than raw simultaneous input.
• Snippets — reusable commands (with their own confirm-before-run flag) to broadcast consistently.
• Server Monitor — spot the fleet-wide problem first, then broadcast the fix.