3 Fixes for Interactive CLI Agents

Interactive CLI agents fail silently because most agent harnesses cannot read terminal redraw loops as prompts. The practical fixes are to drive the terminal with tmux, expose a structured IPC side channel that returns JSON, or inject options and constraints as explicit context. Each approach keeps the CLI deterministic while giving the agent enough state to walk a decision tree. The trade-off is latency, complexity, and how much of the human interface you duplicate for machine readers.

Why Interactive CLI Agents Break Silently

Interactive CLI agents break because the harness cannot read an arrow-key prompt as a question, so the run fails with no error, no exit code, and no log line. The human sees options and a Cursor; the agent sees a terminal redraw loop and loses the interface state entirely.

Mark Lummus, head of developer tools at PayPal, framed the failure in a workshop at the AI Engineer conference in 2025, titled "Burn Your Flags: Interactive CLIs for Agents." Agents shell out to Bash constantly and that works. The trouble starts when the command they shell out to is interactive, because not every harness handles interaction well. When it does not, the process does not crash. It just stops making progress, and nothing tells you.

The failure is easy to reproduce. Run an interactive coffee-ordering CLI from an agent and watch it sit in the prompt. The CLI is working correctly. The agent is waiting for a shape of output it never receives.

Lummus put the history in perspective: command-line interfaces were the only interface in the MS-DOS era before Microsoft Windows, and the resurgence of CLIs is recent, driven by tools like Claude Code and the AI-first editors that followed. See the full workshop recording for the original framing.

Why Interactive CLI Agents Matter

Interactive flows exist because the next question depends on the previous answer. That is exactly what flags cannot express. When you try to predict every possible sequence with flags, the flag space multiplies combinatorially.

Interactive CLIs excel for three reasons Lummus gave in the workshop:

• The next question can emerge from the previous answer, so the flow is contextual.
• Questions can respond to the environment, such as the result of an API call, instead of being fixed up front.
• Guardrails and guidance live inside the flow rather than being re-specified by every caller.

Flags are fine for simple cases: known flows, a single pass, independent options. That is a genuinely good use case for a simple flag. The problem starts when answers change based on context or on real-time events. An automation script is worse still, because it knows nothing and every decision is pre-baked. An agent can reason, react, ask, retry, back up, and most importantly walk a decision tree if you provide one.

How Interactive CLI Agents Compare with Flags, Scripts, and Tmux

Interactive CLI agents differ from flag-driven and script-driven automation in one respect: the agent can walk a decision tree instead of executing a pre-baked sequence. Flags work when inputs are independent and the path is known up front. They multiply when you try to predict every branch.

The table below compares the four approaches discussed in the workshop. None of them is a universal replacement for the others; each fits a different shape of problem.

Approach	What the agent reads	Best fit	Main limitation
Command flags	Parsed arguments	Independent inputs, known path	Combinatorial blow-up on branching flows
Automation script	Nothing; decisions are fixed	Deterministic pipelines	Cannot adapt to live responses
tmux session	Captured pane text	Getting an existing interactive CLI moving	Screen scraping, fragile output
IPC side channel	Structured JSON	Machine-readable state and input	Extra surface to build and maintain

The distinction that matters is reasoning versus execution. An automation script knows nothing and every decision is baked in. An agent can ask, retry, back up, and follow a branch if the tool gives it one. Flags do not give it one.

The Accessibility Analogy Behind Agent-Friendly CLIs

Agent-friendly CLIs reuse the discipline of accessibility: describe the same underlying operation to a reader that cannot see the visual interface. Lummus called it the same discipline with a new reader, which is why the fixes look like a parallel interface rather than a new tool. The web platform made the same move when it added WAI-ARIA, a machine-readable description layer sitting beside the visual page for screen readers.

The design question he posed was how to keep the guardrails and guidance while stopping the pretense that agents and humans have the same abilities. Interactive flows already contain the choices, constraints, and guidance an agent needs. The work is exposing them in a form the agent can consume. Lummus deliberately called the fixes "good ideas" rather than best practices, because the field is early enough that nobody has settled on a standard.

Navinkumar Patil, tech lead for the developer tools team at PayPal, described the two personas explicitly. Earlier CLIs served human beings only. Now the same CLI has to serve a human who wants a short list of options and an agent that can accept all the fields in a single machine-readable input. Patil traced the tooling arc from Eclipse and IntelliJ to JetBrains, then Microsoft VS Code and the AI-first editors like Cursor and Windsurf noted that CLIs stayed constant through all of it.

