# wait_for_text

Source: https://libtmux.org/en/rs/latest/mcp/tools/wait_for_text/

> Wait until a pane writes matching text. Reads the pane's live output stream, so text that scrolls past between checks is still seen. The returned text is that raw stream, not the rendered screen: a line redrawn in place repeats; capture_pane shows the screen. Prefer run_shell_command for commands you are sending yourself: it reports an exit status instead of guessing from output. Use this for output you did not author, such as a server logging that it is ready. A line this server itself types and submits -- with send_keys, paste_text, or run_shell_command's own dispatch -- is discounted from a match for a short time afterward, so waiting for text you just sent does not match its own echo; output that happens to repeat the same words still does. A submitted line that wrapped across terminal rows when it was typed is not discounted. A pattern still on the row being typed into, not yet submitted, reports outcome pending instead of matched, and one already on a completed row before this call attached reports present_at_entry. Waiting owns an observer client until the wait ends. Each list accepts at most 32 patterns, each at most 4,096 bytes, using Rust's linear-time regex engine. Read pane output; accepts no client-supplied executable input. Returned content may be sensitive or untrusted.

MCP is in development

Server behavior and tool contracts may change. Tool availability depends on the server configuration.

Wait until a pane writes matching text. Reads the pane’s live output stream, so text that scrolls past between checks is still seen. The returned text is that raw stream, not the rendered screen: a line redrawn in place repeats; [capture\_pane](https://libtmux.org/en/rs/latest/mcp/tools/capture_pane/) shows the screen. Prefer [run\_shell\_command](https://libtmux.org/en/rs/latest/mcp/tools/run_shell_command/) for commands you are sending yourself: it reports an exit status instead of guessing from output. Use this for output you did not author, such as a server logging that it is ready. A line this server itself types and submits — with [send\_keys](https://libtmux.org/en/rs/latest/mcp/tools/send_keys/), [paste\_text](https://libtmux.org/en/rs/latest/mcp/tools/paste_text/), or [run\_shell\_command](https://libtmux.org/en/rs/latest/mcp/tools/run_shell_command/)’s own dispatch — is discounted from a match for a short time afterward, so waiting for text you just sent does not match its own echo; output that happens to repeat the same words still does. A submitted line that wrapped across terminal rows when it was typed is not discounted. A pattern still on the row being typed into, not yet submitted, reports outcome pending instead of matched, and one already on a completed row before this call attached reports present\_at\_entry. Waiting owns an observer client until the wait ends. Each list accepts at most 32 patterns, each at most 4,096 bytes, using Rust’s linear-time regex engine. Read pane output; accepts no client-supplied executable input. Returned content may be sensitive or untrusted.

[All Rust tools](../) · [JSON](../wait_for_text.json) · [Source](https://github.com/libtmux/libtmux-rs/blob/f0e37052c232636b61d095817046e6bfc8f2ca40/crates/tmux-mcp/src/tools/observe.rs#L344)

## Arguments

* `match_case` optional · boolean

  Match case. Off by default.

  Default: `false`.

* `pane` required · string

  The \`%\`-prefixed pane to watch.

* `patterns` optional · array | null

  Text that ends the wait successfully. Omit to wait for any output.

* `regex` optional · boolean

  Read both lists as regular expressions rather than literal text.

  Default: `false`.

* `seconds` optional · integer | null

  How long to wait, in seconds. Defaults to 30, capped at 600.

* `stop` optional · array | null

  Text that ends the wait as a failure, reported as \`stopped\`. Omit for none. Give the failure markers you already know — \`error:\`, \`Traceback\` — and a failed run returns at once instead of at the deadline.

## Schemas

The schema defines required fields, nested values, defaults, and validation constraints.