Sending long prompts to terminal agents safely with tmux paste-buffer

Short agent prompts are easy to automate with terminal keystrokes. Long prompts are different. They contain newlines, code fences, quotes, markers, and enough bytes that a terminal app may switch into paste handling or queued-input behavior. If you inject that content one character at a time, the target can look correct while never actually processing the message.

The failure mode

The typical script uses tmux send-keys -l for literal input, then sends a submit key. That means tmux emits a stream of key events. A terminal UI can render the text in its input area, but the submit event may arrive while the app is still parsing, wrapping, or queuing the paste-like content.

tmux send-keys -t %3 -l "$LONG_PROMPT"
tmux send-keys -t %3 C-m

A superficial verification step might confirm that keystrokes were sent, or that the pane no longer shows the exact same prompt. That is not the same as confirming the agent accepted and began processing the message.

Use tmux's native paste path

tmux already has an atomic buffer path. Load the prompt into a tmux buffer, paste that buffer into the pane, then send the submit key after a short delay. The target sees a paste event instead of thousands of individual key events.

tmp="$(mktemp)"
printf '%s' "$LONG_PROMPT" > "$tmp"
tmux load-buffer "$tmp"
tmux paste-buffer -t %3
sleep 0.5
tmux send-keys -t %3 C-m
rm -f "$tmp"

If the target application uses a special submit sequence, keep that knowledge in one helper script. The important change is the content transport: buffer paste for long prompts, simple key injection for short prompts.

Pick an automatic threshold

A dispatcher should not ask operators to remember which path to use. Promote automatically when the prompt crosses a byte or line-count threshold. A good starting point is ten lines or 500 bytes.

if [ "$(printf '%s' "$text" | wc -c)" -gt 500 ] ||
   [ "$(printf '%s' "$text" | wc -l)" -gt 10 ]; then
  send_with_paste_buffer "$pane" "$text"
else
  send_with_keys "$pane" "$text"
fi

Verify acceptance, not emission

The robust check happens after submit. Capture the pane and look for evidence that the input area is empty, a run started, or the agent emitted a fresh response. The exact signal depends on the tool, but the principle is universal: the sender should verify application acceptance, not just transport success.

This pattern is small, but it changes reliability dramatically for agent teams. Long briefs become regular work instead of a source of silent drops.