Fix 1: Drive Interactive CLI Agents with tmux

tmux is the lowest-effort fix for interactive CLI agents: run the CLI inside a tmux session, send keys to the pane, and capture the pane contents to read state back. The workshop presented it as the first good idea because it requires no change to the CLI itself.

The mechanics are three commands:

1. tmux new-session -d starts a detached session, so the CLI runs under its own tmux instance.
2. tmux send-keys delivers input to the pane.
3. tmux capture-pane -p returns the visible text so the agent can read state.

Patil also pointed at tmux's session logging: tmux records what each session is working on and can resume those sessions later, which lets an agent pick up a long-running task rather than restarting it. For multi-agent work, each agent can get its own session, and tmux becomes the meeting point between them.

The cost is that tmux is screen scraping with better tooling. The agent reads rendered text, so any layout change, color code, or wrapped line can change what it sees. That fragility is why the workshop treated tmux as a starting point rather than the destination.

Fix 2: Expose an IPC Side Channel with Structured JSON

An IPC side channel gives the agent structured JSON instead of rendered terminal text. Patil's analogy was direct: think of it as adding a REST API to a web application. The website gives humans a visual interface; the API gives machines a structured one. Read state and send input become data operations rather than screen interpretation.

Side channels turn the interactive operations into data. Reading state, sending input, and querying available choices become calls that return JSON, and arrow-key navigation stops being something the agent has to infer from a screen. Patil's framing for the design was to name the fields, the permitted values, and the defaults explicitly, so the agent is not guessing which of five sizes is the default. In the workshop example, the machine-readable call accepts fields like size with permitted values small, medium, and large, and a stated default of large.

The extra surface is real. You now maintain a machine interface alongside the human one, and the two have to stay in agreement as the CLI evolves.

Fix 3: Inject Context So Interactive CLI Agents See Constraints

Context injection means handing the agent the options, constraints, and situational facts up front instead of hoping it discovers them mid-flow. Patil's example was inventory: if only two gallons of oat milk remain, the agent should know that before it takes the order.

The same injected context can carry instructions the CLI cannot express in a prompt, such as confirming whether a two-ounce pour is acceptable or offering a backup choice when the preferred one is unavailable. Those scenarios do not exist in the human-only case, which is why the context has to describe them for the machine reader. Patil's summary of the principle: same prompt, different brain. Do not hand the agent what the human sees; hand it what its own abilities can use.

Together the three fixes describe a progression from reading pixels to reading data: tmux scrapes the screen, side channels publish structured state, and context injection supplies the situational knowledge neither of the other two carries.

What the Barista 9000 Leaderboard Measurably Rewarded

The workshop's challenge was a coffee-ordering CLI called Barista 9000. Participants modified the provided CLI from the PayPal cafe repository, ran it through an agent, and watched scores update on a shared leaderboard. The winner took home a Mac Mini.

The scoring rewarded low latency on a completed order, and it showed quickly that the metric favored throughput over reasoning. Multiple entrants reached a full three-of-three completion in zero seconds, which the organizers said should not have been possible. The leaderboard showed a cluster of entrants in the 4,000 range, and one participant closed in on 5,000.

An audience member described the exploit plainly: a deterministic parser plus a process close to the scoring server drives latency down, which defeats the intended challenge without solving the underlying interface problem. Lummus accepted the critique and drew a general lesson from it. A CLI used as a tool by a language model should be deterministic, because the model is the non-deterministic element in the pair. He called the ideal CLI "a small sharp instrument": every command should produce the same response every time. He argued against building an agent inside the CLI and then handing that CLI to another agent, because you do not know what you will get back.

The winning entry, built by a participant named Bonk, was an agent built on the Claude agent SDK. It was given an evaluation-bench skill that created an environment and optimized against it, and it built a deterministic CLI solver that then ran under tmux against the challenge API. The top result shared on stage was a 29 millisecond response, which the entrant attributed to running in the same region as the server rather than to any modeling advantage. The organizers had planned to break ties by time: highest score first, fastest response second, so an accurate response returned quickly would beat an accurate response returned slowly.

