Sending Input to Another tmux Pane Safely
Slam Buttons places two large red arcade buttons on a cream plate. A button can invoke a narrow tmux script, but sending an answer into a background agent pane should never be treated as blind approval.
How does tmux send-keys choose a pane?
The send-keys command accepts a target pane and sends input as though it had been typed there. Use a full target containing session, window and pane rather than whichever pane happens to be active. Window names need not be unique, and indexes can change, so resolve and verify the target when the script runs.
tmux treats recognized arguments such as Enter as key names. Its literal flag sends text without interpreting those names. Keep literal content and the final Enter as separate steps so the script can stop for review between them.
How can a physical button invoke it?
Make the button emit a spare key, then let a user-level hotkey call a fixed wrapper script. The wrapper checks that the tmux server, session and pane exist, captures a small amount of visible pane content and refuses to continue unless the target matches a narrow expected state.
Do not place shell fragments or arbitrary dictated text in the command. Use a single harmless response whose meaning is stable, and log the time, target and exact input.
When is answering a background pane safe?
Almost never when the answer grants permission, changes files, runs a command or accepts a plan. Switch to the pane and read the full request. A background button is more defensible for sending a non-submitting character, waking a known monitoring process or marking attention without changing agent authority.
A yes-or-no prompt can change between capture and submission. Text visible a moment earlier is not a transaction lock, so state checking reduces mistakes but cannot make blind approval safe.
How do you confirm the input landed?
After sending literal text, select the target pane or capture its updated contents and display them. Only a second deliberate action should send Enter, and that action should occur with the pane visible. If the expected text is absent, stop rather than retrying automatically.
The Slam Buttons makes two actions easy to strike, which increases the need for a safe boundary. Use one button to focus the target and leave the other unbound until a visible, reversible workflow has passed repeated tests. Test against a shell that only echoes input, not an agent or production process. Change the pane index deliberately and confirm the wrapper refuses the new target. A useful guard must fail closed when names, paths or visible state differ.