31–40 of 44 posts
No installation is necessary.
Simply tell your agent to run uvx agent-cli-helper and that's it.
The verbiage and flow is optimized through test harnesses to maximize effectiveness for agentic use.
https://github.com/day50-dev/acli
(Sorry: my marketing and and pitch skills are trash)
My version works on small local models and uses tmux under the hood. No installation is necessary. Simply tell your agent to run uvx agent-cli-helper and that's it. The verbiage and flow is optimized through test harnesses to maximize effectiveness for agentic use. https://github.com/day50-dev/acli (Sorry: my marketing and and pitch skills are trash)
So if I'm understanding right, Claude Code can use Claude Code now?
Something something medical researcher reinvents calculus. In 2026: frontend web developer reinvents tmux. Guys, please do us the service of pre-filtering your crack token dreams by investigating the tool stack which is already available in the terminal ... or at least give us the courtesy of explaining why your vibecoded Greenspun's 10th something is a significant leg up on what already exists, and perhaps has exist…
Something something medical researcher reinvents calculus. In 2026: frontend web developer reinvents tmux. Guys, please do us the service of pre-filtering your crack token dreams by investigating the tool stack which is already available in the terminal ... or at least give us the courtesy of explaining why your vibecoded Greenspun's 10th something is a significant leg up on what already exists, and perhaps has exist…
Maybe, just maybe, this is of obvious utility to the many people who have needs that are not yours? I very regularly need to interact with my work through a python interpreter. My work is scientific programming. So the variables might be arrays with millions of elements. In order to debug, optimize, verify, or improve in any way my work, I cannot rely on any other methods than interacting with the code as it's being…
edit: There are much better solutions for Python-land below it seems :)
My version works on small local models and uses tmux under the hood. No installation is necessary. Simply tell your agent to run uvx agent-cli-helper and that's it. The verbiage and flow is optimized through test harnesses to maximize effectiveness for agentic use. https://github.com/day50-dev/acli (Sorry: my marketing and and pitch skills are trash)
How is acli different from telling the model to "use tmux for this"?
just try it out. It's not the same.
There's a One Minute video showing the difference on the github page.
You can also try it yourself:
$ uvx agent-cli-helper run-command vim
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 for information
~
~ type :q to exit
~ type :help or for on-line help
~ type :help version9 for version info
~
~
~
~
~
0,0-1 All
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
When you are done, use finish-command to finish the session. For example: agent-cli-helper finish-command vim
If you need to see the current screen without sending keystrokes, use agent-cli-helper get-screen-capture
* 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
Something something medical researcher reinvents calculus. In 2026: frontend web developer reinvents tmux. Guys, please do us the service of pre-filtering your crack token dreams by investigating the tool stack which is already available in the terminal ... or at least give us the courtesy of explaining why your vibecoded Greenspun's 10th something is a significant leg up on what already exists, and perhaps has exist…
Maybe, just maybe, this is of obvious utility to the many people who have needs that are not yours? I very regularly need to interact with my work through a python interpreter. My work is scientific programming. So the variables might be arrays with millions of elements. In order to debug, optimize, verify, or improve in any way my work, I cannot rely on any other methods than interacting with the code as it's being…
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.
Earlier quoted context omitted.
Maybe, just maybe, this is of obvious utility to the many people who have needs that are not yours? I very regularly need to interact with my work through a python interpreter. My work is scientific programming. So the variables might be arrays with millions of elements. In order to debug, optimize, verify, or improve in any way my work, I cannot rely on any other methods than interacting with the code as it's being…
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 inter…