automatically control and record tui application sessions from the terminal
93
94%
Does it follow best practices?
Impact
89%
4.45xAverage score across 3 eval scenarios
Risky
Do not use without reviewing
Before using virtui, ensure it is installed and the daemon is running.
# Check if virtui is available
virtui versionIf not installed, install via Homebrew:
brew install honeybadge-labs/tap/virtuiThe daemon must be running before any session commands. Always check first:
virtui --json daemon status
# → {"running":true,"socket":"..."} or {"running":false,"socket":"..."}If not running:
virtui --json daemon start
# → {"pid":1234,"socket":"/Users/you/.virtui/daemon.sock"}The daemon manages sessions over a Unix socket at ~/.virtui/daemon.sock.
The typical workflow is: start daemon → run session → interact → screenshot → kill session.
virtui --json run <command...>This returns a session_id you'll use for all subsequent commands. Common options:
| Flag | Default | Purpose |
|---|---|---|
--cols | 80 | Terminal width |
--rows | 24 | Terminal height |
--dir | cwd | Working directory |
-e KEY=VAL | Environment variables (repeatable) | |
--record | off | Record session as asciicast v2 |
--record-path | auto | Custom recording path |
Example:
virtui --json run --cols 120 --rows 40 bash
# → {"session_id":"a1b2c3d4","pid":1234,"recording_path":""}exec is the primary interaction command. It types input, presses Enter, and optionally waits
for a screen condition before returning.
Claude Code note: The Bash tool strips trailing newlines from command arguments, so
execmay not actually send Enter when called from Claude Code. Prefer usingtype+press Enteras separate steps (or use apipeline) to guarantee Enter is sent. See the Pipeline section for a concrete example.
Wait-condition caveat: Wait conditions check the screen immediately after input is sent. If the target text already appears on screen (e.g., in the typed command itself), the wait can resolve in 0 ms — before the command's actual output appears. For reliable results, use a
pipelinewith separatetype→press Enter→waitsteps, or followexecwith a standalonewaitcommand.
virtui --json exec <session_id> "<input>" [wait flags]Wait strategies (use exactly one, or none to return immediately with current screen state):
| Flag | When to use |
|---|---|
--wait "text" | Wait for specific text to appear on screen |
--wait-stable | Wait for screen to stop changing (500 ms of no updates — does not guarantee the process finished) |
--wait-gone "text" | Wait for text to disappear (e.g., a loading spinner) |
--wait-regex "pattern" | Wait for a regex match on screen |
--timeout <ms> | Override default 30s timeout (use with any wait flag) |
Examples:
# Run a command and wait for its output
virtui --json exec $SID "echo hello" --wait "hello"
# Run a build and wait for screen to settle (500ms of no changes)
virtui --json exec $SID "make build" --wait-stable --timeout 60000
# Wait for a loading indicator to disappear
virtui --json exec $SID "npm install" --wait-gone "resolving" --timeout 120000Read the current screen contents at any time:
virtui --json screenshot <session_id>
virtui screenshot <session_id> --no-colorReturns screen_text, screen_hash, screen_ansi, cursor position, and terminal dimensions.
Use screen_hash for cheap change detection without comparing full screen text.
screen_text for plain text assertions and screen-diff logic.screen_ansi when color, background color, bold, underline, or reverse video matter.virtui screenshot --no-color <session_id> when you want plain text output in non-JSON mode
without ANSI escape sequences.For interactive TUI applications (menus, editors, prompts), use press and type:
# Send special keys
virtui press <session_id> Enter
virtui press <session_id> Ctrl+C
virtui press <session_id> ArrowDown --repeat 5
virtui press <session_id> Escape q # multiple keys in sequence
# Type text without pressing Enter (for search fields, partial input)
virtui type <session_id> "search query"See references/keys-and-errors.md for the full list of available key names and error codes.
Wait independently of exec (useful after press/type or for polling):
virtui --json wait <session_id> --text "Ready"
virtui --json wait <session_id> --stable
virtui --json wait <session_id> --gone "Loading..."
virtui --json wait <session_id> --regex "v\d+\.\d+"Always kill sessions when done:
virtui kill <session_id>List active sessions:
virtui --json sessions show
# → {"sessions":[{"session_id":"a1b2c3d4","pid":1234,"command":["bash"],"cols":80,"rows":24,"running":true,"exit_code":-1,"created_at":"1711900000","recording_path":""}]}Resize the terminal dimensions of a running session. Both --cols and --rows are required
(unlike run, there are no defaults):
virtui resize <session_id> --cols 120 --rows 40For complex multi-step interactions, use pipeline to send a batch of steps in one call.
Recommended for Claude Code: Because
execrelies on Enter being sent and Claude Code's Bash tool can swallow trailing newlines, the most reliable pattern from Claude Code is to use a pipeline with explicittype+press Entersteps instead ofexec.
echo '{"steps":[
{"type":{"text":"echo hello world"}},
{"press":{"keys":["Enter"]}},
{"wait":{"condition":{"text":"hello world"},"timeout_ms":5000}},
{"screenshot":{}}
],"stop_on_error":true}' | virtui --json pipeline $SIDThis is equivalent to virtui exec $SID "echo hello world" --wait "hello world" but
guarantees Enter is actually sent regardless of how the shell tool handles newlines.
Instead of piping JSON via stdin, you can pass a file containing the steps:
virtui --json pipeline <session_id> --file steps.jsonecho '{"steps":[
{"exec":{"input":"ls","wait":{"text":"README"}}},
{"sleep":{"duration_ms":500}},
{"screenshot":{}},
{"press":{"keys":["Ctrl+C"]}}
],"stop_on_error":true}' | virtui --json pipeline <session_id>Step types: exec, press, type, wait, screenshot, sleep.
The pipeline returns a JSON object with a results array. Each entry contains the step
outcome and a screenshot of the screen state at that point:
{
"results": [
{
"step_index": 0,
"success": true,
"error_message": "",
"screenshot": {
"screen_text": "...",
"screen_hash": "...",
"screen_ansi": "...",
"cursor_row": 4,
"cursor_col": 10,
"cols": 80,
"rows": 24
}
}
]
}Record sessions as asciicast v2 (playable with asciinema play):
virtui --json run --record bash
# or with a custom path:
virtui --json run --record --record-path ./demo.cast bashRecording stops when the session is killed or the process exits.
Note:
--record-pathrequires--recordto be set. Using--record-pathalone will not enable recording.
--json (or -j) for machine-readable output with session_id, screen_text, screen_hash, screen_ansi, etc.int64 fields (elapsed_ms, created_at) are serialized as strings.screen_hash (SHA-256) for cheap change detection without comparing full screen text.screen_text for text matching and screen_ansi only when TUI state depends on styling or color.--timeout 120000.screenshot to see current state and decide how to proceed.code, category, message, retryable, suggestion — check retryable before retrying.
See references/keys-and-errors.md for error codes and key names.| Command | Key Fields |
|---|---|
run | session_id, pid, recording_path |
exec | screen_text, screen_hash, cursor_row, cursor_col, elapsed_ms |
screenshot | screen_text, screen_hash, screen_ansi, cursor_row, cursor_col, cols, rows |
press | screen_text, screen_hash |
type | screen_text, screen_hash |
wait | screen_text, screen_hash, elapsed_ms |
kill | ok |
resize | ok |
pipeline | results[]: step_index, success, error_message, screenshot (see Pipeline output format) |
sessions | sessions[]: session_id, pid, command, cols, rows, running, exit_code, created_at, recording_path |
daemon start | pid, socket (background) or socket (foreground) |
daemon stop | ok, optionally message |
daemon status | running, socket |