원클릭으로
shell
Drive bash/zsh shell sessions; detect prompt vs. running command via OSC 133
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
메뉴
Drive bash/zsh shell sessions; detect prompt vs. running command via OSC 133
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
agent-tui usage — spawn, snapshot, wait, interact with PTY apps via @eN refs
Drive AI CLIs (opencode, pi, codex, claude-code, …) — auth, streaming, tool use, sessions
Selectors, refs, and targeted writes — the DOM-lite addressing model for nodes inside a pane
Drive common TUI apps — htop, less, lazygit, tig, fzf, nano — for engine-correctness coverage
Verbs grouped by what you're trying to do (ask/edit/watch/run), not by capability surface
Open files, edit, save, search in vim/nvim with adapter-aware state
| name | shell |
| description | Drive bash/zsh shell sessions; detect prompt vs. running command via OSC 133 |
| allowed-tools | Bash(agent-tui:*) |
Driving an interactive shell from an agent is the most common
agent-tui use-case. The hard problem is "is the shell at a prompt or
running a command?" — agent-tui solves this via the OSC 133
shell-integration protocol when the shell emits it, and falls back to
a heuristic when it doesn't.
This skill assumes you know the core loop (spawn / wait / snapshot / interact). It only covers what's different for shells.
agent-tui spawn -- bash -i
agent-tui wait --text '\$ ' # wait for prompt
agent-tui snapshot --mode adapter # shows `state: Shell`
The shell adapter classifies the pane state by walking the screen and
the recorder event log for OSC 133 A/B/C/D markers:
| OSC 133 | Adapter state |
|---|---|
B (prompt-start) | Shell |
C (command-start) | Running |
D (command-end) | Shell (back to prompt) |
Without OSC 133, the adapter falls back to "if the last line looks
like a prompt regex, we're at a prompt; otherwise Unknown." The
state is exposed in snapshot --mode adapter and used by
wait --state Shell / wait --state Running (P2).
agent-tui spawn -- bash -i
agent-tui wait --text '\$ '
agent-tui type "ls /tmp"
agent-tui press "<cr>"
agent-tui wait --text '\$ ' # wait for the prompt again
agent-tui snapshot # capture output
The "wait for the prompt again" pattern is robust as long as the
prompt regex doesn't appear in the command's output. For commands
that might echo prompt-like text, use wait --state Shell (P2) or a
known sentinel.
agent-tui spawn -- bash -i
agent-tui wait --text '\$ '
agent-tui type "sleep 5 && echo done"
agent-tui press "<cr>"
agent-tui snapshot --mode adapter # state: Running
agent-tui wait --text "done"
agent-tui wait --text '\$ ' # wait for return to prompt
While the command runs, the adapter reports state: Running. The
recorder also emits a Checkpoint event every 1000 PTY mutations
so the trace shows progress for long outputs.
The bash fixture in our tests sets these vars before bash -i:
PROMPT_COMMAND='printf "\e]133;D;%s\e\\" "$?"; printf "\e]133;A\e\\"'
PS1='\[\e]133;B\e\\\]\u@\h \w \$ '
Source: crates/agent-tui-integration/fixtures/bash-osc133.sh. Real
shells with shell-integration (ITerm2, VS Code terminal, modern WezTerm)
already emit these by default.