Back to blog

Running Coding Agents in Your Terminal: Multiplexing, Constraining, Auditing

August 22, 2026 coding-agents, terminal, sandboxing, developer-tools

One coding agent in one terminal needs no tooling. The problems in this list start at the second agent, and they arrive in a specific order.

First you lose sight of them: two or three sessions running, and the only way to know which is blocked, which is grinding, and which finished ten minutes ago is to cycle through windows. Then you lose the leash: an agent asked to fix a null check returns a refactor of the module, and you find out at review time. Then you lose the reasoning: a decision nobody explicitly approved is now in main, the person asking "why is this like this" is you three weeks later, and the transcript that held the answer was deleted after thirty days.

None of that is a model-quality problem, which is why buying a better model does not fix it. It is a workspace problem, and the eight tools below are workspace answers — terminal multiplexers, constraint layers, sandboxes, and decision recorders. Star counts, licences and last-push dates are in the table below, measured on the date shown. Two entries carry copyleft licences that matter if you host them for others, and one has already moved to a different GitHub owner since our catalogue last looked.

Some links to project repositories carry a referral parameter. It costs you nothing, changes nothing about what appears here, and the ordering below is by problem area, not by whether a link earns anything.

The eight tools at a glance

Star counts, languages, licences and last-push dates were read from the GitHub API on 2026-08-22.

Tool What it does Language License Last push ★
herdr Multiplexer running agents in real terminal panes, with a socket API Rust Apache-2.0 2026-08-22 31584
agent-talk Agents message each other directly, including across machines Python MIT 2026-08-21 169
jacquard-lang Language where an agent's code must declare the effects it may perform OCaml Apache-2.0 2026-08-20 116
Z-Jail Sandbox for untrusted binaries: 7 layers, one 130 KiB binary C MIT 2026-07-25 74
kolu Many terminal tiles on an infinite pannable canvas TypeScript AGPL-3.0 2026-08-22 75
Grepathy Extracts the agent's decisions from the transcript into a file beside the code TypeScript MIT 2026-07-17 65
bash4llm A model CLI as one Bash script you can read end to end Shell GPL-3.0 2026-08-20 60
boffin Feeds the agent only the constraints touching the file being edited JavaScript MIT 2026-08-08 38

What counts here

Tools that change how you run and supervise a coding agent from a shell. That covers four jobs and deliberately excludes a fifth.

It includes multiplexing (several agents visible and resumable at once), constraining (bounding what the agent may change or execute), containing (running untrusted output without trusting it), and recording (keeping the reasoning that would otherwise evaporate).

It excludes giving the agent a new capability — document editing, browser driving, database access. Those are worth having and they are a different list; the most-starred candidate this cluster produced, a 29,000-star CLI for Word and Excel, was left out on exactly that line. The distinction is not pedantry: capability tools make the agent able to do more, and everything below exists because an agent doing more, unsupervised, is the problem.

Seeing several agents at once

herdr runs multiple agents in real terminal panes rather than a wrapper's interpretation of their output, so "blocked, working, or done" is visible at a glance. Sessions detach, keep running, survive restarts, and reattach from any terminal including over SSH. It is a single Rust binary with no Electron, it supports tmux-style prefix keys and mouse interaction equally, and — the part worth noticing — it exposes a socket API agents can drive themselves: an agent can spawn its own pane, read its output, and wait on another pane to finish, which is agent-to-agent coordination without a human relaying every step.

kolu answers the same question spatially: real terminal tiles on an infinite pannable, zoomable canvas, with a dock tracking every open terminal. It is deliberately agent-agnostic — the terminal is the interface, so whatever CLI ships next week works with no adapter — but it does know three agents by name well enough to show live status, reading Claude Code's session log plus a screen scrape for the prompts that log cannot reveal, and Codex's threads database. Note the licence: AGPL-3.0.

agent-talk is the least obvious of the three and the most interesting when it applies. It lets an agent message another agent directly, including one running on someone else's machine, so two engineers' agents can settle an implementation detail between themselves instead of their humans relaying it. The transport is end-to-end encrypted by design; the project states plainly that it has not been independently audited, which is the right way to state it and worth repeating here.

Keeping the agent inside the lines

