In a single week, four independent developers shipped tools that all attack the same problem: once you start running Claude Code or another AI coding agent as a background worker, you need infrastructure around it that doesn't exist yet. They called it different things — a process supervisor, a control surface, a notification plugin, a memory framework — but they were all building the outer control layer that the agents themselves don't provide. This post benchmarks Leo, ADHDev, tmux-notify (Vibe), and AIPass against the four jobs any agent control layer needs to handle, and shows which tool fits which workflow.
TL;DR
Each tool solves 1–2 of the four core control-plane jobs. Leo is best for SSH-native ops workflows with scriptable process supervision. ADHDev targets browser-dashboard style monitoring with a mobile browser fallback. tmux-notify is the minimum viable fix for notification within an existing tmux setup. AIPass is architecturally different — it solves persistent agent memory, not monitoring or remote access. For all four jobs without maintaining your own stack, Grass is the packaged alternative. If you know your bottleneck, jump to the verdict.
Why are developers building their own agent control layers?
An agent control layer (sometimes called an outer harness) is the infrastructure that wraps an AI coding agent — Claude Code, Codex, OpenCode — to handle the operational concerns the agent itself doesn't solve: session lifecycle management, permission prompt routing, remote access, and persistence across disconnects. The agent is the AI layer; the control layer is what makes it usable as a real background worker.
The architectural diagnosis is clear. As one post on inner vs. outer coding agent harness architecture in r/ClaudeCode framed it, the inner harness — Claude Code, the agent SDK, the model — is rapidly commoditizing. The interesting engineering surface is what you build on top.
The pain is concrete. ADHDev's creator described it directly in a r/SideProject thread: "I start a task, let it run, come back later, and need to know whether it is still working, waiting for input, stuck, finished, or ready for a follow-up." Claude Code's built-in interface assumes you're watching. These developers are not watching — they're doing something else and checking back.
The permission routing problem is even more disruptive. The tmux-notify author was blunt: "I never knew which session was waiting for an Allow permission request or a Plan review." When you have two or three Claude Code sessions open across different projects, a stalled permission prompt is invisible until you manually inspect each window. The session doesn't fail — it just waits indefinitely. That's a silent blocker.
What's notable is that all four builders converged on the same problem space independently, with completely different architectural bets. That convergence is the signal.
What does each tool actually build?
Leo is an SSH-based process supervisor for Claude CLI. From its README: "Long-running supervised claude processes, scheduled tasks, and ephemeral agents. I can configure agent templates that allow me to spawn agents at will which I can then connect to over SSH using the leo cli." Think supervisord adapted for Claude Code — the leo cli is your control surface, and SSH is the transport.
ADHDev is a browser dashboard that sits above the agent as a control layer. It gives you visual session status, lets you continue sessions, and surfaces approval workflows — all accessible from a browser, including a mobile browser.
tmux-notify (Vibe) is a Claude Code tmux notification plugin built on hooks. When Claude Code needs your attention — an Allow/Deny prompt, a Plan review — it fires a notification. Nothing more, nothing less.
AIPass is a multi-agent framework with persistent identity and memory for local workflows. The builder's summary: "One agent on one project with persistent memory is already a different experience." Its scope is different from the other three — it doesn't monitor or provide remote access, it gives agents memory that survives across sessions.
What criteria matter for an agent control layer?
Four jobs determine whether a control layer is actually useful:
Session status visibility — Can you see at a glance whether the agent is running, idle, waiting for input, or finished? Without this, triaging multiple sessions requires opening each one.
Permission prompt routing — When the agent requests an approval (bash execution, file write, web fetch), does it route that request to you wherever you are? Unrouted prompts stall sessions silently. This is not a minor ergonomics issue — as The Permission Layer Is 98% of Agent Engineering documents, approval routing is the central engineering problem in agent control systems.
Mobile/remote access — Can you reach the agent without being at the machine running it? The laptop-tether is the core friction point these tools are solving.
Persistence across disconnects — If you close your terminal or switch networks, does the session stay alive? And can you resume it?
Capability matrix: Leo vs ADHDev vs tmux-notify vs AIPass
| Leo | ADHDev | tmux-notify | AIPass | Grass | |
|---|---|---|---|---|---|
| Approach | SSH process supervisor | Browser dashboard | tmux hook + notify | In-process memory | Cloud VM + native app |
| Session status visibility | Terminal (SSH) | ✓ Browser dashboard | tmux notification | — | ✓ Real-time streaming |
| Permission prompt routing | Manual (SSH in) | ✓ | Notify only (local) | — | ✓ Native mobile modal |
| Mobile/remote access | SSH | Mobile browser | ✗ | ✗ | ✓ Native iOS app |
| Persistence across disconnects | ✓ Process supervisor | Partial | tmux session | ✓ Session memory | ✓ Cloud VM |
| Setup complexity | Medium (SSH config) | Medium | Low | Medium | Low (QR scan) |
| Open-source | ✓ | ✓ | ✓ | ✓ | ✓ (CLI + app) |
| Self-hosted | ✓ | ✓ | ✓ | ✓ | Optional (cloud tier) |
Leo: What does SSH-based process supervision actually give you?
Leo's bet is that developers running serious long-running agents are already SSH users. The leo cli connects to a running Leo server over SSH, giving you access to supervised Claude Code processes, agent templates you define and spawn on demand, and scheduled tasks.
The strengths are real: if you're already running a VPS or home server, Leo slots into existing infrastructure without introducing new access patterns. The process supervision model means your agents outlive terminal sessions — Leo is a proper daemon manager, not a tmux wrapper.
The tradeoffs are also real. SSH on mobile is workable but not built for this use case. Permission prompts that surface inside a Leo-managed session still require you to navigate to that session in a terminal to respond. And the setup bar is higher than the other tools — you need a machine running Leo, SSH keys configured, and a mental model of the Leo process hierarchy before you get any value.
Best fit: Developers with existing SSH infrastructure who want scriptable, template-driven agent lifecycle management and are comfortable in the terminal.
ADHDev: What does a browser dashboard add?
ADHDev takes the opposite architectural position — don't require terminal access, give people a visual UI. The dashboard surfaces session status, supports continuing sessions, and includes approval workflow handling. Mobile access via browser is a first-class use case, not an afterthought.
The builder's SideProject launch framed the product clearly: AI coding agents are becoming background workers, and the control layer for a background worker should let you triage without reopening your IDE or remote desktop.
Browser-based mobile access is functional but has architectural limits. You're one browser tab away from monitoring, but if the dashboard itself loses connectivity or the underlying session detaches, you're debugging a distributed system. The mobile experience depends on browser rendering, not native UI conventions.
Best fit: Developers who want visual session monitoring with approval routing and are comfortable with a browser as their primary control surface — including cases where the agent runner and the reviewer are different people.
tmux-notify: What does hook-based notification solve?
tmux-notify (Vibe) is the smallest-scope tool of the four, and that's by design. It hooks into Claude Code's event system within tmux and fires a notification when a session needs attention. Nothing more.
This directly fixes the "I didn't notice the permission prompt" problem. If you're running three Claude Code sessions in separate tmux windows, you'll now get a signal when one of them is waiting — rather than discovering it 45 minutes later when you happen to switch windows.
What it doesn't fix is the remote access problem. You still need to be at a machine running tmux, switch to the right window, and respond locally. For human-in-the-loop approval workflows that need to work when you're not at your desk, tmux-notify is a starting point, not a complete stack.
Best fit: tmux-native developers running multiple Claude Code windows on a single machine who just need to stop missing prompts. Lowest setup cost of the four tools.
AIPass: What does persistent memory change?
AIPass is in a different category from the other three. It's not a monitor and it's not a remote control — it's a multi-agent framework that gives agents persistent identity and memory across sessions. Each session starts with context about what's been done before, what decisions were made, what's still open.
The builder's summary is accurate: persistent memory is a qualitatively different agent experience. Without it, every Claude Code session starts cold. With it, you can run structured multi-agent workflows where earlier sessions inform later ones.
What AIPass doesn't address: you still have no visibility into whether your session is running or waiting, no way to route permission prompts remotely, and no access from your phone. It solves a different slice of the control-plane problem than the other three tools.
Best fit: Developers building structured multi-agent workflows where session continuity and memory are the primary friction point, not monitoring or remote access.
Verdict: Which tool solves your actual problem?
These four tools are largely complementary, not competing. They attack different jobs:
- You keep missing permission prompts while working at your desk → tmux-notify
- You want a visual dashboard with session status and approval routing, browser-accessible from mobile → ADHDev
- You want SSH-controlled, scriptable process supervision with agent templates → Leo
- You're building structured multi-agent workflows and need memory continuity → AIPass
If you need all four jobs covered — status visibility, permission routing, remote access, and persistence — no single tool gets you there. A full DIY control plane might stack Leo for process supervision, tmux-notify for notification, ADHDev for the approval dashboard, and AIPass for memory. That's four repos to understand, configure, and maintain.
This same pattern of parallel independent tooling appeared in multi-agent monitoring last month — Agent Quest, baton-os, and teamfuse all shipped in the same window, each covering a different monitoring surface. The control-plane layer is being actively built out across the community, in pieces.
What if you don't want to maintain your own control plane?
The observation from the r/ClaudeCode harness architecture post holds: the outer harness is becoming the real product. Each of these four tools is a handbuilt answer to the same underlying need. If you'd rather use a packaged version than stitch tools together, Grass ships the full stack.
The local CLI (@grass-ai/ide, open-source MIT) runs a server on your machine; you connect via QR scan from the native iOS app. Permission prompts route as native modals on your phone — tap Allow or Deny, with haptic feedback — rather than requiring you to navigate to a terminal window. Sessions survive disconnects via SSE with Last-Event-ID replay. For running Claude Code completely unattended overnight or across a commute, the cloud VM tier at codeongrass.com goes further: an always-on VM where your agent keeps running after your laptop closes.
The tradeoff versus the DIY tools is configurability and ownership. Leo, ADHDev, tmux-notify, and AIPass give you full control over every layer and are worth studying even if you eventually pick a packaged solution — the architectural patterns they've chosen are the right ones.
FAQ
What is an agent control layer?
An agent control layer (outer harness) is the infrastructure that wraps an AI coding agent — Claude Code, Codex, OpenCode — to handle the operational jobs the agent itself doesn't provide: session lifecycle management, permission prompt routing, remote access, and persistence across disconnects. The agent is the AI layer; the control layer is what makes it safe and usable as a persistent background worker.
What is the difference between Leo and ADHDev?
Leo is an SSH-based process supervisor: you manage Claude Code processes via the leo cli over SSH, with agent templates and scheduled task support. ADHDev is a browser dashboard: it gives you a visual control surface for session status and approval routing, accessible from a mobile browser. Leo is terminal-first; ADHDev is browser-first.
How does tmux-notify handle permission prompts?
tmux-notify fires a notification when a Claude Code session within tmux is waiting for an Allow/Deny approval or a Plan review. It notifies you that a prompt is waiting but does not route the approval remotely — you still need to switch to the relevant tmux window on the same machine to respond. It solves the "I didn't notice the prompt" problem, not the "I'm not at my laptop" problem.
Can I combine these tools instead of picking one?
Yes — they are largely complementary. Leo for process supervision, tmux-notify for local notification, ADHDev for a visual dashboard with approval routing, and AIPass for persistent agent memory cover different layers without much overlap. The cost is configuration and maintenance across multiple repos.
What does Grass add beyond these four DIY tools?
Grass bundles the four core control-plane jobs — session visibility, permission routing, mobile access, and persistence — into a single packaged product. The CLI and native iOS app handle local workflows; the cloud VM tier handles always-on remote execution with sessions that survive laptop sleep. The difference from the DIY tools is setup time (minutes vs. configuration across multiple tools) and maintenance burden (Grass-maintained vs. self-hosted). Both the CLI and mobile app are open-source MIT.
If you know your bottleneck, the choice is straightforward: tmux-notify if you're already in tmux and just need notifications, Leo if you want SSH-controlled supervision, ADHDev if you want a visual dashboard with mobile browser access, AIPass if memory continuity is your primary problem. If you want all four jobs handled without building the stack yourself, getting started with Grass takes under 5 minutes — install the CLI, scan the QR code, and your permission prompts start routing to your phone.
This post is published by Grass — a machine built for AI coding agents that gives every developer an always-on cloud VM with Claude Code, Codex, and Open Code pre-loaded, accessible from your laptop, phone, or an automation.
Originally published at codeongrass.com
Top comments (0)