In brief: agent-deck is a young but actively maintained Go terminal session manager for AI coding agents. This agent-deck session manager review is an observed source and documentation review, not a runtime test. Adoption makes sense only for teams that already run several Claude, Gemini, Codex, or OpenCode sessions daily and can absorb near-weekly releases with behavior changes; start with a pilot that checks session safety, repo-script consent, and upgrade handling.

Key facts at a glance

Who this review is for

The problem this article addresses is supervision. An engineering lead, founder, or operations manager has started letting AI coding agents do real work and now needs to know which sessions are running, waiting for input, or failing; which agent is attached to which repository branch and account; and what the work costs. Once sessions multiply across projects and tools, the question shifts from which AI assistant to use to how to run several safely and see what they are doing. The reader for this review is at the evaluating stage, deciding whether agent-deck should become standard tooling, not already committed to it.

What agent-deck claims to solve

The repository describes agent-deck as a “Terminal session manager for AI coding agents. One TUI for Claude, Gemini, OpenCode, Codex, and more.” The README summarizes the intended workflow in one line:

Agent Deck is mission control for your AI coding agents.

Maintainers describe one terminal showing every session, running, waiting, or done, with one-keystroke switching, groups, search, forking, git worktrees, cost tracking, and a conductor that supervises a fleet from a phone through Telegram, Slack, or Discord. No runtime test was performed for this review, so treat every feature description below as a maintainer claim to verify in a pilot, not as an observed result.

Use cases the documentation supports

Read as claims, the project maps onto real operating problems:

• Cross-tool session visibility: the README documents per-session status detection (running, waiting, idle, error), fuzzy search, global search across Claude conversations, a tmux notification bar, remote sessions over SSH, and a web UI that starts on http://127.0.0.1:8420.
• Parallel agents on one repository: git worktrees per session, opt-in sparse-checkout inheritance for monorepos, worktree setup and destruction hooks, and cleanup logic that the v1.14.0 release notes say never proposes unpushed, dirty, live, or inspection-failing worktrees for removal.
• Isolation: sessions can run in Docker containers while the project directory stays bind-mounted, and the README says host tool authentication is shared into containers, including Keychain extraction on macOS.
• Fleet supervision: the conductor starts a supervisor session that escalates to Telegram, Slack, or Discord, and watchers can wake it from outside events such as GitHub activity, mail, ntfy pushes, or meetings, according to the README docs.
• Tool and configuration management: MCP servers can be toggled per project or globally, Claude skills can be attached from a managed pool, and per-group Claude config directories and env files let different groups authenticate as different accounts; the README also documents account switching with conversation migration.
• Cost and usage visibility: a Cost Dashboard and session analytics are documented, and release notes show context-window entries being added for newer model families.

Maintenance signals from the repository and release history

agent-deck is a young project. The repository was created on 3 December 2025, making it roughly nine months old at this review, and its main branch was last pushed on 4 September 2026. Release cadence through August 2026 has been near weekly, with v1.11.0 on 1 August, v1.12.0 on 14 August, v1.13.0 on 16 August, v1.14.0 on 22 August, and v1.15.0 on 23 August. That tempo fixes problems quickly and also creates real upgrade work for operators.

The release record shows a consistent correctness and safety focus. In the v1.11.0 notes, which maintainers describe as a security and correctness release, repository-supplied worktree scripts moved to explicit consent, skills-catalog path handling was hardened, remote worktree creation was refused, session send exit codes changed so automation cannot mistake typed input for submitted input, and conversation identity is checked before resume. The v1.14.0 notes say a failed read can no longer rebuild a user’s Claude config and that worktree cleanup cannot destroy work. The v1.15.0 notes add a first phase for adopting existing agent setups read-only and record the removal of operational capture artifacts that had been shipped by accident. Community contributors are credited in several release notes, and the README says incoming PRs are validated within about a day.

The capacity counter-signal is equally visible. The project is led by one maintainer who is explicitly looking for one or two regular co-maintainers, and there were 60 open issues in the 4 September 2026 snapshot. Weekly behavior changes, a documented release-hygiene mistake, and a single-maintainer bus factor are the conditions under which the rest of this review should be read.

Deployment concerns and checks before production

agent-deck is a per-developer terminal tool, not a service to deploy. The README lists macOS, Linux, and Windows through WSL, which means team rollout is a configuration, policy, and upgrade problem rather than an install problem.

• Confirm tool coverage against your exact CLIs and accounts. Fork support is documented for Claude, OpenCode, Pi, and Codex; Codex forking requires a codex CLI with codex fork support, which maintainers say they verified against codex-cli 0.137.0. First-class dsh tool support arrived in v1.14.0. Check each tool you depend on before standardizing.
• Pin versions and treat upgrades as reviews. August 2026 shipped five releases, and some changes were deliberate behavior changes: the README records that v1.9.55 changed what Enter does in the new-session dialog, and the v1.11.0 notes say session send now exits non-zero when a message was typed but never confirmed submitted, with action required for existing automation.
• Decide your repo-script trust policy. Since v1.11.0, repository-supplied worktree setup and destruction scripts require explicit consent by default, with a prompt, always, or never setting, and non-interactive callers fail closed. These scripts run with your environment, so keeping the prompt default is prudent until a repo is trusted.
• Set a secrets and transcript policy before Docker sandboxes and worktrees become routine. The README documents a .worktreeinclude file for copying gitignored files such as .env into new worktrees, and it says host tool authentication is shared into sandboxed containers, including Keychain extraction on macOS. Sessions also hold conversation transcripts with repository context.
• Audit remote channels and web access. The conductor connects to Telegram, Slack, or Discord, watchers can feed it external events, and the web UI binds to 127.0.0.1:8420 by default. v1.11.0 refused remote worktree creation. Decide who holds channel tokens and which machines may reach the tool.
• Keep claims separate from verified facts. The README states that MCP socket pooling cuts memory use by 85–90 percent with roughly three-second recovery, and the v1.12.0 notes state that a Go toolchain bump cleared four stdlib vulnerabilities flagged by govulncheck. Those are maintainer statements; nothing in this review independently confirms them. Back up the config directory (documented at ~/.config/agent-deck/config.toml by default) and session state before upgrades; uninstall supports a keep-data option.

