We're all learning how to code with agents. If you're "in the bubble" it can feel like everyone is tokenmaxxing. Automating everything. Spinning up overnight agents to write full apps while they sleep. The reality I see with a lot of developers is much more normal:
They are copying and pasting code back and forth from VS Code and ChatGPT.
I am seeing slow adoption of built-in chat interfaces in IDEs like Copilot, Cursor, and Antigravity. CLI agents still feel relatively fringe among next-gen developers. I know this likely is not what you're hearing or seeing on Twitter.
Anyway, I've roasted plenty of developers for copying code back and forth from their IDEs into web chat interfaces. This week, I realized I have been doing the same thing, just with more terminal panes. A test fails in one terminal pane. An agent is working in another. I copy the error, paste it into the agent, wait, run another command, copy the next error, paste again.
My cool hacker-y CLI workflow suddenly felt... less cool.
The obvious fix is: let the agent read the terminal. The less obvious problem is: I do not want agents casually reading every terminal pane I have open.
The CLI Version Of Copy/Paste
I use Zellij as my terminal multiplexer. If you have used Tmux, it is the same general idea: panes, tabs, sessions, and a bunch of terminal state living in one place. I really like Zellij. I struggled with Tmux for whatever reason and never looked back. I seem to be in a minority here though.
I use a variety of CLI coding agents: OpenCode, Gemini CLI, Claude Code, Codex, and whatever else I am trying that week.
A normal tab looks like OpenCode on the left, and one or two panes on the right for running commands, observing tests, or watching a dev server.
But the panes are distinct. Agents do not automatically know what happened in the test pane. My test pane does not know what the agent is trying to debug. So I become the bridge, manually ferrying errors and logs back and forth. Copying and pasting.
Integrated agent shells help sometimes, but they are not the whole answer. Long-running commands eat up agent time. Many commands need elevated permissions. Plus, I already have a terminal layout and workflow I like.
I did not want to move everything into the agent. I wanted the agent to see what I see.
Everything Means Everything
The naive version of my project was easy: give the agent full access. Let it read the whole Zellij session. And call it a day.
Except... secrets and security are a thing. I already play it too fast and loose with my agents. I'm trying to be better about that. I needed selected-pane awareness, not full terminal visibility.
That became the design constraint for zellij-agent-tools: agents should only read panes I explicitly approve, and that approval should be visible where the pane actually lives.
Zellij As The Consent Surface
The project is a Zellij plugin plus a local MCP sidecar.
The Zellij plugin is the human-facing part. It lists panes, asks for approval, marks watched panes, and lets me revoke access.
The sidecar is the agent-facing part. It exposes a small set of MCP tools so agents can list watched panes and read bounded output from the panes I approved.
I did not want consent hidden inside an agent chat. I can see the agent calling the tools in line, but I approve it in the Zellij plugin. I wanted separate surfaces. MCP is the agent interface. Zellij is the human interface.
That feels like the right boundary.
The v1 tool surface is intentionally boring. Just: ask to watch a pane, list watched panes, read a bounded snapshot, read output after a cursor, check status.
That is enough to stop me from copy/pasting every error by hand.
Not Security Itself
I'm not naive to the fact that agents can probably get around this. If an agent has unrestricted shell access as my user, it may be able to call the Zellij CLI directly or do other things I did not intend.
I am not trying to solve malicious local code here. I am trying to make my normal workflow less sloppy.
The goal is for the easy path to be the safer path: ask for the pane, show the user, read only what was approved, fail closed when state is stale or revoked.
That already feels better than copy/paste chaos or full terminal visibility.
More To Do
I still have plenty to do on this project. It's a very rough first pass. But the direction feels right and I think it solves a real problem that I imagine other folks have.
I'm gonna keep using it and iterating on it for my workflows. Feel free to check it out!
Top comments (12)
gonna push back on this a bit - clipboard friction can be intentional. reading what you paste forces you to understand what goes into prod. cursor auto-suggest makes it easy to ship code nobody followed.
There is something to be said about this too: the auto-suggest, which i imagine to be like Copilot code suggestions (i haven't used cursor) at least has you be in the editor.
When you introduce harnesses like claude code and codex when you just have a conversation, files get edited, commited and pushed, and you never typed a single character in the files themselves. That's where ghost code gets sent somewhere, that's entirely agent-made.
yeah that trade-off is real. cursor autocomplete at least keeps your eyes on the diff. with claude code / codex you're trusting your prompt more than your eyes — different discipline. not sure which failure mode is worse honestly.
The separate-surfaces design is the key insight here, and it's underrated. Mixing approval UX into the agent chat (the obvious shortcut) would make consent invisible to the human at the moment it matters - when you're actually looking at the terminal. Keeping Zellij as the consent surface and MCP as the tool interface means each is optimized for its actual audience. The "fail closed on revoked state" detail follows naturally from this: since the human controls the consent surface independently, the agent can't assume approval persists across sessions.
I completely agree with the message of this post.
I'm going to add something to this: look up the "Chinese Room" thought experiment.
It matches this idea to a tee. Too many are simply being the carrier of information from one end to the other without understanding what's happening at either point.
(Not wanting to steal the thunder of this post, it's just that I was actually drafting a blog post to be released soon, using that framing, curiously enough.)
The "two separate surfaces, one for the human, one for the agent" framing is the part that landed hardest for me. I had the same realization the wrong way round: I was building a voice assistant for TAMSIV (task manager) where the user dictates intent and the LLM resolves the action. For months I tried to keep everything in one stream, "user said X, agent inferred Y, agent acted on Z". It collapsed every time, because the human consent surface and the action-execution surface should not be the same view. Two surfaces, two cadences, two trust models.
The Zellij approval flow is a really clean answer to the clipboard pain. One thing I'm curious about: do you find the per-pane scope is enough on its own, or are you also needing temporal scope (this pane, for the next 5 min, then re-prompt)? The pane-as-scope feels right for one-shot debug, less so for an agent that's looping for an hour.
And, separately, "consent should remain visible" is a phrase I'm probably going to steal for my own MCP doc. It's the cleanest one-line spec I've seen for an agent permission model.
The clipboard problem hits hard when you're solo. I built TAMSIV (voice AI task manager) over 6 months and the recurring failure mode wasn't bad prompts, it was context that lived nowhere. I'd paste a chunk of code into the LLM, get a fix, ship it, and 3 weeks later when something broke I had zero traceable record of why that approach was chosen.
What changed for me was treating "context handoff" as a first-class artifact, not a clipboard event. Every non-trivial design decision now lives in a markdown file checked into the repo (decisions.md, ADRs, even just dated notes in /docs/). The LLM session reads from there, writes back to there, and the clipboard becomes a transport layer instead of a memory.
Side effect I didn't expect: my future self stopped feeling like a stranger to my own code. The cognitive cost of returning to a paused project dropped sharply once the "why" stopped being trapped in dead chat windows.
Your iteration on the workflow tool is exactly the right direction. The clipboard is a leak, not a channel.
This feels related to something I've been noticing with spec-driven workflows. A lot of "AI productivity" right now is really just humans acting as context routers. Copying errors, pasting logs, re-explaining intent, reconstructing state across tools.
But I also wonder whether some of that friction is accidentally useful.
Clipboard friction forces you to look at the error. Rewriting context forces you to re-evaluate assumptions. Full agent automation removes a lot of cognitive overhead - but maybe also removes some of the moments where understanding used to happen.
Feels like we're still searching for the boundary between "remove useless friction" and "remove the human from the loop entirely".
The clipboard friction debate is interesting. I see both sides. Copy-pasting forces you to read the error and actually think about what it means. But when you're debugging the same test failure for the tenth time, automation starts looking real good. Maybe the answer is both - copy for understanding, then automate once you know the pattern.
The separate surfaces design is underrated. Agent approval shouldn't live in the same chat where the agent is asking for permission. That's like asking the fox to guard the henhouse. Having Zellij as the human interface and MCP as the agent interface keeps the trust model clean. The agent can't grant itself access if the control panel is somewhere else.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.