Agent Session Manager Desktop
Run a whole team of AI coding agents side by side, each in its own persistent terminal tab that survives closing the window.
Per-dimension scores and reasoning
README is explicit that data stays local, there is no telemetry, and outbound traffic is limited to GitHub update checks, user-configured ntfy push, and a first-use npx call for Task Master — good transparency. However go.mod pulls in robotgo/gohook/uinput/portaudio, granting global input injection and audio capture far beyond session management, with no least-privilege discussion or runtime authorization boundary, so least_privilege scores 1. Rollback is strong: recycle bin, automatic snapshots with thinning retention, manual snapshots, and per-hunk revert justify 3. Sensitive data handling is thin: dictation can route audio to Google Speech API but storage/transmission of audio and credentials is undocumented, so 1. Dependency security gets 2 for pinned action SHAs and npm audit --audit-level=moderate in CI, but no Go-side vulnerability scanning. External effects (self-update, winget install of psmux, npx package fetch) are described without confirmation or failure-recovery detail, so 1. Source attribution only points at the author's own TUI repo with no third-party provenance, so 1.
The README explains missing tmux/psmux, crash survival, and activity-detection false positives, and its failure messages and recovery paths are internally consistent, so 2; but these are documentation assertions with no corresponding error-handling code or tests in the provided files, preventing a higher score. Dependency availability is documented in go.mod and CI (WebKitGTK, PortAudio, MSYS2 toolchain) with install steps, so 2. Self-consistency between README and the CI/release workflows on build tags and artifact naming is good, so 2.
Audience and scenarios are unusually concrete (many parallel agents, waiting alerts, mobile push, explicitly not for SSH/headless), so 3. Capability boundaries are stated for headless/SSH and custom agents but not systematically enumerated, so 2. Trigger precision is described well (shortcuts, command palette, updatable detection patterns) yet activity detection depends on pane output patterns and can misfire, documented only in prose, so 2. Environment fit covers Linux/macOS/Windows and WebKitGTK variants, but macOS is Apple-Silicon-only with Intel via Rosetta, so partial coverage, 2.
Information architecture is excellent: grouped features, shortcut table, on-disk layout, FAQ, so 3. Install notes cover deb/rpm/tar/installer plus runtime deps, so 3. Naming stability is mixed — binary asmgr-desktop versus product name Agent Session Manager, with the macOS bundle renamed — so 2. Examples and FAQ are rich, so 3. Known limitations exist but are scattered rather than consolidated, so 2. LICENSE is a complete MIT text, so 3. Versioning/changelog: the release workflow parses CHANGELOG.md and enforces SemVer, but no changelog content is provided, so 2. Maintenance responsibility is unclear: publisher unverified, no SECURITY/CONTRIBUTING or maintainer commitment, so 1.
Output usability is high: a desktop GUI with multiplexed terminals, diff/file editing, and task lists produces directly usable results, so 3. Marginal value is moderate: centralizing many agent sessions with waiting alerts adds real value over raw terminals, but the core still depends on tmux/psmux and existing agent CLIs, so 2. Cost/benefit is moderate: native deps (WebKitGTK, PortAudio), build complexity, and platform constraints raise cost, with clear benefit mainly for heavy multi-agent users, so 2.
Claim traceability is weak: many README claims (20 languages, byte-identical saves, self-update) have no supporting implementation or test evidence in the provided files, so 1. Cross-source corroboration is decent: CI workflows corroborate build tags, platform support, and binding verification, and browser test fixtures evidence some UI behavior, so 2. Fact/inference separation is poor: the README blends design intent with verified behavior without marking what was tested, so 1.
- go.mod pulls in robotgo/gohook/uinput/portaudio for global input injection and audio capture, a permission surface far beyond session management; static review cannot confirm runtime boundaries.
- Dictation may call the Google Speech API, but storage, transmission, and retention of audio and credentials are undocumented.
- External actions such as self-update, winget install of psmux, and npx fetching Task Master lack confirmation and failure-recovery detail.
- Publisher identity is unverified and there is no SECURITY/CONTRIBUTING file or maintainer commitment, leaving long-term maintenance responsibility unclear.
- Many README feature and quality claims have no supporting implementation or test evidence in the provided files and remain unverified assertions.
- macOS artifacts are Apple-Silicon-only with Intel requiring Rosetta, so platform coverage is incomplete.
What does this agent do, and when should you use it?
Agent Session Manager Desktop is a Wails (Go) + Svelte + xterm.js desktop application that puts Claude, Codex, Gemini, Aider, Amazon Q, OpenCode, custom commands or plain shells into tabs of a single window. Its execution model keeps every session inside a terminal multiplexer — tmux on Linux and macOS, psmux on Windows — so agents are not tied to the app's lifetime: close the window, restart the app or move to another machine and reattach where you left off. Terminal I/O travels over a local, token-authenticated WebSocket (xterm.js ⇄ Go ⇄ multiplexer), and output from tabs you are not viewing is buffered in the backend and replayed on return. Around the terminals it adds a project dashboard with per-repo Git status and Claude/Codex usage windows, file-by-file and hunk-by-hunk diff review, a CodeMirror 6 file browser/editor, commit history, per-directory tasks with deadlines, cross-session history search, and opt-in desktop plus ntfy mobile notifications. It self-updates on all three platforms and keeps its state locally under ~/.config/agent-session-manager-desktop, contacting the network only to check for updates, to push notifications, or to fetch the Task Master MCP package.
On session creation it opens a multiplexer window and runs the chosen agent's command inside it (Claude, Gemini, Aider, Codex, Amazon Q, OpenCode, a custom command or a shell), optionally with its own working directory. Input and output are forwarded through a local token-authenticated WebSocket between xterm.js and the Go backend; output for unviewed tabs is held in the backend and replayed instead of repainted. It reads pane output to derive busy / waiting / idle status, aggregates waiting tabs into the ⏳ attention inbox with one-click yes/no/Enter/Esc replies, and can emit system notifications or ntfy pushes. It supports multiple tabs per session, resume and Claude thread forking, a panel for Claude --bg background agents, session templates, a searchable saved-command library with {{name:default}} parameters, a Ctrl+K command palette and a Ctrl+J numbered jump list. Around the terminal it renders a project dashboard (branch, dirty state, ahead/behind, last commit, Claude and Codex rate-limit usage), a Git diff view with per-file and per-hunk revert, a CodeMirror 6 editor that preserves line endings, BOM and trailing newline, commit history via Ctrl+Shift+Y, global history search via Ctrl+Shift+F, and per-directory tasks with optional Task Master actions through the task-master-ai MCP package. State is written to sessions.json, commands.json, activity-stats.json, backups/ and asmgr-desktop.log, while tasks live in .taskmaster/tasks.json inside each working directory.
- A developer running three or four Claude Code or Codex sessions at once who wants one window showing which agent is blocked on input instead of alt-tabbing between terminal windows.
- Someone doing a long refactor who needs to shut the laptop or restart the app: sessions live in tmux/psmux, so they reopen the app and reattach in one click.
- A user who wants to be pinged on their phone when an agent starts waiting — they set an ntfy topic URL in Settings → Notifications and install the ntfy app.
- A reviewer who wants to inspect an agent's changes file by file before committing and revert exactly one hunk, stepping through changes with Ctrl+F7.
- A Windows developer who does not want WSL or MSYS2: the app can install and drive the native psmux multiplexer via winget.
- A keyboard-driven user who wants to drive everything from the Ctrl+K palette, the Ctrl+P saved commands, the Ctrl+J jump list and rebindable shortcuts.
What are this agent's strengths and limitations?
- Sessions run in tmux/psmux rather than in the app process, so agents keep working when the window is closed and reattach after an app restart or a machine hop.
- Full three-platform delivery: .deb/.rpm on Linux, a macOS .app (Intel via Rosetta 2), a per-user Windows installer that needs no administrator rights, plus in-place self-updates on all three.
- Review tooling operates on the session's own output: file-level and hunk-level diff revert, a CodeMirror 6 editor that preserves line endings, BOM and trailing newline byte-for-byte, Ctrl+Shift+Y commit history and Ctrl+Shift+F cross-session history search.
- Attention handling is concrete: the ⏳ inbox lets you answer yes/no/Enter/Esc without switching tabs, with opt-in system notifications and ntfy mobile push (all off by default).
- Agent-agnostic and customizable: Claude, Gemini, Aider, Codex, Amazon Q, OpenCode, a shell or a custom command, plus imported Konsole/kitty/Alacritty/WezTerm/Ghostty/iTerm2 colour schemes and editable shortcuts.
- Local-first with recovery: no telemetry, deleted sessions and tabs go to a recycle bin, settings and session lists are snapshotted on a thinning schedule, and task files are backed up separately.
- Hard runtime dependency on a terminal multiplexer: without tmux (Linux/macOS) or psmux (Windows) no session can be created, and the app can only offer the install command at startup.
- Desktop-only by design: the README states it cannot be used over SSH or on a headless box, leaving the separate TUI version for those environments.
- Heavy build prerequisites: Go 1.24+, Node.js + npm, the Wails CLI and WebKitGTK on Linux, where Ubuntu 24.04+/Fedora 40+ additionally require -tags webkit2_41.
- All tabs share one WebKit main thread and the backend replays buffered output, so the project itself flags that a busy background agent must not starve the foreground tab; sluggish terminals require switching between canvas, DOM and WebGL renderers.
- Task data lives in .taskmaster/tasks.json inside each working directory rather than the central config directory, so tasks travel with the code and need their own backup or version-control policy.
- Some conveniences reach outside the app: ntfy needs your own topic and phone app, and Task Master AI actions require fetching the task-master-ai MCP package through npx.
How do you install or deploy this agent?
A terminal multiplexer is required before first launch: tmux on Linux, brew install tmux on macOS, and psmux on Windows (the app can install it with winget install psmux; no WSL or MSYS2 needed).
Linux:
sudo dpkg -i asmgr-desktop_*_linux_x86_64.deb # Debian/Ubuntu
sudo rpm -i asmgr-desktop_*_linux_x86_64.rpm # Fedora/RHELThis installs /usr/bin/asmgr-desktop with an app-menu entry; runtime deps libwebkit2gtk-4.1-0 / webkit2gtk4.1 and tmux are pulled in automatically.
macOS (Apple Silicon; Intel via Rosetta 2):
tar -xzf asmgr-desktop_*_darwin_arm64.tar.gz
move asmgr-desktop.app to /Applications, then: brew install tmuxWindows (x64): run asmgr-desktop_*_windows_amd64_setup.exe. It installs per-user, never asks for administrator rights, and supports in-place updates; a .tar.gz is also available for a portable setup.
Building from source requires Go 1.24+, Node.js + npm, the Wails CLI and WebKitGTK:
wails build -tags webkit2_41 # Ubuntu 24.04+/Fedora 40+ where only webkit2gtk-4.1 exists
wails build # other / older WebKitGTKThe binary lands in build/bin/. For development, wails dev -tags webkit2_41 also serves the frontend at http://localhost:34115 with Go methods bridged.
How do you use this agent?
- Press Ctrl+Shift+N to create a session: pick the agent, the working directory and a name. It starts in its own multiplexer window and appears in the sidebar; press Enter to attach to the live terminal.
- Press Ctrl+T for the full new-tab dialog (agent, arguments, directory) or Ctrl+Shift+T for a shell tab that only asks for a name; move between tabs with Ctrl+PageUp / Ctrl+PageDown.
- Group related sessions with Ctrl+Shift+G, star the ones you return to with Ctrl+Shift+8 and jump to them with Ctrl+Shift+1…7; add the current tab to the jump list with Alt+J and land on entries with Ctrl+J plus a digit.
- The ⏳ count in the header is every agent waiting on input: click to jump, or answer yes / no / Enter / Esc from the dropdown. Enable desktop notifications, a sound, and an ntfy topic such as https://ntfy.sh/my-topic in Settings → Notifications for mobile push.
- Switch between terminal, Git diff, files, notes and tasks from the view bar. In the diff, revert a file or a single hunk, step with Ctrl+F7 / Ctrl+Shift+F7, open commit history with Ctrl+Shift+Y, search every session's history with Ctrl+Shift+F, and search the current terminal's scrollback with Ctrl+Shift+L.
- Rebind any shortcut in Settings → Shortcuts; Ctrl+Shift+H opens help generated from that same list. State lives in ~/.config/agent-session-manager-desktop (sessions.json, commands.json, backups/, activity-stats.json, asmgr-desktop.log), and task files live in .taskmaster/tasks.json inside each working directory.