Limitations and unknowns

This review is an observed source and documentation review of the public repository as of 5 September 2026, with release notes through v1.15.0 as the primary behavioral evidence.

• No runtime verification: none of the session, worktree, sandbox, or conductor behaviors were executed for this review.
• Single-source claims: performance numbers, security statements, and feature behavior come from the maintainers’ README and release notes.
• Snapshot age: the project is roughly nine months old, the CLI and TUI are still changing rapidly, and future releases may alter defaults again.
• Maintenance capacity: 60 open issues, one lead maintainer recruiting co-maintainers, and a support model of GitHub issues and Discord (the repository homepage links to a Discord invite) with no SLA.
• Popularity is not quality: 841 stars and 144 forks on 4 September 2026 show interest, but stars do not verify session safety or upgrade stability.

Where custom development or maintenance will be needed

Even where agent-deck fits, the documentation points to recurring work an internal team or a contractor must own:

• Tool integration: any CLI without first-class support needs configuration, wrappers, or code, and integrations can break when vendors change their own CLIs. The codex fork requirement and v1.14.0 dsh support are examples of this moving surface.
• Policy and configuration: groups, per-client or per-environment Claude accounts, default worktree locations, sandbox settings, repo-script consent, and watchers must be designed, documented, and reviewed as the team changes.
• Automation: scripts that call session send, fork, status, or JSON surfaces must be tested against documented exit-code behavior such as the v1.11.0 change.
• Upgrade and incident routine: near-weekly releases mean changelog review, pilot testing, rollback planning, and diagnosis of tmux, SSH, container, and config failures.
• Integration beyond the tool: the evidence shows a local web UI and CLI/JSON interfaces, not a managed enterprise console, so reporting, access control, or audit needs would be custom work.

Who should and should not use it

Strong candidates

• Engineering leads or operations managers running several active AI coding sessions across multiple CLIs on a regular basis.
• Teams whose agents share repositories and need isolated worktrees or sandboxes to avoid collisions.
• Terminal-first organizations already using tmux, SSH, and Linux or macOS, where WSL is an acceptable Windows path.
• Teams that want cross-tool visibility of waiting, running, and failed sessions plus a cost view, and have someone responsible for configuration.

Weak candidates

• A developer running one or two agent sessions occasionally; the TUI, tmux, and config overhead outweigh the benefit.
• Windows-native-only environments, since support is macOS, Linux, and WSL.
• Teams without a terminal-first culture or without an owner for tooling, upgrades, and incidents.
• Organizations that need centralized authentication, audit trails, or a support contract; the evidence shows an open-source tool with issue-tracker and Discord support.

Alternatives and evaluation questions

Alternatives include plain tmux or screen with per-tool sessions, each AI CLI’s native session resume, IDE-based agent panels, and custom orchestration for larger fleets. Agent-deck’s differentiators, as claimed, are the cross-tool registry, status detection, and worktree or Docker isolation. Ask these questions before standardizing:

1. How many concurrent sessions does each developer realistically run, and across which CLIs?
2. Do agents ever work the same repository at the same time, and what worktree and branch policy would prevent collisions?
3. Who owns near-weekly upgrades, changelog review, and rollback, including deliberate changes like the session send exit-code behavior?
4. Where do transcripts, .env-style files, MCP credentials, and channel tokens live, and who can read them?
5. Is phone-based supervision through a conductor required, or is local status and notification enough?
6. Are tmux, Docker, and SSH already standard in your environment?
7. Can your team accept GitHub-issue and Discord support while the maintainers look for co-maintainers?

Verdict

Conditional adoption is the honest verdict for agent-deck as of v1.15.0 (23 August 2026) and the repository snapshot of 4 September 2026. The release record shows a maintainer and a contributing community acting on real safety problems, including script consent, destructive cleanup, resume identity, and delivery truth, which is a better signal than the star count alone. The conditions are strict, though: your team must already treat several concurrent AI coding sessions as normal work, and someone must own configuration, upgrades, and incident diagnosis. If those conditions are not met, stay with tmux plus each CLI’s native session handling and revisit after the project stabilizes its maintenance model.

What I can do next

If you are at the supervision point this review describes, I can help with the adoption work: scoping agent-deck against the agent CLIs, repository layout, and accounts you actually use; defining group, worktree, sandbox, and repo-script policies; writing the small integrations or automation around session commands; and setting up an upgrade and incident routine that matches the project’s release cadence. This is practical AI workflow work within my software development services rather than a product recommendation.

To give you a concrete plan rather than generic advice, I would need a short inventory first: operating systems and tmux versions, the AI agent CLIs and accounts in use, expected concurrent session counts, whether agents share repositories, and how transcripts and credentials are currently stored. With those details I can produce a written adoption plan and pilot checklist for your environment. I cannot promise that agent-deck will be the right fit or that a pilot will pass until that information is in hand. Contact me about your agent workflow if that is the decision you are facing.

Sources

• agent-deck repository
• agent-deck v1.15.0 release notes
• agent-deck v1.14.0 release notes
• agent-deck v1.11.0 release notes