It performs substantially better.

just try it out. It's not the same.

There's a ONE MINUTE video showing it on the github page. It's just a single minute.

You can also try it yourself:

    $ uvx agent-cli-helper run-command vim

  <session id="vim" current-program="vim">
  <screen-capture>
     1
  ~
  ~
  ~
  ~
  ~                              VIM - Vi IMproved
  ~
  ~                               version 9.2.218
  ~                           by Bram Moolenaar et al.
  ~                   Modified by team+vim@tracker.debian.org
  ~                 Vim is open source and freely distributable
  ~
  ~                           Sponsor Vim development!
  ~                type  :help sponsor<Enter>    for information
  ~
  ~                type  :q<Enter>               to exit
  ~                type  :help<Enter>  or  <F1>  for on-line help
  ~                type  :help version9<Enter>   for version info
  ~
  ~
  ~
  ~
  ~
               0,0-1         All

  </screen-capture>
  </session>
  <instructions>
  The command has started. To send keystrokes run `agent-cli-helper send-keystrokes` followed by the id and the keystrokes. For instance:

      $ agent-cli-helper send-keystrokes vim "^X"

  Run `agent-cli-helper send-keystrokes --help` to find out the full syntax
  </instructions>
  <important>When you are done, use finish-command to finish the session. For example: agent-cli-helper finish-command vim</important>
  <random-usage-tip>If you need to see the current screen without sending keystrokes, use agent-cli-helper get-screen-capture <session-id></random-usage-tip>

* it returns the output to the stdout making it easier to loop on

* it formulates everything in fake xml so the that the agent knows the status and doesn't send weird keystrokes to the wrong command

* it includes reminders and "random-usage-tip" which is not random, it reminds the agent of how the tool behaves. The "random-usage-tip" is non-random, it is called that to make it look unrelated but it really is.

All of these things have been tested and eval'd. Calling it "screen-capture" "current-program", these have all been tested with variations for a variety of tasks/harness/model triplets.

The tool is optimized for agent usage and has been designed that way as a first principle

I agree that at first glance, it seems like tmux, or even long-running PTY shell calls in harnesses like Claude, solve this. They do keep processes alive across discrete interactions. But in practice, it’s kind of terrible, because the interaction model presented to the LLM is basically polling. Polling is slow and bloats context.

To avoid polling, you need to run the process with some knowledge of the internal interpreter state. Then a surprising number of edge cases start showing up once you start using it for real data science workflows. How do you support built-in debuggers? How do you handle in-band help? How do you handle long-running commands, interrupts, restarts, or segfaults in the interpreter? How do you deal with echo in multi-line inputs? How do you handle large outputs without filling the context window? Do you spill them to the filesystem somewhere instead of just truncating them, so the model can navigate them? What if the harness doesn’t have file tools? And so on.

Then there is sandboxing, which becomes another layer of complexity wrapped into the same tool.

I’ve been building a tool around this problem: `mcp-repl` https://github.com/posit-dev/mcp-repl

So tmux helps, but even with a skill and some shims, it does not really solve the core problem.

In the data science scenario you should just have proper tooling, for you it sounds like a REPL the agent can interface with. I do this with nREPL/CIDER; in Python-land a Jupyter kernel over MCP maybe. For stateful introspection where you don't control the tooling, tmux plus trivial glue gets you most of the way.

edit: There are much better solutions for Python-land below it seems :)

Are you aware that you can use tmux (or zellij, etc.), spin up the interpreter in a tmux session, and then the LLM can interact with it perfectly normally by using send-keys? And that this works quite well, because LLMs are trained on it? You just need to tell the LLM "I have ipython open in a tmux session named pythonrepl"

This is exactly how I do most of my data analysis work in Julia.

See related sibling: the use cases are compelling!

My complaint is that tmux handles them perfectly. Exactly the claim that OP is making with their software - is served by robust 18 year old software.

In 2026, it costs nearly nothing to thoroughly and autonomously investigate related software — so yes I am going to be purposefully abrasive about it.

What I do is have a quick command that spins up a worktree on a repo with my ghostty splits as I like them and the tmux named the worktree. I then tell the Claude code about the tmux when it needs to look. It’s pretty good at natively handling the tmux interactions.

Ideally Ghostty would offer primitives to launch splits but c’est la vie. Apple automation it is.

> I'm not going to dump tens of GB of stuff to a log file

In the same vein as the parent comment, the curiosity is why you would vibe code a solution instead of reaching for grep.

You can start a tmux session and tell your agent about it and it will happily send commands and get the output from it.

I saw this post a while ago that turned me on to the idea: https://news.ycombinator.com/item?id=46570397

The TUI makes more sense to humans who don’t understand the difference between a human and a machine.