A second entrant had never written CLI code by hand, described themselves as a vibe coder, and used Claude Code inside VS Code to read the problem, fix it, and explain the fix. That entrant reached 49.98 seconds on one script, copied it, and asked the agent for suggestions to get to 49.99.

The organizers' own guidance was to try cheaper, faster mid-tier models rather than spending maximum reasoning tokens on a CLI that mostly wants deterministic output. Their argument was about token budgets: teams are watching their budgets, and burning the highest thinking mode on a tool run is wasteful.

A recurring caveat sits on top of these results. Scores from an event leaderboard describe that leaderboard's scoring, its network, and its server placement. They are not an independent benchmark of interactive CLI agents in general.

Making an Interactive CLI Understand an Agent

The practical recipe from the workshop has three parts: give the agent good context, expose a side channel, and tell it to use tmux. The order matters less than the combination, because each addresses a different gap.

A few decisions follow from that:

• Keep the CLI deterministic and push reasoning into the agent.
• Publish a help command that describes the machine interface. Agents lean on the help command before they try anything else, which makes it the first thing they read.
• Identify what the competition or the workflow actually measures before optimizing against it, because the Barista 9000 leaderboard showed how easily a scoring rule can be satisfied without solving the problem.
• Keep any added machine interface in sync with the human one. A side channel that drifts from the interactive flow is worse than no side channel, because the agent will follow the stale contract confidently.

Frequently asked questions

What are interactive CLI agents?

Interactive CLI agents are AI agents that invoke command-line tools which expect user interaction, such as arrow-key menus or follow-up prompts, rather than only flags and arguments. They break when the agent harness cannot read the terminal prompt as a question, causing a silent failure with no error output.

Why do agents fail on interactive CLIs without an error?

The harness sees a terminal redraw loop rather than a rendered question, so it has nothing to respond to and no exception to raise. The run stalls, the interface state is lost, and the process may simply hang or exit without reporting a problem.

When should you use flags instead of an interactive flow?

Flags fit simple cases where you know the flows up front, the path is single-pass, and the options are independent. They become awkward when later questions depend on earlier answers, on live API responses, or on conditions in the environment.

What does tmux give an agent?

tmux lets the agent start a detached session, send keys to it, and capture the pane text to read state. It works without changing the CLI at all, but the agent is reading rendered output, so layout changes and formatting can alter what it perceives.

What is an IPC side channel?

A side channel is a machine-readable interface alongside the human one, typically returning JSON for state reads and input sends. Patil compared it to adding a REST API to a website, with the website serving humans and the API serving machines.

What is context injection?

Context injection supplies the agent with options, constraints, and situational facts before it acts, such as how much of an ingredient remains in stock. It carries information an interactive prompt would not naturally surface for a machine reader.

Should the CLI itself be agentic?

No. Mark Lummus argued the CLI should be deterministic and the language model should carry the non-determinism. Building an agent into the CLI and then handing that CLI to another agent makes the output unpredictable.

Do event leaderboard scores measure real CLI performance?

No. The Barista 9000 scores reflected one scoring rule, one event network, and one server placement. Several entrants reached zero-second completions, which the organizers confirmed should not have been possible under the intended rules.

What was the Barista 9000 prize?

The workshop offered a Mac Mini to the winner of the coffee-ordering CLI challenge. Participants modified the provided CLI, ran it through an agent, and watched their scores update on a shared leaderboard.

What model won the Barista 9000 challenge?

The winning entry ran on Opus 4.8 through the Claude agent SDK, driven over tmux. The organizers still recommended testing faster mid-tier models first, since the CLI itself was deterministic and the agent only had to drive it.

Source video

Turning a workshop talk into a written article

The session's core lesson is that a machine reader needs the same operation described in a form it can parse, whether that reader is a screen reader or an agent harness. If you have recorded talks, interviews, or explanations where the same idea deserves a written reach, that knowledge is already sitting inside the video. Skala Blog takes a YouTube URL, transcribes it, and turns it into a structured article you can publish.

If you want to go deeper on the stack behind that workflow, CrazyStack is the place to look. The same kind of build-focused teaching shows up in Gustavo Dev Doido content and in courses like Crazystack Typescript and the Bootcamp do Dev Doido, where agents, CLIs, and TypeScript tooling are covered as working systems rather than theory.