{"slug": "ai-coding-agents-need-a-team-runtime-not-just-more-tmux", "title": "AI Coding Agents Need a Team Runtime, Not Just More tmux", "summary": "A developer has created a blueprint for a managed, multi-developer runtime for AI coding agents, moving beyond personal tools like Agent Deck and Claude Code's agent-view. The system, built with SSH, tmux, sudo, and infrastructure-as-code, addresses the need for session visibility, permission control, and team coordination that arises when multiple developers run agents simultaneously. The approach provides a minimal working model for teams of 2-15+ developers, handling agent durability, attribution, and lead access to junior sessions for mentoring.", "body_md": "When a team starts coding with AI agents, the bottleneck moves fast. Getting agents to run is the easy part.\n\nRunning agents under control is the hard part: knowing which server an agent sits on, what it's allowed to touch, who can watch a session, and who can drop into a teammate's session to help.\n\nThis is a hands-on blueprint for exactly that: the jump from agents scattered across people's laptops to a managed, multi-developer runtime, built with nothing fancier than SSH, tmux, sudo, and infrastructure-as-code.\n\nPlenty of ready-made tools already cover the solo case. [Agent Deck](https://github.com/asheshgoplani/agent-deck), [AoE](https://github.com/agent-of-empires/agent-of-empires), [Vibe Kanban](https://github.com/BloopAI/vibe-kanban), and the like spin up parallel agent sessions, sort them by project, and show status. Vendors are moving the same way too: Claude Code now has [ /agent-view](https://code.claude.com/docs/en/agent-view).\n\nBut those answer how one person runs a lot of agents, not how a team runs them safely.\n\nConcretely, a team needs to know where and how sessions get launched, what permissions agents run with, who can see them, who can attach to them, and how to give leads and seniors access to juniors' sessions for mentoring. It also needs a standardized execution environment and a way to scale the whole thing through infrastructure-as-code.\n\nToday I'll walk through how to build a basic agent runtime for teams of two or more:\n\nBefore a team runtime appears, there are usually two personal modes:\n\n`/agent-view`\n\n, Agent Deck, or similar tools.After that, the runtime becomes a team concern:\n\nThis article is about the jump from personal modes, 0A-0B, to level 1.\n\n`NOPASSWD: ALL`\n\nin the examples, but I flag every one of them with a note.The minimal working model:\n\nThis isn't enterprise grade. Where there's sensitive infrastructure and/or data, I run agents in rootless containers at the very least. But for now, this is just the minimal working setup.\n\n| Handles | Doesn't handle |\n|---|---|\n| scaling to teams of 2-15+ developers | quality of requirements and architecture |\n| agent durability | team processes |\n| separating human and agent permissions | code quality, tests, CI |\n| basic attribution of actions | protection against agent mistakes |\n| basic limits on agent permissions | full permission isolation |\n| session visibility for leads | compliance with AI vendor rules |\n| a controlled way to attach to newcomers' agent sessions for mentoring | protection of sensitive data |\n| enterprise policies |\n\nFor teams moving to agent-driven development, the first pain point isn't the sandbox. It's session chaos: it's unclear where and how to launch agents, how to keep tabs on them, how to manage them. Without a session-management layer, moving the chaos inside containers won't save you.\n\nAgents in containers aren't free. A lot of details show up that someone has to keep an eye on: UID mapping, network namespaces, egress proxy, DNS, API endpoints, services, duplicated authentication, image maintenance. All of it is solvable, but it's not a team's first step into an agent runtime.\n\nIf you need agents to actually work, not just to \"try them out,\" the default is a separate dev server, or an equivalently isolated environment, per developer.\n\nWhy:\n\n**load:**\n\ndev/stage environments, external integrations, and services need clear isolation of permissions and environment;\n\naccounts, subscriptions, rate limits, and outbound IP behavior are easier to attribute and control.\n\nAn option for the start of a project, for training, or for light load. Use it only if the basics are in place:\n\nI won't go deeper into this scenario, since I don't treat it as the main one here.\n\nDeveloper Wes generates an SSH key on his laptop:\n\n```\nssh-keygen -t ed25519 -f ~/.ssh/id_ed25519\n```\n\nHe copies the public part of the key to his server, `dev-wes`\n\n:\n\n```\nssh-copy-id -i ~/.ssh/id_ed25519.pub wes@1.2.3.4\n```\n\nHe sets up an alias in `~/.ssh/config`\n\n:\n\n```\nHost dev-wes\n  HostName 1.2.3.4\n  User wes\n  IdentityFile ~/.ssh/id_ed25519\n  IdentitiesOnly yes\n```\n\nAfter that, connecting is just:\n\n```\nssh dev-wes\n```\n\nWhen you have a lot of servers, it helps to add autocompletion and an fzf menu over `~/.ssh/config`\n\nso you don't have to keep aliases in your head.\n\nOn the servers, disable password login and root login. Keys only:\n\n```\n# /etc/ssh/sshd_config\nPasswordAuthentication no\nPermitRootLogin no\nPubkeyAuthentication yes\n```\n\nIf the team has no corporate VPN and connects to servers directly, the private keys on personal laptops must be protected with 2FA, in software or hardware: at minimum the Secure Enclave on macOS, or Windows Hello / TPM on Windows.\n\n`et`\n\ninstead of `ssh`\n\nPlain SSH drops when the network blips, when the laptop goes to sleep, and so on. When you've always got a pile of tabs open across different servers, projects, and agents, reconnecting is a pain.\n\nSo I don't connect like this:\n\n```\nssh dev-wes\n```\n\nI connect like this:\n\n```\net dev-wes\n```\n\n[Eternal Terminal](https://github.com/MisterTea/EternalTerminal), or `et`\n\n, restores the connection after drops, including long ones. Switch VPNs and your sessions are still alive; open the laptop after changing location, or the next morning, and everything keeps running.\n\nThe more popular [mosh](https://mosh.org/) isn't a great fit for agents yet: it \"draws\" the screen itself and \"predicts\" your input instead of behaving like plain SSH. That makes scrolling, full-screen mode, and terminal integrations work worse. Eternal Terminal is closer to a regular SSH/PTY session, so agents are happier inside it.\n\nRunning agent sessions remotely in tmux is already better than running them locally: the session lives on the server, doesn't depend on the laptop, and runs in a standardized environment.\n\n```\net dev-wes\ntmux new -s claude\nclaude\n```\n\nBut hand-managed tmux turns into chaos fast. A couple of days in, you open the session list and see something like this:\n\n```\ntmux ls\nclaude: 1 windows (created Mon May  4 09:12:43 2026)\ntest: 1 windows (created Mon May  4 14:55:01 2026) (attached)\nnew: 2 windows (created Tue May  5 10:03:18 2026)\nnew2: 1 windows (created Tue May  5 18:41:02 2026)\nprod-bug-final: 1 windows (created Wed May  6 23:17:55 2026)\nfix-temp: 1 windows (created Thu May  7 08:22:11 2026)\n```\n\nNo idea which project, whose process, which agent, what's active, what's stuck, what's safe to kill, and so on.\n\nSo you need a session manager on top of tmux.\n\nBut first, permissions.\n\nThe basic scheme:\n\nIt's important not to mix the two roles:\n\nIf you run the agent as the same human user, the agent gets the same permissions, especially in permissive mode: `--dangerously-skip-permissions`\n\n, yolo. In that case the blast radius is limited only by the human user's permissions.\n\nIn a sane setup these are different users: the human user manages the session, and the agent runs as an agent user with limited permissions.\n\n```\nsudo useradd -m -s /bin/bash wes\nsudo useradd -m -s /bin/bash wes-agent\n\n# Give the trusted user wes the right to act as wes-agent\necho \"wes ALL=(wes-agent) NOPASSWD: ALL\" | \\\n  sudo tee \"/etc/sudoers.d/wes-agent\"\n\nsudo chmod 440 \"/etc/sudoers.d/wes-agent\"\nsudo visudo -c -f \"/etc/sudoers.d/wes-agent\" # syntax check\n```\n\nJust to be clear: I'm constraining the agent, not trying to defend against Wes himself. That's why I'm using `NOPASSWD: ALL`\n\nhere. Wes can run any command as his own agent user, but not as root, and not as other users.\n\nSo Wes won't launch the agent with a plain `claude`\n\n. It'll be more like this:\n\n```\nsudo -u wes-agent tmux new -s billing-api-claude\nclaude\n```\n\nExcept it'll be a single keypress in a wrapper over tmux: the session manager, more on that in the next section.\n\nIf you want the agent to push to Git on its own, set up a separate SSH key or a fine-grained PAT inside `wes-agent`\n\n, with minimal permissions for just the repos it needs. Don't forward the ssh-agent with `ForwardAgent yes`\n\nor `ssh -A`\n\ninto the agent user, or `wes-agent`\n\ncould end up with privileges it shouldn't have.\n\nA team lead should see all of the team's agent sessions and be able to attach to them; a senior should see the sessions of the juniors they mentor; everyone else sees only their own.\n\nThe simplest way to manage this is the same OS-level sudo privileges.\n\n```\n# Let lead Marcus see and attach to his own sessions, plus Wes's and Nadia's\necho \"marcus ALL=(marcus-agent,wes-agent,nadia-agent) NOPASSWD: ALL\" | \\\n  sudo tee \"/etc/sudoers.d/marcus-lead\"\n\nsudo chmod 440 \"/etc/sudoers.d/marcus-lead\"\nsudo visudo -c -f \"/etc/sudoers.d/marcus-lead\" # syntax check\n```\n\nAgain, `NOPASSWD: ALL`\n\nhere. This is the trusted-lead/senior model. This access is equivalent to full access to the employee's agent user, not just `tmux attach`\n\n.\n\nYou end up with this:\n\n```\nwes\n└─ sudo → wes-agent → only their own sessions\n\nnadia\n└─ sudo → nadia-agent → only their own sessions\n\nmarcus (lead)\n├─ sudo → marcus-agent → his own sessions\n├─ sudo → wes-agent    → Wes's sessions\n└─ sudo → nadia-agent  → Nadia's sessions\n```\n\nThe lead gets sudo rights over `wes-agent`\n\n, not over `wes`\n\nhimself. He can attach to Wes's session, kill it, inspect the agent's processes, but he doesn't become Wes. Wes's SSH keys, his secrets and credentials, his personal `.gitconfig`\n\n: all of that stays with Wes.\n\nIn process logs and Git commits, the lead's actions stay the lead's actions.\n\nThis isn't about defending against an evil lead. He's trusted. It's about cleaner attribution and not doing something under someone else's name by mistake.\n\nThe point isn't to build a \"real sandbox.\" It's this:\n\nAn even better practice is to isolate the work in rootless Docker/Podman or a VM. But for a quick start, for small teams and dev servers with no sensitive data, limiting agent permissions at the OS level can be enough.\n\nThis is nowhere near enterprise-grade security. But it's a lot better than one shared user. Any dev server quickly becomes a place with access to repos, personal data, secrets, internal APIs, and tokens.\n\ntmux doesn't know the context of agent sessions: which project, who owns it, which agent, and so on. And when there are many dev servers, it does nothing to pull all their sessions onto one screen.\n\nSo you need a thin layer over tmux that adds all this semantics.\n\nFor solo development there are already plenty of good tools: [Agent Deck](https://github.com/asheshgoplani/agent-deck), [AoE](https://github.com/agent-of-empires/agent-of-empires), [Vibe Kanban](https://github.com/BloopAI/vibe-kanban), [CCManager](https://github.com/kbwo/ccmanager), and others. Most of them support different agents. Agent Deck and AoE can run sessions in Docker. Agent Deck can work with your own sessions on other remote servers.\n\nThe AI vendors themselves are also building tools to manage sessions from a single window. Claude Code recently got [ /agent-view](https://code.claude.com/docs/en/agent-view), though multi-agent support and several personal subscriptions in one window are unlikely to land.\n\nThat helps the solo workflow, but it does not solve the team runtime problem by itself.\n\nFor team scenarios, what matters isn't pretty session lists. It's the constraints:\n\nThe question isn't \"how does one person launch 30 agents.\"\n\nIt's: **how do you give a team a manageable runtime?**\n\nIn my own setup, I use a small Python + Textual TUI wrapper over tmux called [uxon](https://github.com/vzd3v/uxon). Treat it as one reference implementation of the pattern, not as the point of the article. For more complex scenarios such as containers or enterprise environments, it's always custom.\n\nYou can use it as a starting point, or build your own tmux-based session manager with Claude in an evening or two, as long as you understand the requirements it has to meet.\n\nIn my view, these columns in the UI / TUI are probably enough:\n\nOn every server lead Marcus needs to reach, you create a separate Linux user `marcus`\n\nand grant it sudo rights over the relevant agent users:\n\n| Server | Linux user | Sudo access to agent user |\n|---|---|---|\nMarcus's server, `dev-marcus`\n|\n`marcus` |\n`marcus-agent` |\nWes's server, `dev-wes`\n|\n`marcus` |\n`wes-agent` |\nNadia's server, `dev-nadia`\n|\n`marcus` |\n`nadia-agent` |\n\nThe local `marcus`\n\ngets SSH access to the remote `marcus`\n\nusers by key:\n\n```\n# Marcus connects from his laptop to his own server\nmarcus-laptop: et dev-marcus\n\n# Marcus can reach Wes's server\nmarcus@dev-marcus: et dev-wes\n\n# Marcus can see Wes's AI sessions\nmarcus@dev-wes: sudo -iu wes-agent tmux ls\n\n# Marcus can attach to the session he wants\nmarcus@dev-wes: sudo -iu wes-agent tmux attach -t backend-debug\n```\n\nThe session manager should do this work in the background so that, in the TUI, Marcus sees both local and remote sessions, including other people's, running under other agent users such as `wes-agent`\n\nand `nadia-agent`\n\n, that the `marcus`\n\nuser has sudo access to on the remote servers.\n\nMarcus doesn't get some \"magic\" blanket access to every agent on every machine. On each server, access is defined with ordinary OS tools: you created the `marcus`\n\nuser, dropped in his SSH key, and granted specific sudo rights over the relevant agent users. It's rolled out like any infrastructure-as-code: through Ansible, Terraform/OpenTofu, or whatever stack you've settled on.\n\nIn this scheme, to revoke Marcus's access to Wes's sessions, you edit sudoers on Wes's server, and nowhere else.\n\nIt sounds primitive, but it's precisely the absence of a central point that answers most of the \"how do you administer all this centrally\" questions. Config rollout is centralized through Ansible/Terraform. Authority is validated locally on each server by plain sudo. The session manager on top is just a client that connects by key and asks each host what's available to it.\n\n```\n   et dev-wes\nuxon\n```\n\nOr your own wrapper.\n\nSees their sessions, which folders they're running in, their status, and the server load.\n\nAttaches to the one they need, or creates a new one and gets to work.\n\nCloses stale sessions with a single keypress.\n\nWhen a lead or senior opens the session manager, they see:\n\nAt the \"mature\" level, agent visibility and the absence of server chaos aren't the main problem anymore. The goal is to make the agent's execution environment genuinely constrained and reproducible.\n\n| Approach | What it does | When to choose it | Downsides |\n|---|---|---|---|\n| Separate OS-level users | Isolates process permissions, files, tokens, partly resources | Basic team runtime, fast start, no sensitive data or risks | Weak network and dependency isolation; boundaries sit at the OS-kernel level |\n| Dev container | Provides a reproducible environment: image, tools, dependencies, settings | When people and agents need the same dev environment | It's about reproducibility; protection depends on configuration |\n| Rootless Docker/Podman | Isolates the filesystem, processes, dependencies, some host permissions | When you need isolation for yolo mode but without enterprise security | The container shares the kernel with the host; mounted paths, secrets, network, and capabilities are critical |\n| VM | Isolates at the hypervisor level, separate OS kernel | Sensitive infrastructure, long-lived sandboxes | Heavier in resources, startup, and maintenance |\n| microVM / Kata / Firecracker | Almost like a VM | Sensitive infrastructure, many short-lived sandboxes | Harder to debug, orchestrate, and fit into the dev process |\n| Ready-made sandbox platform | Depends on the platform | When you need a production-grade sandbox without building your own | Vendor lock-in, cost, and open questions on data, compliance, and customization |\n\nContainers aren't a \"mature\" or enterprise level by themselves. If you've forwarded SSH keys, credentials, the Docker socket, the whole home directory, and unrestricted network into the container, that's not isolation. It's the old risks in new packaging.\n\nThe point is that agent sessions run not in a shared shell on the server, but in a predefined environment with clear boundaries:\n\nIt's better to give the agent more freedom inside a constrained runtime than to run it with limited permissions in the shared environment of a dev server.\n\nAt the enterprise level, on top of all this you may see custom agents on custom models, centralized policies and audit, sensitive-data controls, DLP, observability, quotas, SIEM/SOC, SDLC, and so on.\n\nThe approach above solves the most basic team problem: it makes working with agents more transparent, manageable, and scalable.\n\nIt doesn't make developers better, code higher-quality, the product more valuable, or the team automatically AI-native or agent-first.\n\nYou'll also need, or may need:\n\nIf the topic's interesting, I can devote the next part to level 2: how to run agent sessions in rootless Docker/Podman and what details to plan for. Or I could cover how to reshape team processes so that working with agents actually fits into them.\n\nFor now: I hope this was useful. If you set this up for your own team, I'd love to hear what you changed in the comments.", "url": "https://wpnews.pro/news/ai-coding-agents-need-a-team-runtime-not-just-more-tmux", "canonical_source": "https://dev.to/zakarov/ai-coding-agents-need-a-team-runtime-not-just-more-tmux-141", "published_at": "2026-05-30 09:10:17+00:00", "updated_at": "2026-05-30 09:41:36.481616+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "ai-infrastructure", "ai-products", "ai-startups"], "entities": ["Agent Deck", "AoE", "Vibe Kanban", "Claude Code", "BloopAI", "SSH", "tmux", "sudo"], "alternates": {"html": "https://wpnews.pro/news/ai-coding-agents-need-a-team-runtime-not-just-more-tmux", "markdown": "https://wpnews.pro/news/ai-coding-agents-need-a-team-runtime-not-just-more-tmux.md", "text": "https://wpnews.pro/news/ai-coding-agents-need-a-team-runtime-not-just-more-tmux.txt", "jsonld": "https://wpnews.pro/news/ai-coding-agents-need-a-team-runtime-not-just-more-tmux.jsonld"}}