boffin targets the single most common failure of agent-assisted work: a small requested fix returned as a large unreviewed rewrite. Instead of one static instruction file for the whole repository, it selects only the architectural constraints that apply to the file about to be edited, and requires a verification check proportional to the size of the change. It is explicit about what it is not — not a linter, not a CI gate, not a sandbox — because it acts before and after the edit rather than on committed code.

jacquard-lang takes the same goal to its logical end and is the most researchy entry in this list. It is a small language and runtime where a function's type says not only what data it takes but which side effects it may perform — network, filesystem, clock, randomness — and the interpreter enforces that: an effect not authorised on the command line does not run, and a function whose signature omits an effect it actually performs fails to compile rather than passing silently. Effects propagate up the call graph automatically, so a caller three layers above a network call still shows it. Treat it as a research project with a working demonstration, not as something to port a service into.

Containing what actually executes

Z-Jail runs untrusted native binaries behind seven independent layers — namespaces, pivot_root, capability dropping, NO_NEW_PRIVS, a seccomp-BPF syscall allowlist, hashed audit logging — applied in an order chosen so a later layer cannot be undone by an earlier one. It is a single 130 KiB dependency-free C binary, which is what makes it usable in CI or a challenge box where a container runtime is too much machinery. It sits in the gap between bwrap, which is minimal but has no seccomp by default, and nsjail, which is fuller but heavier.

bash4llm belongs in this section rather than the tooling one, because its selling point is auditability rather than features: a single self-contained Bash script that talks to any OpenAI-compatible endpoint and that you can read end to end in an afternoon. It never uses /tmp, never calls eval, and never executes the model's own output — three properties that are easy to claim and, here, easy to verify, because the whole thing is one file. Licence: GPL-3.0.

Answering "why is this code like this"

Grepathy records the decisions an agent made — including the ones nobody explicitly approved — into a markdown file committed next to the code. It runs off hooks rather than being invoked: you work normally, and on git push it writes .ai/why/<branch>.md and shows it to you before anything ships, with each entry marking whether the choice was agent-initiated, which files it touched, and what the agent believed its rationale was. The problem it targets is concrete and dated: Claude Code deletes session transcripts after thirty days by default, and a pull-request reviewer asking "why was this done this way" three weeks later is asking about a conversation that no longer exists.

Doing this natively

The tools above sit outside the assistant. Several of the same jobs have install-able answers inside it:

  • Native Parallel Agents — coordinating several specialised agents through the built-in agent system
  • Dispatching Parallel Agents — one agent per independent failure domain, instead of investigating bugs in sequence
  • tmux — session, window and pane management for persistent terminal workflows
  • Codex CLI as a Subagent — delegating a bounded task to a separate sandboxed session
  • Code Review and Quality — five-axis review with severity-labelled findings, for the code the agent just wrote

FAQ

How many agents can I actually run at once?
The limit is rarely the machine. It is how many blocked agents you can notice before they have been idle for twenty minutes — which is why the tools in the first section are about visibility rather than about spawning. Two agents need no tooling. Four without a multiplexer means you are the scheduler, and you are slower than the agents.

Does a constraint layer make the agent worse?
It makes it narrower, which is usually what you wanted. The failure these tools target is scope, not capability: the agent was asked for a fix and delivered a redesign. Constraining what it may touch does not reduce the quality of the fix; it reduces the amount of unrequested work you have to review to find the fix.

Is a sandbox necessary if I read the code before running it?
You will read the first ten outputs and skim the eleventh. The value of a sandbox is that it does not depend on your attention that day. It matters most exactly where review is weakest — a long unremarkable run late in a session — which is also when the review feels least necessary.

Does AGPL matter for a developer tool I run locally?
Running it yourself, no: copyleft obligations attach to distribution, and using a tool on your own machine is not distribution. It matters when you host it so that other people use it over a network — that is the case AGPL adds over GPL, and it obliges you to offer the source, including your modifications, to those users. Two entries in the table above are copyleft and the rest are permissive, which is why the column exists.

Why record decisions if the code is reviewed anyway?
Because review answers "is this correct" and not "why is this shaped this way". The second question arrives weeks later, usually with a proposal to undo something that turns out to have been deliberate. An agent's reasoning is unusually cheap to capture and unusually expensive to reconstruct — it exists in full at the moment of writing and nowhere at all a month later.

Explore 4,500+ AI tools on Spark

Browse catalog