Instead of a 2 bash call, send-keys to a tmux session, then another call to read the whole pane.
It could one bash call to a non interactive wrapper around lldb that return the result of evaluating the command.

My point is that this could be easier to interact with for the AI.

Humans don't start a repl in a background tmux session to then use send-keys follow by sleep 1 && capture-pane.
Based on my reading of your blog and videos this is potentially context poisoning, it require a lot of tool calling with token that are not about the debugging but circumventing limits.

Example with a repl started in the background and a eval script that talk to the interactive process and return the result. Can still run into issue with async process and side effects happening after evaluation completed. In that case it usually sleep and `make logs` to get results.

This is an example where I would try to meet the LLM in the middle and either seek solutions that don't require interactive use of the terminal or build a wrapper to provide a non interactive experience.

It's painful to watch and I wouldn't wish any human to go thru this kind of setup. Intuition is that this can't be good for perf but might not matter and even less so in the future.