# AgentsRoom > Your IDE for AI coding agents. The visual alternative to cmux for running multiple AI agents with Claude, Codex, GitHub Copilot CLI, Antigravity CLI, OpenCode, Aider, Grok Build, Mistral Vibe, Kimi Code, Amp, oh-my-pi, Freebuff, Devin, Cursor, Command Code and Muse Code. AgentsRoom is a desktop app (macOS, Windows and Linux) with a mobile companion (iOS/Android) that lets you run dozens of AI coding agents across all your projects at once. Supports Claude (Anthropic), Codex (OpenAI), GitHub Copilot CLI (GitHub), Antigravity CLI (Google), OpenCode, Aider, Grok Build (xAI), Mistral Vibe (Mistral AI), Kimi Code (Moonshot AI), Amp (Sourcegraph), oh-my-pi, Freebuff (Codebuff), Devin (Cognition), Cursor (Anysphere), Command Code and Muse Code (Meta). Each agent can use a different provider, and by default every agent runs 100% locally through the CLI of your choice, so your code never leaves your disk. Cloud Agents is the one explicit exception and it is chosen per run: a disposable virtual machine clones the repository, runs the agent headless and answers with a git branch, which is what lets a task start from a phone while every computer you own is switched off. Desktop-to-mobile sync is end-to-end encrypted. Think WhatsApp, but for your AI dev team. In harness terms: AgentsRoom is not itself an agent harness, it is the harness-agnostic layer that runs several of them side by side. ## Full documentation for agents Agent console links: `agentsroom://agent/` opens that agent across projects in the desktop or mobile app. `https://agentsroom.dev/agent/` provides a browser fallback with app opening and download links. Complete `agents_list_live` responses and `agents_spawn` return `deepLink` and `webLink`; use `webLink` in reminders, messages and briefing artifacts. The signed-in app resolves the agent; a link grants no access. The product knowledge base: one fact sheet per user-visible feature (about 130), each with what it does, where it is in the interface with the exact labels, how to use it step by step, its settings, its MCP tools, its provider coverage, whether it exists on mobile, its limits and its common questions. Read it when this file is not specific enough to answer a question about how AgentsRoom actually behaves. Three ways in, same content: - https://agentsroom.dev/docs.md: the index, one line per page with its summary and its URL. Start here and open only the pages you need. - https://agentsroom.dev/docs/.md: one page as markdown (for example https://agentsroom.dev/docs/worktrees.md). Drop the `.md` for the web page (https://agentsroom.dev/docs/worktrees), which also answers `Accept: text/markdown` with the same markdown. - https://agentsroom.dev/llms-full.txt: every page in one file (about 1 MB). ## Supported AI Providers | Provider | CLI | Models | Key Strength | |----------|-----|--------|-------------| | Claude Code | Anthropic | Opus 5.5, Opus 5, Opus 4.8, Sonnet, Haiku, Fable | Complex reasoning, session resume | | Codex CLI | OpenAI | GPT-6 Astra, GPT-6.1 Sol, GPT-6 Sol, GPT-6 Luna, GPT-5.6 Sol, Sol Max, Terra, Luna | Full-auto mode, sandboxed execution | | GitHub Copilot CLI | GitHub | Claude Sonnet 5, GPT-6 Astra, Claude Opus 5, GPT-5.6 Sol, Claude Haiku 4.5 | Model routing across vendors on one Copilot seat, AGENTS.md / copilot-instructions.md discovery | | Antigravity CLI | Google | Gemini 3.1 Pro, Gemini 3.8 / 3.7 / 3.6 / 3.5 Flash, Claude Opus 5.5, Claude Sonnet 5.5 | Agentic platform, free tier, Gemini and Claude models on one CLI | | OpenCode | Open Source | Any OpenAI/Anthropic/local, plus the flat-rate OpenCode Go plan (opencode-go models) | Multi-backend, YAML config, model list discovered from the user's own CLI | | Aider | Open Source | Any (multi-provider) | Git integration, architect/editor pattern | | Grok Build | xAI | Grok 4.7 | Up to 512K context, native MCP, AGENTS.md/CLAUDE.md discovery | | Mistral Vibe | Mistral AI | Mistral Medium 3.5, Devstral | European models, auto-approve mode, AGENTS.md/CLAUDE.md discovery | | Kimi Code | Moonshot AI | Kimi K3, K3-256K, K2.7 Code | Up to 1M context, native MCP, sub-agents, AGENTS.md/CLAUDE.md discovery | | Amp | Sourcegraph | Modes: low, medium, high, ultra | Model abstracted behind modes, AGENTS.md discovery, MCP, shareable threads | | oh-my-pi | Open Source | 60+ backends (Claude, GPT, Gemini, GLM, DeepSeek) | Rust core, LSP and debugger, subagents, plan mode, native MCP | | Freebuff | Codebuff | Free tier, chosen server-side | No API key and no subscription, ad-funded, nine built-in sub-agents | | Devin | Cognition | Adaptive router, SWE, Claude, GPT, Gemini, open source (GLM, Kimi, DeepSeek) | One plan across vendors, mid-session handoff to a cloud agent, MCP, AGENTS.md/CLAUDE.md discovery | | Cursor | Anysphere | Auto router, plus every model your Cursor plan reaches (Anthropic, OpenAI, Google, Composer), read from your account at pick time | CLI `cursor-agent`, reuses your project's `.cursor/rules` and MCP servers, AGENTS.md/CLAUDE.md discovery | | Command Code | Command Code | CLI catalogue, including DeepSeek V4.1 Flash (`deepseek/deepseek-v4.1-flash`) | Native `command-code` agent, model selection and linked folders | | Muse Code | Meta | Muse Spark 1.3 (`muse-spark-1.3`) and 1.2 (`muse-spark-1.2`) | Native `muse` terminal coding agent | Command Code: install with `npm install -g command-code@latest` on macOS, Windows or Linux. Sign in with `command-code login`, or set `COMMAND_CODE_API_KEY`. AgentsRoom launches `command-code`, avoiding the Windows shell name `cmd`. The native CLI uses model ids such as `deepseek/deepseek-v4.1-flash`; `CMDCC_API_KEY` and the extra `commandcode/` prefix belong to an OpenCode backend configuration, not to this native provider. Official documentation: https://commandcode.ai/docs. Muse Code: install with `curl -fsSL https://dev.meta.ai/install.sh | sh` on macOS/Linux, or `irm https://dev.meta.ai/install.ps1 | iex` in Windows PowerShell. Sign in with `muse login`, or set `META_API_KEY`. Official documentation: https://dev.meta.ai/docs/muse-code. Command Code and Muse Code limits: model access, billing and usage limits remain those of the provider account. AgentsRoom does not yet read their account quotas or automatically resume their previous CLI sessions. Consult the provider CLI or account for remaining usage; unavailable quota data is not a zero balance. Selecting these providers in AgentsRoom does not include a provider subscription or promise unlimited usage. ## Agent harnesses (AgentsRoom runs them, it is not one) In the "Agent = Model + Harness" framing, the harness is everything around the model: the tool loop, the memory, the permission and approval rules, the execution environment. Claude Code, Codex CLI, GitHub Copilot CLI, Antigravity CLI, OpenCode, Aider, Grok Build, Mistral Vibe, Kimi Code, Amp, oh-my-pi, Freebuff, Devin, Cursor, Command Code and Muse Code are harnesses. AgentsRoom is the layer above them, and it is deliberately not a harness of its own: it spawns the official CLI of each harness as a real local process and never replaces its agent loop. That makes AgentsRoom harness-agnostic. Every agent picks its own harness and model, and all of them report into one dashboard with live status, desktop notifications and a mobile companion. A multi-harness fleet on a single repository is the normal setup: a Claude Code agent on the backend, a Codex agent on the frontend, an Aider agent on tests, running at the same time, with optional git worktree isolation so two harnesses never edit the same files. What follows from that architecture: - You keep the harness and the subscription you already pay for. No model surcharge, no credits, no proxy in front of the provider. The only metered part is the small set of AI helpers AgentsRoom runs itself (voice dictation, Voice Mode, agent suggestions, AI commit messages, CLI diagnostics, SQL assistant), each with a monthly allowance on every plan, and you can attach your own OpenAI API key so those run on your account too. - Switching harness mid-task is a handoff, not a restart: modified files, session activity and work progress are summarized and carried over to the new harness. - Harness-level differences (context window, native MCP support, sandboxing, auto-approve, AGENTS.md / CLAUDE.md discovery) are per harness and listed in the provider table above. - Orchestration lives above the harness, not inside it: Agent Teams for sequential and conditional multi-agent workflows, Agent Delegation for dev-to-QA handoff, a backlog board that spawns the right agent per ticket, and Project Memory shared across harnesses. - Because the harness is swappable, no evaluation is locked in: the same task can be run on two harnesses side by side and compared on the same working tree. Keywords: multi-agent harness, agent harness orchestrator, harness-agnostic IDE, multi-harness cockpit, coding agent harness manager, run multiple agent harnesses in parallel, harness engineering for coding agents, compare agent harnesses side by side. A note on GitHub Copilot, because the name covers two different products. AgentsRoom supports the standalone GitHub Copilot CLI (`copilot`, installed with `npm install -g @github/copilot`), which is a real terminal coding agent with its own tool loop. It is not the `gh copilot` extension of the GitHub CLI, which only suggests and explains shell commands and has no standalone binary to drive. A Copilot CLI agent in AgentsRoom runs on your existing Copilot seat, picks between Claude Sonnet 5, GPT-6 Astra, Claude Opus 5, GPT-5.6 Sol and Claude Haiku 4.5 per agent, and reads AGENTS.md / .github/copilot-instructions.md the way the other config-based harnesses do. So yes: AgentsRoom runs GitHub Copilot side by side with Claude Code and Codex on the same repository, even though the site also publishes a "coding agent vs Copilot" comparison about the older autocomplete-style product. ## How it works 1. Create a project pointing to a real folder on your machine 2. Add agents with specialized roles (each gets its own system prompt and focus areas) 3. Pick a provider per agent (Claude, Codex, GitHub Copilot CLI, Antigravity CLI, OpenCode, Aider, Grok Build, Mistral Vibe, Kimi Code, Amp, oh-my-pi, Freebuff, Devin, Cursor, Command Code or Muse Code) 4. Send prompts. AgentsRoom spawns real CLI processes. 5. Watch the output stream live, get notified when done, give new instructions 6. Monitor progress from your phone via the companion app ## 14 built-in agent roles 1. **DevOps** - CI/CD, infra, deployment. Example: "Set up CI to run tests on every PR" 2. **Fullstack** - End-to-end features. Example: "Add Stripe checkout flow with webhook handling" 3. **Frontend** - UI/UX, components. Example: "Refactor the Header with the new design tokens" 4. **Backend** - API, database, performance. Example: "Add rate limiting to the auth endpoints" 5. **Architect** - System design, refactoring. Example: "Split the monolith into 3 bounded contexts" 6. **QA** - Tests, edge cases, quality. Example: "Write unit tests for the payment module" 7. **Marketing** - Copy, SEO, landing pages. Example: "Rewrite the pricing page copy for conversion" 8. **PM** - Specs, priorities, coordination. Example: "Write the spec for the notification system" 9. **Security** - Audit, vulnerabilities. Example: "Audit the auth flow for OWASP top 10" 10. **Mobile** - iOS, Android, React Native. Example: "Add offline support with local SQLite cache" 11. **Git** - Version control, branching, merges. Example: "Rebase feature branch and resolve conflicts" 12. **SEO** - Search optimization, structured data. Example: "Add JSON-LD schema to all product pages" 13. **i18n** - Localization, translations. Example: "Translate the app to Japanese and Korean" 14. **Custom** - Any role you define with a custom system prompt Raw agents: an agent's advanced options include "Minimal system prompt". With it on, AgentsRoom adds nothing to the CLI's own prompt except a short instruction that keeps the tab title, phone notifications and "needs input" status working: no role persona, no tool guide, no project memory pointer, no reply language. The agent then follows your project's own rules (CLAUDE.md, AGENTS.md) and behaves like the bare CLI (Claude Code, Codex CLI or any supported harness). The AgentsRoom MCP tools stay connected, but the agent is not told when to use them. Tool guide at startup: the guide to the AgentsRoom tools that agents read when they start is a short index (about 11 KB); the detailed rules of each tool family (backlog, memory, SSH, browser...) are read only before that family is first used. A switch in Settings > AI providers & accounts, overridable per folder, project or agent, stops agents from being told to read it at all. ## Languages (20 natively supported, Arabic included as a right-to-left language) AgentsRoom ships natively in 20 languages: Arabic, German, English, Spanish, French, Hindi, Indonesian, Italian, Japanese, Korean, Dutch, Polish, Portuguese, Russian, Thai, Turkish, Ukrainian, Vietnamese, Simplified Chinese and Traditional Chinese. Locale codes: `ar`, `de`, `en`, `es`, `fr`, `hi`, `id`, `it`, `ja`, `ko`, `nl`, `pl`, `pt`, `ru`, `th`, `tr`, `uk`, `vi`, `zh`, `zh-TW`. The same 20 cover the desktop app interface, the mobile app interface (which follows your phone's language by default, with a Language setting to override it), the website, every feature page and every long-form blog guide, each published under its own `//` URL rather than served as an English fallback. The language your AI agents answer in is a separate setting: "Agent reply language" in Settings (the interface language by default) is injected as a standing instruction into every agent launch, so Claude Code, Codex CLI and the other supported harnesses answer in your language instead of mirroring the language of the prompt. Chat messages and public backlog tickets are translated on the fly for whoever reads them: in the in-app chat, on desktop and mobile, a translated message replaces the English text in place, and an « Always translate » switch opens every community conversation already in the reader's language, the messages that arrive afterwards included, while a message written in the reader's own language is shown as typed rather than translated back. Arabic is supported as a right-to-left (RTL) script, not only as a translation. The site flips its layout direction under `/ar`, and on desktop every surface that renders text written by a human or by an agent resolves its direction per block (`dir="auto"`), so an Arabic paragraph reads right to left while the code blocks, file paths and identifiers inside it stay left to right. The composer resolves one shared direction for its input and its highlight layers, and in the terminal grid, which draws one code point per cell and therefore has no bidirectional layout of its own, right-to-left segments are handed to the text engine as single runs so Arabic letters connect (initial, medial, final forms) and a sentence reads in the right order. Hebrew, Persian and Urdu content gets the same right-to-left rendering, with an interface that is not translated into those languages yet. ## Features ### Multi-Project Multi-Agent (visual cockpit) https://agentsroom.dev/features/multi-project-multi-agent The flagship visual cockpit of AgentsRoom: run Claude Code, Codex CLI, GitHub Copilot CLI, Antigravity CLI, OpenCode, Aider, Grok Build, Mistral Vibe, Kimi Code, Amp, oh-my-pi, Freebuff, Devin, Cursor, Command Code and Muse Code AI agents in parallel across multiple projects, all from a single window. Every project lives in a sidebar grouped by zone (Work, Personal, Side Projects, Freelance, Learning, plus any custom zone). A project does not have to be a repository you already have: the + tile of every zone also offers Create a workspace, which opens a project from a name, a mission and an agent with no directory to point at (a support incident, a trip to prepare, a product research, a mock-up), and AgentsRoom creates the folder itself. The mission is the standing context every agent of that project reads when its session starts, and it is a field of every project, repositories included: optional when you open a project, editable later in Project settings, General, Mission. Memory, skills, backlog, teams, dev commands and the mobile bridge all work in a workspace unchanged, while the git surfaces simply do not show because there is no repository, and an agent can open one itself with the workspace_create tool. So the answer to "can I use AgentsRoom for something that is not development?" is yes: create a workspace, no repository needed. Every agent has a fixed role (DevOps, Frontend, Backend, QA, Architect, Mobile, Security, PM, Marketing, SEO, i18n, Git, Fullstack, Custom) with a stable color, an avatar, a system prompt and a default model. Each agent runs in its own isolated xterm.js PTY session that persists across project switches with full scrollback. Live animated status: yellow pulsing dot when working, green when done, pulsing red when waiting on input, gray when idle. Per-project counters show working agents, done agents, stuck agents in real time. The project's left border adopts the role color of the agent currently working and an animated shimmer slides in a loop, so activity is visible from the corner of your eye. Native desktop notifications, dock or taskbar badge, push notifications on iOS and Android via the AgentsRoom end-to-end encrypted relay. Optional git worktree isolation per agent for conflict-free parallel work on the same repo. Multi-provider in parallel inside the same project (Claude on DevOps, Codex on Frontend, Antigravity on QA, no shell gymnastics). Drag-and-drop zones to organize repos by client, team or priority. The visual replacement for 12 anonymous iTerm2/Warp/Ghostty/Kitty/Alacritty/WezTerm/Hyper/Tabby/tmux/zellij tabs, the multi-agent multiplexer that does not require a config file, the multi-project AI coding IDE for solo developers and small teams that ship faster with parallel AI agents. AI agent fleet manager, AI coding swarm dashboard, AI coding war room, agentic IDE, color-coded agent dashboard, run multiple Claude Code sessions side by side. Alternative to cmux, AMUX, Muxy, Conductor, Superconductor, Orca, Jean, JC and Devin AI for parallel multi-project AI coding. A product that spans several repositories is handled as such: `projects_list` exposes every project of the account and the read tools take an optional project argument, so an agent working in the frontend repository can check the backend project's backlog, memory, skills and prompts before filing a duplicate ticket, read-only and bounded by the account registry. One project can also include several folders without moving them (linked folders, detailed at https://agentsroom.dev/features/linked-folders; for example an Unreal Engine game in one folder and its copy on a newer engine version in another): Project settings, General, Linked folders, empty by default, so a project without linked folders behaves exactly as before. Agents still start in the project's main folder; at launch each linked folder is granted to the session through the CLI's own flag (Claude Code, Codex, GitHub Copilot CLI, Antigravity CLI, Kimi Code, Mistral Vibe), and the other CLIs see the folders listed in their startup brief and open them by full path. Each folder keeps its own repository and version control: the Changes tab has a repository picker listing the project folder plus every linked folder that is a git repository, to diff, stage and commit by hand per repository, while auto-commit and the worktree per ticket stay on the main folder. Linked folder paths are specific to each computer and not synced, agents launched on a remote SSH host do not receive them, and the mobile app shows the list read-only and offers the linked repositories in its Changes picker. How much of that cockpit is on screen is a choice: three interface modes, Simple (a project, its agents, one prompt: no Files and Changes panel, no dock, no dev command bar, a composer reduced to screenshot, dictation and send, 8 settings tabs instead of 22), Balanced (adds Files and Changes, the dock with Backlog, Preview, Prompts and Triggers, the terminals and the teams) and Full (everything). A mode only folds, it never switches a feature off: everything hidden stays reachable from the Cmd K search, the panel menus and Settings, the guided tour proposes a mode from the level the person declares, a footer chip next to the theme changes it in one click, and Settings, Interface elements, still hides elements one by one. Inside a room, the agent list separates seen from unseen and draws an explicit inactive boundary, each agent card shows which CLI account it runs on when several are reachable, agents can be closed in bulk, and a navigation button takes you back to the projects home without closing anything. The preview searches inside the file (Cmd/Ctrl+F, with a 3 of 12 counter, case, regex and whole-word switches) and replaces in an editable file (Ctrl+H on Windows and Linux, Cmd+Alt+F on macOS). File > Open File (Cmd+O on macOS, Ctrl+O on Windows and Linux) opens any file of the disk in the same preview and editor, a log under /var/log, a dotfile, a file of another folder, marked "Outside project" in its header; the project itself does not change, nothing is indexed or watched. ### Cloud Agents (a task runs while every computer you own is off) https://agentsroom.dev/features/cloud-agents Trigger a coding task from the desktop app or from the phone, and an AI agent runs it on a disposable virtual machine instead of your laptop. A cloud agent is a JOB, not a remote session: the machine clones the repository, runs Claude Code or Codex headless, commits, pushes a dedicated branch and writes a report, then destroys itself. The two machines never talk to each other and the meeting point is git, which is precisely why your own computer can be shut down, out of battery, in a bag at the airport or three thousand kilometres away. What comes back is code and a written account of what was done, never the agent's memory. While the machine is up you can reply to the agent between two of its steps, from the desktop or the phone, in the same conversation view as a local agent, with every command it ran shown; without a reply within a few minutes it pushes its work and the machine shuts down, and waiting for you is not billed. Once it stops you do not resume a cloud agent, you review its work and choose between three actions the interface presents as equals: validate the branch, relaunch in the cloud with an extra instruction, or continue locally in a normal AgentsRoom session with the context pre-filled. That third path is the bridge a pure-cloud product does not have. The workflow this unlocks end to end, with no computer switched on: a user files a report on your public backlog, the ticket lands in your project backlog, you see it in the mobile app, you send that ticket to a cloud run from the backlog tab of your phone, minutes later a branch is pushed with the fix committed, and your own CI/CD takes it from there so continuous delivery builds the mobile app or deploys the site. AgentsRoom supplies the trigger and the scoping, your pipeline supplies the delivery: the phone is not an emergency IDE, it is the remote control of a chain that already runs without you. Same shape for an on-call weekend, a stolen or dead laptop, a long flight, a commute, a machine too weak for a heavy build, or a queue of four independent tickets started in parallel before going to sleep. No forge is assumed for the repository itself: git credentials are registered per host, so GitHub, GitLab, Bitbucket, Gitea, OneDev and any git server you host yourself on your own https domain are all served the same way, with the app naming the token page of that very host instead of a domain it knows. Setting up a run takes a prompt, a provider (Claude or Codex on a cloud machine for now), the agent account it spends (several agent tokens can be registered per provider, each with a label such as Work or Personal, and a run picks one; a cloud account is a token minted by signing in with that account, independent of the desktop's multi-account profiles), a model, a branch mode (a dedicated branch by default, or the current one) and up to four attached files such as screenshots, sketches or logs, copied onto the machine and destroyed with it. A cloud agent works on a clean clone and is meant to finish without you, which is why a scoped backlog ticket makes a far better brief than a line written in a hurry, and why the public backlog, which keeps collecting user reports while nobody is at the machine, is the natural source of cloud runs. Runs are metered in minutes of machine time rather than in tokens, because a run rents a real machine billed by the second: included minutes come with the Plus and Pro plans, purchased minutes never expire, and every run is bounded by a maximum duration and a concurrency cap so a runaway task cannot spend an unbounded amount. The free tier includes zero cloud minutes, and that zero is a rule rather than a ceiling: every other metered feature spends tokens that can be absorbed, a cloud run does not. Currently in beta through the self-serve beta programme. Keywords: cloud coding agents, run Claude Code in the cloud, run Codex in the cloud, background coding agents, agents that run while your computer is off, trigger a coding agent from your phone, remote AI coding agent, headless coding agent, disposable VM coding agent, agent pushes a git branch, self hosted git cloud agent, Gitea cloud agent, OneDev cloud agent, self hosted GitLab cloud agent, backlog to cloud run, AI agent CI CD pipeline, ship a fix from vacation, on-call fix without a laptop, async coding agents, Warp Oz alternative, Devin alternative, autonomous background agents. ### Split View (multi-pane agents, side by side) https://agentsroom.dev/features/split-view A multi-pane split view that tiles the workspace so you can watch several AI coding agents at the same time, side by side, in one window. Drag an agent from the agent list onto an edge of the terminal on screen (a pane that is already shown moves by the badge in its header), iTerm2 style: left or right splits into side-by-side columns (horizontal split), top or bottom stacks into rows (vertical split). The targeted half highlights during the drag to show where the pane will land. The split is N-way with no hard-coded maximum, so two, three, four panes and beyond fit as your screen and agent count allow. The whole layout shares one orientation that you flip between horizontal columns and vertical stacked rows with a single click in the toolbar. Each pane keeps its agent's role color, avatar and animated live status (idle, working, done, needs input), and the focused pane gets a focus ring in its role color while inactive panes dim slightly. Any pane can be pinned: a pinned pane keeps its slot, so opening another agent shows it in the pane beside it instead of replacing the whole layout, and the reference session you pinned stays on screen while you browse the rest of your fleet. Pin as many panes as you want, from the pane header or by right-clicking an agent in the sidebar. Pane groups, their orientation and their pins are saved per project and restored on relaunch, with stale agents filtered out cleanly; clicking a different agent keeps your previous split alive in the background. The same split system applies to dev command terminals (dev server, build, tests) with a right-click Split Horizontal / Split Vertical. Provider-agnostic across Claude, Codex, GitHub Copilot CLI, Cursor and 12 other agent CLIs, so you can mix providers side by side in the same split. Boundary with Claude Code's own layout (checked on code.claude.com on 11 October 2026): in a terminal, Claude Code is a single session and the CLI never splits the screen; the Code tab of the Claude desktop app shows two Claude Code sessions side by side (Cmd+click, or Ctrl+click on Windows, on a session in its sidebar) with draggable chat, diff, terminal, browser and file panes, for Claude Code only. The visibility layer for parallel multi-agent work: a tiling window manager for AI agents and a split-screen alternative to iTerm2, tmux, Zellij, Warp, WezTerm, Kitty and Ghostty split panes, built so every pane is an identifiable agent instead of an anonymous shell. Keywords: split view, split screen, multi-pane, split panes, side by side agents, watch multiple AI agents at once, drag and drop split, horizontal split, vertical split, tiling terminal for AI agents, run multiple Claude Code sessions side by side, agent visibility dashboard, persistent split layout, pin an agent pane, pinned agent panes. **Video (1 min 13 s):** [Split View, shown in the real app](https://youtu.be/-WlvSnCSB8o). Three AI coding agents share one small shop project but the screen shows one terminal at a time; the second agent is dragged from the agent list to the right edge, the right half lights up and the screen splits into two columns, then the third makes three. Each pane gets its own task (a bug fix, a shipping fee, tests for the cart), all three work at once, and their status dots turn from orange (working) to green (done). ### Commit Context (agent conversation gist per commit) https://agentsroom.dev/features/commit-context Commit Context attaches the full AI agent conversation behind each commit as an unlisted gist and links it from the commit message with an Agent-Conversation trailer, so the reasoning behind every change is never lost. AI agents have no memory between sessions, which makes context the scarce resource, not code: the why behind a change, the constraints, the dead ends and the decisions usually die when the terminal closes. With a checkbox under the commit panel (on by default), AgentsRoom captures the conversation of the agent or agents behind the commit (including sub-agent threads), redacts common secrets like API keys, tokens and .env values on a best-effort basis, uploads it as a readable Markdown conversation with a downloadable raw transcript behind an unlisted link, and appends the gist URL to the commit message. The next AI agent or teammate opens that link from git history and recovers the full context: prompts, reasoning, tools run, files edited. The upload never blocks the commit, the link travels with the repo through clone, push and fetch, and you can also create gists by hand on gist.agentsroom.dev the way you would on a public code gist host. This is context engineering applied to git: keep the conversation, attach it to the commit, hand it to the next agent for smooth context handoff, clearer multi-agent collaboration and a project that stays coherent. Provider-agnostic: works with Claude Code, Codex, GitHub Copilot CLI, Antigravity CLI, OpenCode, Aider, Grok Build, Mistral Vibe, Kimi Code, Amp, oh-my-pi, Freebuff, Devin, Cursor, Command Code and Muse Code. Keywords: commit context, agent conversation per commit, share agent conversation, agent context handoff, AI agent memory, context for AI agents, commit conversation, attach conversation to commit, AI agent gist, create a gist, unlisted gist, code provenance, decision log for code, context is the new code. ### Agent Notifications https://agentsroom.dev/features/agent-notifications Unread notifications and status alerts for AI agents. Includes unread badges per session, WhatsApp-style message previews, native desktop notifications on macOS, Windows and Linux, a dock or taskbar badge, and mobile push notifications. Know when an agent finishes a task or needs your input without watching the terminal. A push is only sent when you are not really at the desktop (window in front plus recent keyboard or mouse activity), and the phone can override that to always or never. Mobile push notifications carry the identity of the agent that spoke: its avatar as the sender photo, its name as the title and the project underneath, so you can tell two agents apart from the lock screen. On iOS the notification is rendered as a message from a contact and repeated pushes from the same agent stack into one thread; on Android the avatar becomes the notification icon. Notifications tied to a project or an account rather than an agent keep the app icon. The mobile build carrying the avatars is in App Store and Google Play review. You choose how much of each agent reaches the phone: All, Only when it needs you (its questions and the messages it sends you), or Off, per agent (right-click menu on the desktop, long press on the phone), per project or for the whole account, so a busy pipeline can stay silent while the one agent that coordinates it still reaches you. An agent can also message your phone on purpose with the notify_user MCP tool, for example a scheduled run that needs a decision while you are away; the push is titled with the agent and the project and is limited to one per agent per minute. Keywords: agent avatar push notification, know which AI agent finished, mobile notifications for coding agents, push notification for Claude Code, agent completion alert on phone, mute one AI agent on the phone, only get notified by one agent, agent sends push notification, cron job phone notification. ### Prompt Library https://agentsroom.dev/features/prompt-library Built-in prompt manager for saving, organizing, and reusing prompts per project. Prompts live in folders, at project scope or at account scope (the Global library, available in every project), and a prompt can be marked personal (visible to its author only). The library is stored on the AgentsRoom account and cached locally in `.agentsroom/prompts-cache.json` (gitignored, never committed): the same prompts come back on every machine and in the mobile app, edits made offline or without an account are kept in the cache and sent at the next sync, concurrent edits from two windows, two machines or an agent are merged instead of overwriting each other, and the last 50 versions of each prompt are kept. Nothing is written into the repository; sharing with teammates goes through the Team shared library (publish once, every member imports a self-contained copy) or the public catalog. A prompt can be sent to a terminal, dropped into a backlog ticket, a scheduled agent, a trigger, a team step or a cloud run, in one of two ways: as a copy, or as a REFERENCE. A reference is the prompt handle written between double curly braces; AgentsRoom replaces it with the current text of the prompt when the run starts, so editing the prompt in one place updates every caller instead of leaving copies to drift. A dead reference fails the run and names the missing handle rather than starting an agent with a hole in its brief. A prompt can also be published to the public catalog: a checkbox in the editor, unticked by default, moderated, then translated into 20 languages and served at https://agentsroom.dev/prompts/. **Video (1 min):** [Prompt Library, shown in the real app](https://youtu.be/OFO7CLXtECk). A prompt that runs the tests and explains each failure is saved once in a folder of the project's library, then brought back by typing a slash in the message box, inserted with Enter and sent to the agent with Enter again; the agent runs the tests and explains the two failures without changing any code. ### Linked Prompts (Prompt Chaining) https://agentsroom.dev/features/linked-prompts Link any prompt to one or more other prompts in the library. When you copy or send a linked prompt, AgentsRoom appends all attached prompts automatically, each titled with a markdown H1. Transitive chains, cycle detection, order control. The first prompt library with native prompt inheritance. Prompts are stored on the AgentsRoom account with a local gitignored cache, so a link holds on every machine and in the mobile app. Supports drag-and-drop organization and one-click sending to agents. Every save that changes a prompt keeps the previous version: a History button in the editor lists the earlier versions with their author, shows what restoring one would change, and restores it in one click, from the desktop or the mobile app (the last 50 versions of each prompt are kept). ### Skills Library https://agentsroom.dev/features/skills-library Trigger-based modular procedures (skills) for AI coding agents. Save the procedures your agents repeat (code review checklists, migration patterns, accessibility audits, framework conventions) and attach them to backlog tasks or specific agents. The right skill loads exactly when relevant, no manual context juggling. Claude SKILL.md format natively, with universal export to Cursor, Codex, Windsurf and Aider on demand. Stored per-project in `.claude/skills/` (git-committed when shared with the team) or globally in the AgentsRoom skills library. Synced across desktop and mobile through the end-to-end encrypted relay. Folder organization, drag-and-drop, attach UI on every backlog ticket, optional inclusion toggle per agent run. The first cross-runtime skills library for AI coding workflows. Skills also exist at project level, as a project baseline every agent of that project inherits, on top of the per-agent defaults and the per-ticket selection, and the whole library is reachable from the mobile companion. The public skills catalog is browsable INSIDE the app: a Community tab in the Skills Library searches what other developers published, filters by category, and either uses a skill as it is or copies it into the library of your choice (this project, your personal project scope, or your account). Publishing your own is a checkbox in the skill editor, unticked by default; every submission is scanned for secrets, checked against near-duplicates, moderated by a human, then translated into 20 languages, body included, and gets its own indexable page at https://agentsroom.dev/skills/. A skill can also be marked "attached agents only": it leaves the library agents browse over MCP and is served exclusively to the agents, project baseline or tickets it is attached to, so a large library of specialised procedures never gets picked up by the wrong agent. A skill that fires on a ticket key (fetch the Linear or Jira issue, then start on it) can be fed by the agent's own name: with the project setting "Start on the ticket in the agent's name" turned on, an agent called ARD-221 receives that key as its first message at its first launch, so the intake skill triggers without anyone typing the key the agent is named after. Skills are versioned too: every save that changes a skill (its body, description or bundled files) keeps the previous version, with the same History view and one-click restore on desktop and mobile. A skill can also be linked to a git repository (URL, optional branch or tag, and a subfolder when one repository holds several skills): Fetch or Update clones it shallowly into a machine-local cache with the computer's own git access (SSH key or credential helper, never a password stored by AgentsRoom), reads SKILL.md and its sibling files, and the previous version stays in the history so an update can always be undone. Updating is an explicit click, never a background sync. ### Project Memory (persistent shared memory for AI agents) https://agentsroom.dev/features/project-memory A persistent, shared knowledge base scoped to a project, written by the AI coding agents themselves while they work. Agents save distilled knowledge through the `memory_save` MCP tool (no confirmation needed, upsert by name so notes deepen instead of duplicating, plus an append mode that adds a section to an existing note without the agent having to read and rewrite the whole thing, and an edit mode that replaces one passage in place, accepted only when the quoted passage occurs exactly once, so a correction sits next to the claim it fixes instead of at the end of the note) and read it back with `memory_list` and `memory_get`, which they are instructed to call before exploring a codebase. A fourth tool, `memory_delete`, lets an agent undo a note it created by mistake instead of asking the user to remove it by hand. Notes live in two canonical roots created on first use: features, one note per feature or area of the app, with its architecture, decisions, pitfalls and current state as sections inside it, and global for the knowledge that belongs to no single feature (system-wide architecture, repo-wide conventions, traps in tooling, infra and build). Notes link to each other with [[wiki-links]], which become the edges of a knowledge graph view where node size and brightness track how recently a note was updated, so stale knowledge visibly fades on a 60-day horizon. Unlike per-user note tools, the memory is keyed to the project id committed in the repository rather than to a user account: everyone who opens the project in AgentsRoom reads and writes the same memory, so a teammate who clones the repo inherits everything the other agents have learned, with no invite, export or import. Knowledge is captured at three moments: opportunistically after any significant outcome, at the end of every turn for agents with the "Always memorize" toggle on, and through a memorize-on-close prompt when an agent session is about to end (short sessions are skipped, and the prompt can be opted out per agent, per project or globally). A per-project master switch disables memory entirely. The project is the default scope, and three more sit around it, all four visible and editable in the same Memory library: a folder scope for the zone a project is filed under, typically a client or an employer, whose knowledge is mirrored into every project of that folder so agents read it as files; an account scope for what is true of the user everywhere, whichever client is involved; and one notebook per saved agent, for how that specialist works, which travels with the agent to the next project. Agents pick the scope with a single argument on memory_list, memory_get and memory_save, and are told to choose it by asking who would want to read the note, so knowledge about the code itself stays in the project memory. Provider-agnostic: the tools are served by the AgentsRoom MCP server, so Claude Code, Codex CLI and the other supported agent CLIs share one project memory. Free, with no note limit and no separate sync subscription. Desktop app. Every note is versioned: each save that changes a note (by you or by an agent through memory_save) keeps the previous version, shared with every member of the project, and the History button of the note editor shows what restoring one would change and restores it in one click (the last 50 versions of each note are kept). A project can explicitly link one Obsidian vault folder for ongoing sync while the desktop is running and online: both ways, or vault to memory only. Agent-written notes return as Markdown with frontmatter and preserved [[links]]. Concurrent edits and deletions show both versions for an explicit choice instead of using last-write-wins. The link and conflicts follow the account; each computer locates its local folder. All Markdown notes in the selected folder join the shared project memory; attachments are excluded. Detail: https://agentsroom.dev/features/obsidian-vault-sync ### Obsidian Vault Sync (an Obsidian vault folder kept in step with the project memory, for every agent CLI) https://agentsroom.dev/features/obsidian-vault-sync AgentsRoom links one folder of an Obsidian vault to a project's memory (Project memory in the dock, then Obsidian sync in its toolbar: Choose a vault folder, Sync direction, Link this folder). Both ways: notes edited in Obsidian update the project memory, and the notes agents create or change, plus the notes already in the memory, are written into the folder as Markdown with frontmatter (agentsroom_id, description, tags) and preserved [[note#heading|alias]] links and YAML properties. Vault to memory only: the folder is only read, nothing is written into the vault. The notes become ordinary memory notes, read through the same memory tools by all 16 agent CLIs AgentsRoom supports (Claude, Codex, GitHub Copilot CLI, Cursor and 12 more), so the agent does not have to run inside the vault. No last-write-wins: two edits of one note between passes, or an edit against a deletion, stop that note and show the Obsidian version and the Project Memory version until the user chooses; other notes keep syncing. The engine reads and writes the files on disk (no Obsidian plugin, no Local REST API, no Obsidian Sync, Obsidian does not need to be open), picks up saved files after about a second and checks the memory every 30 seconds while the desktop app is running and online, without the panel open; Sync now forces a pass. Limits: up to 2,000 notes, 1 MB per note, 16 MB in total, eight levels of subfolders; attachments, hidden folders and symbolic links are excluded; one folder per project, folders of two projects cannot overlap. The link is saved on the account: another computer shows it and asks the user to locate the matching folder there, and Unlink stops the sync on every computer and keeps notes and files. Every Markdown note of the linked folder is shared with everyone who has access to the project memory, which is stored on AgentsRoom servers. Linking a folder and resolving conflicts happen on the desktop (macOS, Windows, Linux); agents driven from the mobile app read the same notes. Different from Import from Obsidian (a one-time copy of chosen notes). Boundary with what exists without AgentsRoom: starting Claude Code or Codex inside the vault folder (the notes are plain Markdown files), community plugins such as Claudian that open agents in an Obsidian sidebar with the vault as working directory, MCP servers such as mcp-obsidian that go through the Local REST API community plugin (Obsidian open), and the official Obsidian CLI shipped with Obsidian 1.12 (Settings > General > Command line interface; read, search, create, append; talks to the running app). The comparison page https://agentsroom.dev/alternatives/obsidian covers AgentsRoom Project Memory versus Obsidian as a note-taking app. **Video (1 min 19 s):** [Obsidian Vault Sync, shown in the real app](https://youtu.be/q-cQzPxDLYM). In the project memory, Obsidian sync links one folder of an Obsidian vault both ways, and its two notes arrive in the memory with their descriptions and tags. An AI coding agent asked for a price helper checks the memory first and follows the pricing rule written in Obsidian (euros, two decimals, the sign after the amount). Asked to save what it learned, it adds a section to that same note, which comes back to the vault folder as Markdown, links intact. Subtitled in every site language. ### Structured Notes (plans and reports for the user) https://agentsroom.dev/features/project-memory#notes Account-owned notebooks for personal notes, project folders, projects, saved agents, the main assistant and specialists. Each notebook has a permanent table of contents, nested chapters, tags and free-text instructions for its agents. Its home can show the contents, a pinned page or the latest-created report in a chosen chapter. Parent notebooks never merge child notebooks. Notes are user-facing documents; agent memory remains the knowledge base used while working. The notes_list, notes_get, notes_save, notes_configure, notes_history and notes_archive MCP tools work across providers. Pages keep their previous 20 versions and can be archived, restored, imported from Markdown or exported with an index. Concurrent replacements require the version read, and append/edit operations merge on the server. Contents and history are encrypted at rest and private to the account, including notes attached to shared projects. Desktop and mobile read and edit the same server-backed notebooks; mobile access does not require a running desktop. ### Agent Status Tracking https://agentsroom.dev/features/agent-status-tracking Real-time monitoring dashboard showing individual agent statuses: Working, Done, Needs input, Idle. Includes project-level indicators with counts of working and completed agents, hover previews, and sidebar badges to track multiple agents across all your projects. **Video (1 min 11 s):** [Agent Status Tracking, shown in the real app](https://youtu.be/ucfUVsuAac0). Three AI coding agents work on one project; the agent list sorts them by state (working with a timer, done and waiting for review, blocked on a question), the counters at the top add it up, and the blocked agent is answered from the message box and gets back to work while the bug fix finishes on its own and moves up to review. ### Local status API (read agent status and the backlog from your own dashboard) https://agentsroom.dev/multi-agent-dashboard Since 1.203.0, a read-only HTTP API on 127.0.0.1 for the programs that run next to AgentsRoom on the same machine (a terminal status bar, a tmux line, a personal TUI dashboard, a script). Opt-in: Settings > Dev tools > Local status API, off by default. When on, the desktop listens on a port chosen by the operating system and publishes a discovery file at a stable path, ~/.agentsroom/local-api.json ({ apiVersion, url, port, token, pid, updatedAt }, mode 0600; %USERPROFILE%\.agentsroom\local-api.json on Windows), with a random bearer token regenerated at every launch. Endpoints, all GET with Authorization: Bearer : /v1 (health), /v1/projects (the open projects with their agent status counts), /v1/agents?project=, /v1/backlog?project=…&status=a,b&limit=n. Agent statuses are the ones of the sidebar and of agents_list_live (offline, starting, idle, busy, waiting_input, blocked, rate_limited, degraded, failed), for every CLI. Agents are cached one second per project, the backlog 15 seconds with a stale copy when the server does not answer. Requests with a browser Origin or a foreign Host are refused, so a web page cannot read it; ticket rows carry no description and no reporter data. Versioning rule: v1 only ever adds fields, endpoints and vocabulary values; a breaking change is served as /v2 next to /v1, and clients treat an unknown value as unknown. Desktop only (the phone already shows the same statuses and backlog natively). Keywords: agentsroom api, read agent status from a script, tmux status line claude code agents, external dashboard for coding agents, local http api coding agents, agent status json. ### Conversation view (read an agent as a chat, answer Claude's questions with a click) https://agentsroom.dev/claude-code-gui Every agent pane can show its session as a readable thread instead of the raw terminal: your messages as bubbles on the right, the agent's answers signed with its avatar and name, each burst of tool calls grouped into one collapsible block (Read x3, Bash x2...) whose detail unfolds on click (since 1.214.0 tool calls are hidden by default; an eye button next to a block shows or hides them for that agent, that project or everywhere, and Settings > Terminal, the project settings and the agent's settings carry the same switch), a full-width thread, and the same selection toolbar as the terminal (Summarize, Explain, Copy, Listen, Send to an agent, Quote, Backlog). The default is set per agent, per project or globally (auto, on, off; auto turns it on for right-to-left languages, which a terminal grid cannot lay out), and the view exists for the providers whose transcript AgentsRoom can read: Claude Code, Codex, Grok Build, Mistral Vibe, oh-my-pi and Antigravity CLI. When Claude Code asks a question with options (its AskUserQuestion tool), the view shows a card with the numbered options and their descriptions, an Other field for a free-text answer and a Submit button when there are several questions or a multiple choice; clicking an option answers inside the CLI's own dialog, so the terminal never has to be opened for it. A permission prompt, /model or a plan dialog exist only in the terminal, so the pane lends itself to the terminal for those and comes back to the conversation afterwards. The phone shows the same thread in read mode and follows the same tool calls setting (agent, project or global): a filter button next to the thread shows or hides the tool calls for the moment, and the eye button of a block saves the choice for that agent, that project or everywhere, exactly as on the desktop. While the agent writes, its answer types out in the thread as it arrives in the terminal (Claude Code, Codex and Antigravity CLI), smoothly even when the CLI prints a long part at once, as plain text, then is replaced by the saved, formatted version as soon as the CLI writes it to its transcript; the phone receives it too, every few seconds, and types it out the same way. ### Dynamic Island (floating always-on-top agent status) https://agentsroom.dev/features/dynamic-island A floating, always-on-top status indicator for your AI coding agents that stays visible above every other app. The Dynamic Island plays a different animation depending on the global agent state (idle, active, needs input), so you know what your Claude Code, Codex and Antigravity agents are doing without bringing AgentsRoom to the front. When an agent finishes its turn, a notification surges next to the island for a few seconds with the agent name and project; one click brings AgentsRoom forward and opens that exact agent's terminal in that exact project, the same one-click routing shared with the native desktop notification. A clickable history list catches the finishes you missed and resets when AgentsRoom regains focus. The island can be dragged anywhere on screen including a second monitor, anchored to six edge positions, hidden or configured from a right-click menu, and hides itself automatically when every agent is idle. A team run can take a single place in it: an option shows each team run as one team icon (the team's crest, the state of the whole run, a click opens the console that needs you) instead of one avatar per console. Ambient agent monitoring for multi-agent and parallel AI development. ### Live Agents (one Live Activity for every coding agent: iPhone lock screen, Dynamic Island, Apple Watch, widgets, Android Live Update) https://agentsroom.dev/features/live-activities Live agents puts every AI coding agent of an AgentsRoom account into one Live Activity on the iPhone: the lock screen, the Dynamic Island, the Smart Stack of a paired Apple Watch and StandBy, plus CarPlay and the Mac menu bar with iOS 26 and macOS 26. One activity for the whole room: every agent CLI AgentsRoom runs (Claude, Codex, GitHub Copilot CLI, Cursor and 12 other agent CLIs), on every computer signed in to the account. Three states, the most urgent first: working (a status ring with one segment per agent, each agent with its task and a live timer, silent updates), waiting for you (the agent that waited the longest first, with its question, the Dynamic Island in red, the only update that plays a sound on iPhone), and session complete (duration, agents, files and lines changed, kept 20 minutes, tap to review). Answering from the lock screen works with Claude Code (its single-choice questions, the first two options becoming buttons, and its permission requests, Allow / Deny) and with the Structured Questions any agent CLI with MCP asks through AgentsRoom when the card holds one question with two short options (https://agentsroom.dev/features/clarifying-questions), always behind Face ID or the passcode; any other question shows the agent's message and an Open button. It starts on its own when an agent starts working (Automatic, Manual or Off in Settings > Notifications > Live agents on the phone; "Follow on the lock screen" in the Activity tab) and ends once the room is quiet; a computer that stops reporting shows as offline 10 minutes after its last update. Agent names, tasks and questions are end-to-end encrypted with a key only the phone holds; the AgentsRoom server relays counts and generic alerts; discreet mode hides project names and questions and removes the answer buttons. Widgets: home screen (small, medium, large), lock screen (circular, rectangular, inline), a quota widget with the most used quota bar and its reset time, the tinted and clear looks of iOS 26 with refresh by push, and an iOS 18 Talk to Bot control for Control Center, the lock screen and the Action button. Android: an ongoing Live agents notification with the same answer buttons (unlocked phone required), promoted to a Live Update with a status bar chip from Android 16 QPR2, and a home screen widget. While the live view runs on a phone, it replaces the per-agent push notifications for a finished turn or a waiting question. Requires the AgentsRoom desktop app running and signed in, and iOS 17 or later (a start while the app is closed needs iOS 17.2). Free for every account. Keywords: claude code live activity, codex live activity, coding agent lock screen, ai agent iphone widget, dynamic island ai agents, answer claude code from lock screen, android live update ai agent. ### Process Guard (find and end the runaway processes AI agents leave behind) https://agentsroom.dev/features/process-guard An AI coding agent does not work alone: every tool call it makes spawns a real system process, a search, a build, a script, a test. Most finish in seconds. Some never do. They keep holding gigabytes of RAM, sometimes outlive the agent that started them, and pile up over a work day until the whole machine crawls. Two measured incidents shaped the detection, and both broke an assumption. First, on a 16 GB laptop running eight agents: seven stuck search processes claimed 41.8 GB between them, swap sat at 95%, load average hit 21 on 8 cores, the CPU spent 56% of its time in the kernel just moving memory around, and roughly 993 GB had been written to swap in five and a half hours. Ending those seven returned 15.5 GB instantly, without restarting a single agent or the app. Those processes were NOT idle: they were each burning 10 to 19% of a core while the kernel swapped for them, which is why requiring a process to be idle before flagging it was wrong. Second, on the same class of machine: twelve tsc --noEmit type checks started by six agents, 0.84 to 1.72 GB each, every single one under a 2 GB threshold, 15.4 GB between them, swap full and the machine unusable, with two agents running three checks at once because each one slowed down and got read as hung. Judged one at a time, all twelve were fine. So Process Guard applies two rules. Every child process of an agent older than your lifetime threshold gets its real memory measured, and it is reported above your memory threshold, doubled for a process still using the processor so a legitimate long build stays out of the way. And when everything the agents started adds up to half the machine's physical memory, the whole crowd is reported whatever each piece weighs alone. CPU is measured as a rate between two scans rather than read from the lifetime average, so a process that worked hard and then wedged is still caught; it sets the bar and blocks automatic termination, it is never a free pass. Memory is measured as the REAL footprint, compressed and swapped-out pages included, because on macOS a thrashing process can report 20 MB of resident memory while actually holding 8 GB, and the virtual size is useless there (launchd itself reports 440 GB). A process that lost its parent and became an orphan is reported on its own merits, since nobody else will ever reclaim it, and orphanhood is decided by absence from the live agent tree rather than by a parent id: a Linux desktop reparents to the systemd user manager and Windows reparents nothing at all. What it never touches is as deliberate as what it catches: dev command terminals are excluded by construction, because an idle dev server matches every runaway criterion and is the one process you want running; the agent CLI itself is protected whatever the provider, resolved from the binary the app used to launch it rather than from any hardcoded name; and the kill path refuses any process the guard did not adopt from an agent's own tree. A discreet chip appears in the status bar listing each stuck process with the agent that spawned it, its real memory footprint, its age and its CPU. Two or more flagged commands from the same agent are grouped under that agent, with a button to interrupt it: that sends Ctrl+C to its terminal, ending its current turn so it stops relaunching the command, without closing the agent. One click ends a process along with anything it forked. Nothing is terminated automatically unless you switch that on, and even then never a process still using the processor nor one flagged only for what its neighbours hold. The scan costs about 40 ms per minute on a machine running 824 processes, and no scan runs at all while no agent is active. Designed for macOS, Windows and Linux, with the right memory measurement on each. Keywords: AI agent slows down my computer, Claude Code high memory usage, runaway process, stuck process, orphaned process, too many processes at once, kill process eating RAM, find what is using all my memory, macOS swap usage high, compressed memory, process watchdog, resource guard for AI coding agents, developer machine performance, background process cleanup. ### Keep Awake (keep the computer awake while AI agents work, a Caffeine alternative) https://agentsroom.dev/features/keep-awake Computers sleep when nobody touches them: on a recent Mac with factory settings the system sleeps about a minute after the screen turns off, and locking turns the screen off at once; Windows and Linux have the same idle timer. Every process AgentsRoom runs freezes with it. Measured on a real session: a 13-minute build took 62 minutes of wall-clock time, 45 of them asleep, and a database export over an SSH tunnel lost its connection. AgentsRoom holds system sleep while an AI coding agent is mid-turn, while a dev command's job is still running (an open tab whose build finished holds nothing; a dev server that never returns does), and for the whole duration of a database export, import or copy, then releases it as soon as nothing is running. The screen still turns off: only system sleep is held. A cup icon in the status bar lights up while the machine is held and lists why (which agent, command, transfer or manual hold). One click on it keeps the machine awake on demand, with nothing running and even with the automatic mode off, for 1, 4 or 8 hours or until turned off, optionally with the screen on too; that option is on by default on Windows, where many laptops enter standby as soon as the screen turns off. Agents can read and drive the same hold through the AgentsRoom MCP: keep_awake_status, keep_awake_start (1 to 1440 minutes, or until stopped, optional keepScreenOn) and keep_awake_stop; the cup shows when an agent started it. Native power requests on macOS and Windows; on Linux a desktop session inhibitor plus a systemd-logind sleep lock, so it holds on desktops that ignore the usual request. A closed laptop lid still sleeps on every OS. Nothing can stay stuck on: a crashed window's report expires within minutes, quitting AgentsRoom releases every hold, and a manual hold is not restored at the next launch. Automatic mode on by default (Settings > Terminal > Keep the machine awake), free on every plan. **Video (1 min 11 s):** [Keep Awake, shown in the real app](https://youtu.be/q2k5qOxTl9A). The cup in the status bar is grey while nothing runs and lights up as soon as an AI coding agent starts a long task; one click on it says why (the machine will not go to sleep because an agent is working). A four-hour hold keeps the computer awake on demand once the agent is done and one click turns it off, then an agent asked to keep the computer awake for one hour starts a hold of its own, shown in the cup as started by an agent. Keywords: keep computer awake, keep mac awake, prevent sleep during build, computer sleeps while AI agent runs, Claude Code stops when mac sleeps, Caffeine alternative, Amphetamine alternative, PowerToys Awake alternative, caffeinate, keep screen on, systemd-inhibit. ### Project Pause (pause every AI coding agent of a project and resume it later) https://agentsroom.dev/features/pause-agents A Pause button in a project's agent toolbar, next to the broadcast megaphone, stops every open AI agent of that project cleanly. Each agent is told to stop and its console closes only once its current turn is over, never in the middle of an edit; agents that were already idle close at once. Two modes. Quick pause: resuming reopens the same conversation with its full context. Long pause: each agent first writes a resume summary (what it was doing, what is done, what is left), AgentsRoom keeps it and closes the console, and resuming starts a new conversation from that summary instead of reloading a long context, so restarting a project does not consume a large share of the quota in one go. A follow-up panel counts the agents already paused and shows each agent's state (finishing its turn, writing its resume summary, paused, or not paused with the reason: its turn is not ending, no summary written, could not be reached), with a Close now button that closes a console without waiting and keeps its conversation for the resume and then says that all agents are paused and AgentsRoom can be closed: the signal that it is safe to shut the laptop or install an AgentsRoom update. While a project is paused it is marked as paused and nothing relaunches it on its own: not the session restore at launch, not messages from other agents (they wait in the inbox), not scheduled tasks, not triggers (they are skipped, not replayed at resume). Resume relaunches every paused agent; opening one agent by hand relaunches only that one. Agents that belong to a running team keep going, since the team run manages their consoles, and so does the personal assistant; the pause panel says how many agents are left out before you confirm. An agent whose turn has not ended after 30 minutes is reported as not paused; AgentsRoom never kills it on its own. The pause and the resume are free on every plan. Typical uses: updating AgentsRoom reliably, closing the laptop and coming back later, and near a Claude Code or Codex usage limit, pausing the less urgent projects so the remaining quota goes to the one that matters. The personal assistant can do it on request ("pause every project except AgentsRoom", "resume project X"), and the mobile app offers the same pause, follow-up and resume from the project's menu. Works with Claude Code, Codex, Antigravity and the other agent CLIs AgentsRoom runs, on macOS, Windows and Linux. Keywords: pause AI coding agents, pause Claude Code, resume Claude Code session later, stop all Claude Code agents safely, close laptop while Claude Code is running, resume summary, handoff summary, save Claude quota, pause Codex. ### Context Canary (context drift and degradation early warning) https://agentsroom.dev/features/context-drift-detection An early-warning system that detects when an AI coding agent is losing context, before it starts hallucinating. Long agent sessions degrade through context rot: as the context window fills up, the model quietly drops small instructions a turn or two before it invents files, APIs or decisions that never existed. AgentsRoom turns that into a visible alarm using a built-in canary. Every agent already writes a one-line status at the end of each turn (the summary shown in the sidebar and in mobile push notifications); when an agent stops updating that status for two consecutive turns, AgentsRoom raises a warning banner above the terminal. The banner offers a one-click restart on a fresh, clean context and a tip to type /compact to summarize the conversation, then clears itself automatically when the agent starts reporting again. The canary reuses a signal the agents already produce, so there is nothing to set up and nothing to remember. It is provider-agnostic and works with Claude Code, Codex, Antigravity CLI and other agents, which makes it ideal for monitoring a whole fleet of parallel AI agents where nobody can re-read every reply in real time. Keywords: context rot, context drift detection, lost in the middle, when to restart claude session, compact conversation, AI agent hallucination, AI agent degradation, context window, AI agent monitoring. ### Adaptive Mode (smart model routing for cost-effective AI coding, before the session opens and from the composer) https://agentsroom.dev/features/adaptive-mode Smart model routing that puts the cheapest capable AI model on every task, decided at two moments. Before the session even opens: the suggestion button of an agent card ("Suggest a model from my prompt"), or the one in the room toolbar when no agent is picked yet, opens a short intent screen asking what this agent is about to do, while clicking an agent the usual way still opens it straight away. One sentence, in your own language, and a single call returns the cheapest model in the current provider's catalog that can still do the job, a generated session name and, when no agent has been picked, the agent itself, chosen among the agents already in the room, the fourteen built-in roles and a catalog of more than 260 experts. The session then opens already configured, with the description delivered as its first message through the CLI's own launch argument rather than pasted into the terminal after boot. The visible control is a four-notch complexity rail, Quick, Standard, Complex and Extreme, mapped onto the provider's real models: Quick is text or config edits with no logic behind them, Standard a small change whose solution is already known, Complex a feature, a bug to investigate or a refactor, Extreme architecture, an audit or a problem with no known cause. No model identifier is hard-coded there either: the levels are resolved from the live catalog of whichever CLI the agent runs on, and when a provider offers fewer than four models the table folds upward, so Complex and Extreme both land on the flagship rather than the reverse, because under-sizing wastes a whole run while over-sizing only costs the price difference of one call. Nothing is sent while typing: the call happens only when the button is pressed and only if the level is still on Auto, clicking a level yourself opens the session with zero network calls, an "Open directly" link under the field skips the screen entirely, and the screen can be set to open by itself every time an agent is opened, off by default, for one agent, for one project or everywhere. Failure is never blocking: a dead network, a rate limit or an unusable answer all end with the agent opening exactly as it would have opened without the feature, and when the machine is offline the screen is not shown at all. After the session opens, a thin bar asks once whether the suggested model was the right one, with three answers, it helped, too light, too heavy, and that answer is only sent when usage data sharing is enabled. Then again from the composer, later on: AgentsRoom reads the prompt you are about to send, estimates how demanding the task really is, and recommends the cheapest model in your provider's lineup that can still do it well: a light model like Claude Haiku for a typo fix, a rename, a translation, a short test or a summary; the balanced Claude Sonnet for a pull-request review, a new endpoint, complex debugging or a refactor; the flagship Claude Opus for system architecture, a security audit, a large legacy refactor or deep performance work. It is provider-agnostic and routes within Claude, Codex and Antigravity, validating each suggestion against the models that provider actually offers, and telling you when your current model is already optimal. One click applies the recommendation: it live-switches a running session and saves the choice to the agent for next launch. The composer suggestion runs once per conversation so it never nags you, and it is opt-in: it ships off and you switch it on in the AgentsRoom settings, so nothing reads your draft until you do. The economic point: smaller models cost a fraction of the flagship, so right-sizing the model for each task burns far less of your plan's usage budget per task, which means more tasks per day on the same plan. Keywords: adaptive mode, adaptive model, smart model routing, AI model selection, choose the right model, cost-effective model, cheapest model for the task, AI cost optimization, cut token cost, reduce AI costs, Claude Haiku Sonnet Opus, Codex model routing, Antigravity model routing, more tasks per day, pick the model before launching the agent, choose the AI model before starting a session, task complexity level, right-size the AI model, stop using a flagship model for small tasks, agent intent screen, automatic session naming, pick the right agent for the task, provider-agnostic model routing. ### Scheduled Tasks (cron-style scheduling for AI coding agents) https://agentsroom.dev/features/scheduled-tasks A cron-style scheduler for AI coding agents that runs recurring agent sessions and development workflows without writing a single cron expression. Create a scheduled task on any project with a name, a prompt, what makes it fire and who runs it: one agent, or a whole team, in which case the prompt goes to the team's first step and the run plays the entire pipeline unattended. What makes it fire is picked from five cards rather than typed: Scheduled, a calendar frequency (every N minutes, hourly, daily at one or several times of day, weekly on one or several days of the week, or monthly; since 1.214.0 several tasks can also be selected and edited at once); Quota, the usage window of your own AI subscription; Webhook, an outside event; On ship, a ticket of the project entering Done or In review (see Webhook Triggers below); or On demand, which answers "nothing does": no clock, no endpoint, no quota window, just a saved brief (prompt, agent, machine) that runs when you press its button, which is the shape of the job you repeat but never on a rhythm, such as building the app or cutting a release. The agent to spawn (role, provider, model, plus an Advanced block that carries the rest of the launch per task: permission mode, account, browser access, default skills, CLI options, environment variables and a system prompt); when the time comes, AgentsRoom launches a background agent in that project and feeds it your prompt as its first message. Permission mode being a field of the task rather than a global provider setting is what makes an unattended run actually unattended: a 3 AM task can be allowed to work without stopping at every approval prompt while the agents you drive by hand on the same provider keep asking first, and a task name can carry {{date}}, {{time}} or {{datetime}}, resolved at fire time so a daily task produces a correctly dated agent. Schedule a Claude Code or Codex session to review pull requests every morning at 8, scan crash logs every night, check dependencies every Monday, generate a weekly changelog, analyze production logs daily, summarize git history weekly, or run a QA pass after every deploy. A schedule can also be driven by your SUBSCRIPTION rather than by the clock: the quota frequency fires the task when your AI plan's usage window comes back, or at the tail of that window before it resets and only once the plan is actually consumed past a threshold you pick (any usage, 50%, 80% or 90%), with a lead of 30 minutes, 1, 2 or 4 hours. The reason it exists is that a subscription is not spent evenly: credits you did not use before a window resets are simply gone, and a window you are already at the bottom of blocks the work you wanted to start. The two modes answer those two moments. Waiting for the reset means a run you were blocked on starts by itself instead of you checking the gauge every twenty minutes; firing before the reset means the code review you always launch at the end of your credits runs on the quota that was about to expire, and it repeats on every window instead of depending on you remembering. The window is read on the provider and the account that RUN will actually debit, not on a global gauge, and only the windows your plan publishes with a real reset time are offered (5 hours, daily, weekly, monthly); when the plan publishes none, the editor says so and offers nothing. Precision is the one of AgentsRoom's usage scan, about 10 minutes through the Claude OAuth API and 30 minutes through the ghost /usage terminal, not the minute: a quota run starts shortly after the boundary rather than exactly on it. The one-shot version of the same idea is a scheduled message in the composer, see Message Queue (https://agentsroom.dev/features/message-queue): a message armed on the quota window leaves once and the card is gone, while a quota FREQUENCY is a standing order that fires again on every window. Starting the window itself, with one background message to the cheapest model rather than by running anything, is a different feature again: the quota kick-off, described with the Usage Alerts (https://agentsroom.dev/features/usage-limit-alerts). A daily or weekly task can also carry several times of day (09:00 and 18:00, up to six), two fixed moments an interval in minutes cannot express, since an interval spreads runs evenly while several times of day pin the hours your day is actually shaped around. It uses a simple in-app plus catch-up execution model: tasks fire while AgentsRoom is open, and a run missed because the app was closed or the machine was asleep is caught up automatically as soon as AgentsRoom is back; a task tied to a hard clock time can opt out of catch-up, and its missed slot is then recorded as missed instead of running late. The machine itself can be woken for a run: with Wake the machine turned on (globally, per project or per task), AgentsRoom arms the operating system's own wake timer for the next scheduled run (pmset schedule wake on macOS, a wake-to-run task in the Windows Task Scheduler, the RTC alarm on Linux), so the computer wakes at that time with the screen off or the lid closed on power, runs the agent and is kept awake while it works; macOS and Linux need a one-time administrator grant scoped to that single command, shown before you type the password and revocable from Settings. Missed and failed runs are written into the run history and flagged on the task row, so a task that stopped running never looks healthy. Every automatic start sends a native desktop notification and a mobile push, and each task keeps a run history that outlives its runs: the agent's terminal output is archived per run, for every provider, so a run is readable days later even after its session was closed and from any other machine signed into the same account, while a recent run can still be reopened as a live terminal you take over. A Run now button fires a task on demand and opens that agent's tab straight away, and it can name WHICH machine: right-clicking it lists the other computers of your account that hold this project, so a build fires on the machine that has the toolchain from whichever laptop you are sitting at, and the run is stamped and archived over there in the same history. The mobile app carries the same button and always asks for the machine, since a phone runs nothing itself. Any task can be enabled or disabled in one click, and a task can be pinned to the machines of your choice so two computers with the same project open do not both fire the same nightly run. The agent a task spawns is chosen from the same catalogue as the Add Agent modal: the built-in roles plus the Agency experts and the community agents. Provider-agnostic across Claude Code, Codex, Antigravity CLI and other agents, with the task list synced per project to your account. A cron alternative and task scheduler built for developers and recurring AI development workflows, and a complement to tmux and cmux that automates the launch of commands and agents at predefined times. When the right moment is not an hour but an outside event (a pull request opened, a build broken, an alert fired), the same panel also fires on a webhook: see Webhook Triggers (https://agentsroom.dev/features/webhook-triggers). Keywords: scheduled tasks, scheduled task, scheduled agent, run an agent when my quota resets, run a coding agent when my Claude limit resets, schedule an agent on my quota window, use up remaining Claude credits before they expire, run a code review before the weekly limit resets, start an agent automatically after a usage limit, quota based scheduling, twice a day agent, schedule an agent twice a day, run a task several times a day, agent that runs several times a day, scheduled AI agent, scheduled coding agent, scheduled CLI tasks, scheduled terminal commands, scheduled terminal session, scheduled CLI session, scheduled CLI workflow, recurring agent tasks, recurring development tasks, AI agent scheduling, agent scheduler, cron for AI agents, cron alternative, cron jobs for developers, automated terminal workflow, terminal automation, schedule Claude Code, scheduled Claude Code session, schedule code reviews, schedule dependency updates, nightly AI agent, daily AI agent, unattended AI agent, run an AI agent without approval prompts, autonomous overnight agent, wake mac for scheduled task, wake computer for scheduled agent, launchd alternative for AI agents, run an agent while the mac sleeps, wake from sleep scheduled task, missed scheduled run, tmux alternative, cmux alternative. Yes. Choose Existing project agent, then a saved agent in the project. The trigger sends its prompt to that agent instead of creating a temporary one. You can choose a repeating schedule, for example every 15 minutes to check the backlog. Delivery waits while the agent works or needs your answer, and repeated reminders combine into one pending message. Reopening a closed console is optional and off by default. Its previous conversation is resumed only when the provider and your restore settings allow it. Every scheduled agent is versioned: each save that changes its name, prompt, schedule, agent, model or options keeps the previous configuration (run history excluded), and the History button of the editor, on desktop and in the mobile app, compares it with the current one and restores it as unsaved edits. Since v1.205.0 the Scheduled view opens on a Timeline of the day by default (a Timeline / List switch sits next to the filters, saved on the account so every computer and the phone open on the same view): the week on top with each day's number of runs, the day's tally (done, running, failed or missed, to come) with who runs next, an All day long band for the triggers that fire every few minutes or every hour, then one card per run at its exact time with its state (Ran at 09:02, Running, Failed to start, Missed, Did not run, or a countdown). Drag a card up or down to move its trigger to another time (15-minute steps, Undo in the confirmation bar), or hover an empty half-hour to create a trigger already set to that time, every day or on that weekday only. The phone shows the same timeline: tap an empty slot to create a trigger, long-press a card then drag it to move it. In the List, a team trigger shows one chip per member with its provider and model, on the phone too. ### Webhook Triggers (start an AI agent on a GitHub, GitLab, Slack, Linear, Sentry or CI event) https://agentsroom.dev/features/webhook-triggers Webhook Triggers answer the question "when does this agent start?" with an outside event instead of an hour. They live in the very same panel as Scheduled Tasks (https://agentsroom.dev/features/scheduled-tasks): same list, same enable switch, same per-run history, same picker for who runs it (one agent with its role, provider, model, reasoning effort, skills and system prompt, a whole team, or a built-in board action) and same per-machine scope. The board action Start next Todo ticket spawns no agent and makes no LLM call: on each accepted event (a pull request merged, a green CI run, an issue closed) it does what the backlog board's Start next button does, the top Todo ticket that is not waiting on a prerequisite moves to In progress and runs with its own assigned agent or team, so a ticket-per-agent pipeline advances by itself without paying an agent turn to move the Kanban. A trigger has five modes, presented as five cards under "what fires it": Scheduled, the cron-style calendar frequency (every N minutes, hourly, daily at one or several times of day, weekly on one or several days, or monthly); Quota, the usage window of your AI subscription; Webhook; On ship; and On demand, which fires on nothing at all and waits for you to press its button, for the job you repeat often but never on a rhythm. On ship starts the trigger's agent or team when a backlog ticket of the project enters a column, Done by default or In review for a check before closing: no URL and no signing secret, the AgentsRoom server produces the event itself and nothing outside AgentsRoom can send one; an optional condition on the ticket (ticket.type == "bug", ticket.tags contains "prod", fromStatus == "in_review") narrows it; the prompt receives the ticket as variables ({{event.id}}, {{event.title}}, {{event.body}}, {{event.type}}, {{event.tags}}, {{event.status}}, {{event.from}}, {{event.shipped}}, {{event.branch}}, {{event.version}}, {{event.agent}}, {{event.team}}, {{event.author}}, {{event.url}}); each ticket entering the column starts one run, once (a double move or a retried request never starts a second one, a ticket declined as won't fix never starts it), only your own triggers of that project fire whoever moved the ticket (board drag, MCP, phone), and Run now replays the last shipped ticket. It is the post-release pass: watch logs, errors and user feedback after a change ships, and reopen the ticket if something regressed. In webhook mode AgentsRoom gives the trigger a unique public URL you paste into the service, plus a regenerable signing secret. Every incoming call is verified before anything runs: X-Hub-Signature-256 for GitHub, X-Slack-Signature for Slack, the X-Gitlab-Token shared token for GitLab, an HMAC of the raw body for Linear and Sentry, and for a generic source a signature that also covers a timestamp and a delivery id, and an unsigned call is rejected, so knowing the URL is not enough to start an agent. Replay protection is on by default for every new generic trigger: the sender signs v1::: with HMAC SHA-256 and sends X-AgentsRoom-Signature (v1=), X-AgentsRoom-Timestamp and X-AgentsRoom-Delivery; a call outside the acceptance window (1 to 60 minutes, 5 by default) is refused, a delivery id already received never starts a second run (native dedupe, provider retries included), and Slack's own timestamp is checked the same way, so a request captured in a CI log cannot be sent again. For a payload you do not control (pull request code, a public issue), a trigger can be a Restricted run: the agent CLI itself, not the prompt, then refuses the shell and the web, keeps project files read-only, withholds every AgentsRoom tool and only calls the MCP tools you list from the trigger's own MCP servers, with no approval prompt to stall on. Claude Code (--restricted, strict MCP config, dontAsk) and Codex (OS sandbox without network, per-agent profile) enforce it; any other CLI refuses to start the run rather than run it unprotected. A trigger also carries its own environment variables and MCP servers filled from the local secret vault, so a token meant for one reviewer reaches that trigger's runs only, and in a restricted run it can live in the MCP server where the agent never reads it. An optional filter decides whether an event deserves a run at all (fire only when action equals opened, only on one branch, only for one label), and burst protection caps it at one run per time window with the calls that arrive inside that window grouped together, so a noisy repository cannot spawn twenty agents in a minute. The JSON payload becomes prompt variables resolved at fire time, exactly like the date and time variables of a scheduled task: the event title, the author, the event URL, the pull request or issue number, the branch, and the whole raw payload. The editor shows the last call the trigger actually received, raw JSON included, and replays it in one click, so a webhook is wired by looking at a real payload instead of pushing test commits to find out. Execution follows the same honest in-app plus catch-up model as Scheduled Tasks: an event that arrives while AgentsRoom is closed is queued and replayed on the next launch rather than dropped, and when several machines have the same project open the first one to pick an event locks it and the others skip it, so a single event never produces two runs. This is not cloud execution: the agent always runs on your own machine, in your project, as a real agent with its terminal, its conversation view and an archived transcript you can read back later. Typical wiring: review every pull request the second it opens, investigate a red CI build with the branch and run URL already in the prompt, triage a Sentry exception before anyone opens the dashboard, start an agent from a Slack slash command, scope a new GitHub, GitLab or Linear issue as it is filed, run a QA pass after every deploy, or write release notes on a pushed tag. There is no integration list to wait for: anything that can send a signed POST with a JSON body works, including a CI job, a monitoring tool, your own backend or a curl in a shell script. The economic argument is the reason the feature exists: making an agent watch something by polling burns a full turn of context on every loop and almost every loop answers "nothing new", while a webhook trigger consumes nothing at all until the event happens and then reacts within seconds. Triggers are inbound only, AgentsRoom receives events and does not emit them, and a trigger is not a visual multi-step scenario builder: it decides when a run starts and hands it the event, while the multi-step work belongs to what it points at, a single agent or an Agent Team (https://agentsroom.dev/features/teams) whose pipeline then plays on its own. The same panel has an "On ship" mode: the agent starts when a backlog ticket enters Done (or In review, a QC step), once per ticket, with the ticket as context (title, description, type, tags, branch, fixed-in version, the agent or team that did the work), which closes the loop between delivery and production monitoring. It is fed by AgentsRoom itself, so it has no public URL to protect. Besides an agent or a team, a trigger (webhook, schedule or on demand) can run a board action, "Start next Todo ticket": exactly the board's button (top of To do, tickets blocked by an open prerequisite skipped, started with their own agent or team), with no prompt and no AI call. Keywords: webhook trigger, on ship trigger, post-release monitoring agent, webhook triggers, trigger an AI agent, event driven AI agent, start an agent on a webhook, GitHub webhook AI agent, GitLab webhook automation, Slack webhook agent, Sentry alert automation, Linear webhook automation, run an agent when a pull request opens, CI webhook trigger, build failure automation, deploy hook agent, event driven automation for developers, webhook automation without polling, stop polling the API, incoming webhook URL, webhook signature verification, HMAC webhook security, webhook payload variables, replay webhook payload, webhook queue replay, cron alternative event driven, trigger Claude Code from GitHub, trigger Codex from a webhook, autonomous coding agent trigger. On the desktop, the Triggers window carries a switch next to its title, the project (its logo and name) or Global, to go from the project's triggers to the global triggers of the personal assistant and back without closing the window. ### Vibe Coding Review https://agentsroom.dev/features/vibe-coding-review Side-by-side diff viewer for reviewing AI-generated code changes. Features word-level diffs, syntax highlighting, keyboard navigation, file list with color-coded status (added, deleted, modified), and AI-generated commit messages. ### Per-Agent Review https://agentsroom.dev/features/per-agent-review Filtered code review interface that isolates changes by individual AI agent. Shows per-agent tabs, file tracking to see which agent modified what, scoped commits per agent, filtered keyboard navigation, and attribution to track which agent made which modifications. Since 1.203.0 the Changes tab can also discard a file's changes from its "..." menu, in two clicks (a tracked file returns to its last committed version, index and working tree included; a file that was never committed is deleted from disk), on the desktop and in the mobile app, whatever CLI produced the change. The Pull button follows a Pull method setting (since v1.205.0): Fast-forward only by default, Merge or Rebase, set for every project in Settings > Git, per project in Project settings > Git, or straight from the Remote changes detected window that opens when the branch is behind its remote. A pull that stops on a conflict is offered to a Git expert agent or to a terminal. Since v1.208.0, a repository with linked git worktrees shows a worktree selector at the top of the Changes tab (Main, then each worktree with its branch): pick one to review, commit, pull and push the work it holds even when no agent is pinned to it, and a branch already checked out in another worktree opens that worktree instead of failing to switch. Since v1.213.0 the Changes tab lists the changed files as a tree by folder by default (collapsible folders with a file count, a checkbox per folder), with a View options button to go back to the flat list, on the desktop and in the mobile app, and a Follow the selected agent switch decides whether switching to an agent's terminal also switches the filter and that agent's worktree: turn it off and the list stays on the filter and worktree you picked until you change them (also in Settings > Git). Next to Push, a CI badge shows the GitHub Actions or GitLab CI status of the pushed commit (running, passed, failed) with the account connected for Import repositories; a failed pipeline lists its failed jobs with the end of their log, and Send to agent to fix hands the job name, its link, the commit and those log lines to an agent of that checkout or to a new agent, on the desktop and in the mobile app, with an optional notification (desktop and phone) when the pipeline of a branch you pushed finishes. ### Mobile-Desktop Sync https://agentsroom.dev/features/mobile-desktop-sync Real-time encrypted sync between the desktop app and the mobile companion (iOS and Android). Start AI agents from your phone, type in the terminal remotely, send saved prompts, preview dev servers through the built-in localhost tunnel, and monitor agent status with push notifications. The phone owns its own ringer: a three-way setting in the mobile app (follow desktop, always, never) overrides the desktop's own "send notifications to phone" checkbox, so an agent or a long terminal command you started from the phone still reaches you when you walk away from the computer. All communication uses X25519 key exchange and XSalsa20-Poly1305 encryption. **Video (1 min):** [Mobile-Desktop Sync, shown in the real app](https://youtu.be/twmkOTG3KyY). A task typed on the phone reaches the computer end-to-end encrypted, the agent there fixes the bug and runs the tests while the phone shows it working live, then its answer is read on the phone. ### Scratchpad (Prompt Draft Editor) https://agentsroom.dev/features/scratchpad Built-in prompt draft editor and mini text editor inside the agent composer for composing long, complex prompts for Claude Code and other AI coding agents without typing directly into the terminal. Write, relisten, reread, revise and iterate on your prompt in a dedicated textarea (docked under the terminal, or the near-fullscreen Compose panel opened with the Expand button), then send the whole block to that agent's terminal in a single atomic bracketed paste (`\x1b[200~…\x1b[201~`) so newlines, indentation and special characters are preserved instead of triggering premature execution. Every agent keeps its own draft, persisted to localStorage (`agentsroom-composer-drafts`, keyed by agent id) so it survives app quit, computer reboot, agent switch, project switch and window close. Includes a built-in Dictate button (in-app microphone, server-side transcription, transcript inserted at the caret, nothing sent automatically), a one-click Save that promotes a working draft into the project Prompt Library, a Prompts button that opens the library without losing the current draft, a Sketch and a Screenshot button, and the Cmd/Ctrl+Enter shortcut to fire the prompt at the agent (queued instead of dropped when that agent is mid-turn). An Enhance button (magic wand, Cmd/Ctrl+Shift+E) rewrites a short or dictated request into a clear prompt with a goal, constraints and a definition of done, using the agent's role and the related project memory notes; the result replaces the draft in place with an Undo, and nothing is sent automatically. The same Enhance button exists in the backlog ticket editor, the Prompt Library editor and the mobile app. Local-first, zero cloud sync, and every composer action can be hidden individually in the settings. A prompt composer, AI prompt notepad, scratch buffer, text staging area and prompt draft manager built for developers working with Claude, Codex, GitHub Copilot CLI, OpenCode, Antigravity CLI, Aider, Grok Build, Mistral Vibe, Kimi Code, Amp, oh-my-pi, Freebuff, Devin, Cursor, Command Code and Muse Code. Replaces external editors like Notes, Obsidian, VS Code or TextEdit for writing structured multi-paragraph AI prompts. Not to be confused with the session scratchpad directory of Claude Code: a temporary folder the CLI creates for each session and names in its system prompt (/tmp/claude-///scratchpad on macOS and Linux, %TEMP%\claude\\\scratchpad on Windows), which nothing in the CLI displays and which a temp cleanup or a reboot erases; File > Open File (Cmd/Ctrl+O) in AgentsRoom opens any file from that folder, marked as outside the project. ### Message Queue (stack messages, send them in order) https://agentsroom.dev/features/message-queue A message queue built into the AgentsRoom composer for AI coding agents. Instead of sending every prompt immediately, you stack several messages above the composer and send them to the agent in the order you choose, one at a time, so you stop overloading the agent with one giant mega-prompt and keep a clear view of the tasks still to come. Click Queue instead of Send and the message parks above the input as a compact card; the composer clears for the next idea. Every queued message gets a short title summarized by AI (via the AgentsRoom backend, no model key needed on your side), shown in bold with a one-line preview and a count of attached files. Screenshots and dropped files stay attached to each queued message, so nothing has to be re-attached at send time. Reorder the queue by drag and drop, reopen a card to edit it back in the composer, send any message on demand, or remove it. The queue is per agent, persists across app restarts (localStorage), and stays inert until you send: the mobile app can add a text-only card to the queue, send it now or remove it, while region screenshots and the Chrome extension always target the live composer, so the queue never gets in the way of what you are typing. Scheduled messages (send later): any queued message can also carry a clock and send itself at a time you choose, with no action from you. Pick a relative preset (15 minutes, 30 minutes, 1 hour, 2 hours, 4 hours, tomorrow morning) or type an exact HH:MM (today if that hour is still ahead, tomorrow otherwise), and the card shows a live countdown (in 58 min, at 21:30) that one click reschedules or disarms. A scheduled message is the same queued card, in the same queue, delivered through the same path as a message typed by hand: only the trigger changes, a clock instead of your finger. It can be armed from the AgentsRoom mobile app (a clock button next to send, presets in a bottom sheet, pending messages with countdown and cancel), which is the main use case: you schedule the instruction at the moment you are putting your phone away. The phone arms, the desktop fires. The timer is held desktop side because a message only makes sense inside a live agent CLI, and a message whose time passed while the app was closed goes out on the first check after you reopen AgentsRoom, so nothing is silently lost. If the agent is unreachable when the time comes, the message is never dropped: it stays in the queue marked as waiting for the agent, AgentsRoom starts that agent for you and retries, and a push notification lands on your phone once the message has actually been sent, because nobody is watching the screen at that hour. A message can also be armed on the SUBSCRIPTION clock instead of the wall clock, which is what you want when you work at the end of your credits: send it the moment the quota comes back, or 30 minutes, 1, 2 or 4 hours before a window resets, and in that second case only when the plan is actually consumed past a threshold you pick (any usage, 50%, 80% or 90%), so a code review fires on the credits that were about to expire rather than on a barely touched plan. The window is read on the provider and the account that agent really debits, the same resolution as the usage gauge, and only the windows your plan publishes with a real reset time are offered (5 hours, daily, weekly, monthly). The reset time is re-read on every check rather than frozen when you arm the card, so a window that rolls over or an account switch never fires the message against a boundary that no longer exists. Quota arming works from the phone too, with the same windows, delays and thresholds. Each project tile on the home screen also shows how many prompts are still waiting on its agents, on desktop and on mobile. There is no full date picker, on purpose: a message for next week is a backlog ticket, and recurring work belongs to Scheduled Tasks (https://agentsroom.dev/features/scheduled-tasks). The boundary between the two is the lifetime and not the mechanism: a message armed on the quota window is a ONE-SHOT, it leaves once and the card is gone, whereas the quota FREQUENCY of a scheduled task is a standing order that fires again on every window, with the same modes, the same windows and the same thresholds. A prompt queue, message stacking, staged messages, draft queue, ordered task queue, scheduled prompt, delayed message, send later and timed prompt for developers working with Claude, Codex, GitHub Copilot CLI, OpenCode, Antigravity CLI, Aider, Grok Build, Mistral Vibe, Kimi Code, Amp, oh-my-pi, Freebuff, Devin, Cursor, Command Code and Muse Code. Sending is manual by default so you stay in control of what goes out and when, and the only automatic triggers are the ones you set yourself: a time, or a quota boundary of your own subscription. ### Structured Questions (AI agents ask clarifying questions in a card with clickable options, then wait) https://agentsroom.dev/features/clarifying-questions When an AI coding agent needs a decision, a preference or a missing fact, it no longer writes the question in the middle of its reply and carries on: it calls ask_user, a tool of the AgentsRoom MCP server, and the question appears as a card docked above the agent's input box, with one to four questions shown one at a time, two to eight clickable options each with a one-line description, multiple choice, text, ASCII or HTML mockups to compare, a free-text field that also takes option numbers (2, or 1, 3), a Recommended badge on the option the agent advises, an Annotate button that attaches a note to a question's answer, a Not clear? button that makes the agent explain the question and ask it again in plainer words (other answers kept), the same two actions on any single option (icons on hover, long press on the phone), and, on the last question, Send or Add a note (an Additional notes field sent with the answers). The agent waits 45 seconds by default (10 to 600; Codex and the CLIs whose limit is unknown pause after about 50 seconds because their tool calls are cut at 60), then pauses without losing anything: the card stays open and a later answer is typed to the agent as a message starting with "[AgentsRoom] Answer to your question", and answers can also come from the desktop Waiting for input list, the AgentsRoom mobile app, or two buttons on the iPhone Live Activity and the Android live notification for a single question with two short options. The personal assistant relays them too: ask it "what are my agents asking me?" by voice or from the phone and it reads every open question of every project with its options and the agent's recommendation, then hands over the answer you give it (or a "Not clear?"), never choosing in your place. It works with Claude, Codex, GitHub Copilot CLI, Cursor and 9 other agent CLIs that have an MCP client (Aider has none), is on by default on every plan, and turns off for all projects, one project, one agent or straight from the card's menu. A single card can also be closed without an answer (the cross at the right end of its header, visible even when the card is folded, or Close without answering, last entry of its ⋯ menu; on the phone, the cross in the corner of the card): the agent is told no answer is coming, does not ask that question again, and decides on its own or ends its turn; Answer in the conversation instead makes it ask again in plain text. Keywords: ai agent clarifying questions, codex ask clarifying questions, claude code AskUserQuestion alternative, ask user question MCP tool, human in the loop coding agent, multiple choice question card, answer an AI agent from the phone or the lock screen. **Video (1 min 13 s):** [Structured Questions, shown in the real app](https://youtu.be/UD6U--rX1w8). An AI coding agent gets a task with a real choice in it; instead of burying the question in its reply or picking on its own, it asks in a card right above its input box, each option with one line on what it implies, and waits, marked as needing your input. One click answers, a last step adds a note or skips and sends, and the agent opens its reply by restating the choice before carrying on with it. Left unanswered, the agent pauses and the card stays open. Subtitled in every site language. ### Command Palette (one Cmd K bar that searches everything in the project) https://agentsroom.dev/features/command-palette A universal search bar for AgentsRoom, opened near the top of the screen over the whole desktop app with Cmd K on macOS or Ctrl K on Windows and Linux, from a shortcut you can rebind, or from the Search button in the title bar. One field searches every list AgentsRoom keeps for the project you have open, at the same time: the skills library (project and global), the scheduled agents and the webhook triggers, the prompt library (project and global), the project memory notes, the open backlog tickets, the dev commands and servers, the saved SSH and database connections, the agents of the current project, then the agents of your other projects at the bottom of the list so they never displace what you were looking at, the files of the repository with fuzzy matching over the whole path and .gitignore honoured, and the last 200 commits of the current branch when the project is a git repository. Matching is fuzzy and tolerant: letters can be missing or out of order and accents are optional, which is what makes it work on names you gave yourself months ago. Results come back grouped by category with a cap per group rather than in one flat list, so a repository of a hundred thousand files never buries the one backlog ticket that matched. Prefix characters restrict a search to a single source and lift that cap: the greater-than sign for dev commands, the hash sign for the backlog, the at sign for agents, the slash for files, the colon for commits; the chips under the field do the same with Tab and Shift Tab. Navigation is keyboard only from start to finish: arrow keys move across every group, Enter opens what is selected in the surface that owns it (an agent gets its terminal focused, a ticket opens on the board, a skill or a prompt opens in its editor, a memory note in the memory editor, a dev command its tab, an SSH or database connection its session, a file its preview, a commit its diff), Escape empties the field and closes it on a second press. With an empty field the palette shows your last eight choices instead of a blank rectangle, so most of the time the result is already on screen. Each source can be turned off in the settings, globally, and any project can override that choice for itself. Performance is part of the design: nothing is indexed while the application is launching, the file list comes from git and is scored in a worker thread so typing never blocks the interface, the commit page and the file list are cached and refreshed in the background, and the lists AgentsRoom already holds answer instantly whatever the repository is doing. Everything stays on the machine: the index lives on your disk and nothing typed in the palette is sent to a server. The shortcut is not a system-wide hotkey: it fires while the AgentsRoom window has the focus, so it never takes the key away from the app you are working in. Available on macOS, Windows and Linux, and agnostic of the CLI your sessions run on: Claude, Codex, GitHub Copilot CLI, Cursor and 12 other agent CLIs. Two always-on keyboard shortcuts jump between projects: "Next project waiting for you" (Cmd+Shift+J on macOS, Ctrl+Shift+J on Windows and Linux) opens the next project in sidebar order where an agent needs your answer, on the agent that has waited longest; and each project can get its own shortcut (Settings > Keyboard shortcuts). Since 1.214.0, holding Cmd (Ctrl on Windows and Linux) for a moment shows the shortcut of every control that has one: the project numbers 1 to 9, the search, the screenshot button, New project and the next project waiting for you. Keywords: command palette, universal search, global search, spotlight for AI agents, Cmd K, Ctrl K, quick open, quick switcher, fuzzy file search, search git commits, jump to file, keyboard driven interface, search agents, search backlog tickets, local search with no server. ### Dev Terminals https://agentsroom.dev/features/dev-terminals Per-project terminal manager and process launcher built into AgentsRoom, a modern alternative to iTerm2, Terminal.app, Warp, Ghostty, Kitty, Alacritty, WezTerm, Hyper and Tabby for project work. Every command (backend, frontend, mobile bundler, Docker, worker, database, microservices) is saved per project in .agentsroom/commands.json, launched in one click, and runs in a real xterm.js pseudo-TTY with live status tracking (running, starting, stopped, crashed). Detachable terminal window for a second monitor, so your logs stay visible while you code in the main window. AI-powered command generation via Claude scans package.json, Dockerfiles and Makefiles to auto-fill your entire command list with correct paths, framework categories and icons (30+ frameworks supported). Unique feature: launch terminal commands remotely on your computer from the iOS or Android mobile app over 4G/5G through the end-to-end encrypted relay, with live output streamed back to the phone. Works seamlessly with the built-in localhost live preview tunnel so you can start a server from mobile, then open it in your phone's browser from anywhere. Command completion alerts: every terminal tab carries a bell in its floating label, and arming it sends a desktop notification (plus a mobile push when you are away) the moment the command running in that terminal finishes, with its name and duration. Get notified when a build, a test suite, an npm run build, a Docker build or any long running command is done, without watching the terminal. Only commands longer than a minute alert, so cd, ls and git status stay silent, and nothing pops while you are already looking at that terminal. Detection reads the terminal's foreground process group, so nothing is injected into your zsh, bash, fish or PowerShell configuration and it works on macOS, Windows and Linux with hand-typed commands as well as saved ones. **Video (1 min 18 s):** [Dev Terminals, shown in the real app](https://youtu.be/tyc4mV7lsC0). A small shop project with an API and a storefront has no saved command yet; one click on the magic wand and an AI agent reads the repository and writes the two start commands, each with its own folder. Start on each row runs the server in a real terminal tab, the counter shows two running, and nobody typed a single cd. ### CLI Doctor (AI diagnosis of an agent CLI that failed to launch) https://agentsroom.dev/features/cli-doctor An agent CLI that dies at launch is the most opaque failure in AI coding: no output, no stack trace, sometimes just a prompt that comes back. CLI Doctor answers the only question that matters, what broke and what to do now. It works in layers, cheapest and most certain first. AgentsRoom records the exact command it spawned at the single point where any terminal is created, so the record covers desktop launches, agents started from the mobile companion and agents spawned by a backlog ticket. Deterministic verdicts keep absolute priority and cost nothing: a missing binary, a flag the CLI no longer accepts, a session that is not logged in, an outdated version are answered directly with a banner and a fix button, with no model involved. If the failure is not one of those known cases, a broad error-pattern scan runs over the first seconds and is then corroborated against what is actually running in the terminal, so a CLI that is merely slow to boot, or busy installing its MCP servers on first run, is discarded instead of misdiagnosed. Only then does the AI step in, with three inputs: the error excerpt, the sanitized launch command, and a flag provenance map. Flag provenance is the differentiator: every token of the final command is attributed to the layer that injected it (autonomous mode, stored provider options, a per-agent CLI override, the model selection, the reasoning effort, Codex fast mode, the system prompt, the browser MCP denial), so the answer names the setting to change instead of describing a flag in the abstract. The response is a plain-language summary plus ordered steps, each step optionally carrying a whitelisted action (open CLI options, open provider settings, relaunch, run the install command). Nothing is ever executed automatically. System prompts, secret-looking environment values and long quoted arguments are redacted on your machine before anything is sent, and the automatic diagnosis can be switched off entirely in Settings under Privacy and data. Dev command terminals get the same diagnosis on click rather than automatically, because a failing watch loop re-emits its error continuously, and the result can be handed straight to a DevOps agent. Covers Claude Code, Codex CLI, GitHub Copilot CLI, Antigravity CLI, OpenCode, Aider, Grok Build, Mistral Vibe, Kimi Code, Amp, oh-my-pi, Freebuff, Devin, Cursor, Command Code and Muse Code. Keywords: claude code will not start, codex cli error, unknown option cli, unrecognized flag, command not found agent cli, agent launch failure, why is my agent not starting, diagnose cli error, which setting added this flag, build command failed help. In the guided installer's diagnostic screen, a CLI that is already installed can be ticked to reinstall or update it in place (since v1.186.0): the install command of the provider is the update command, a binary owned by Homebrew is upgraded through Homebrew rather than overwritten by npm, and the sign-in step is skipped when every selected CLI is an update. ### Import Repositories (connect GitHub or GitLab, clone in batch) https://agentsroom.dev/features/import-repositories Connect GitHub or GitLab from the project opening screen, browse the repositories you own or are a member of, tick several and clone them in a single pass. Each cloned repository is registered as an AgentsRoom project with its path already set, ready to receive agents, so setting up a new machine no longer means a manual clone-and-add loop per repository. Two ways to authenticate, both local: paste a personal access token (the app links to the creation page with the minimal read scope prefilled), or reuse in one click a gh or glab CLI session already signed in on the machine. Self-hosted GitLab instances are supported end to end: enter your own host and the listing, the token deep link and the cloning all follow it. GitHub Enterprise is not supported yet. The listing shows namespace, visibility, star count and last activity so you can find the right repository without leaving the app. There is no server round-trip at any point: the connection goes straight from your machine to your git host, AgentsRoom's servers never see your repository list, the token is stored encrypted with the operating system's own secure storage under restrictive permissions and never crosses into the interface layer, and clone credentials are supplied as a transient header on the clone command only, never written into the cloned repository's git config. Read access is all that is requested, since importing only lists and clones. Opening a folder you cloned yourself still works exactly as before, and a repository imported this way is indistinguishable from one you cloned by hand. Keywords: import github repositories, import gitlab repositories, batch clone repositories, connect gitlab to ai agents, self hosted gitlab, gh cli authentication, glab cli authentication, clone repo into ai coding ide, set up a new machine repositories, github and gitlab in one app. ### Backlog Task Board https://agentsroom.dev/features/backlog-task-board Visual kanban board for orchestrating AI agent tasks with a drag-and-drop workflow. Create tasks in TODO, drag them to In Progress to automatically spawn an agent, and track completion across Pending and Done columns. Each task can be assigned to a specific agent role, include image attachments, and maintains a live link to the running agent terminal. Since 1.194.0 every save that changes a ticket's text or configuration keeps the previous version (History in the ticket header on the desktop: compare and restore; on the phone the version loads as a draft), board state excluded; scheduled agents and memory notes have the same history. Columns can be sorted on demand (by creation date, priority, tag or assignee) on desktop and on mobile. Several tickets that describe the same thing merge into one: the AI recombines their titles and descriptions into an editable draft, upvotes add up, comments, screenshots and links move over, and every reporter of every absorbed ticket stays subscribed so they are all notified when the fix ships. Per-ticket executor overrides let a single ticket pin its own provider, model, reasoning effort, account profile and skills, and worktree isolation is available from the default agent profiles in Settings. On Codex specifically, fast mode is enabled automatically for backlog tasks. Agents drive the board over MCP too: create, update, comment, reorder and now delete tickets without leaving the terminal. Tickets can also depend on each other, and the board enforces the dependency rather than merely documenting it: while a blocker is still open the blocked ticket sits in Pending instead of TODO, so Start next never picks it up; it returns to TODO on its own when the last blocker closes, and goes back to Pending if that blocker is reopened. A ticket already in review or done is never parked, a ticket parked by hand stays where its owner put it, and a ticket that turns out to be blocked while in progress is moved out of the way without killing the terminal running it. Agents create and remove those links over MCP, so one that discovers a prerequisite mid-run can create that ticket and link it in a single call. Tickets that already live in another tool are imported into the same board: GitHub Issues (a repository, a state, labels), JIRA Cloud (a project or a JQL query), Notion (a database shared with the integration) or Linear (the issues assigned to you, filtered by team, project and workflow status or status type, in one of several connected workspaces: one personal API key per workspace, each with its own label, so a consultant connects every client's workspace and picks one per import; detail: https://agentsroom.dev/features/linear-issues), with a preview before anything lands. Replaying the same import updates the tickets already imported instead of duplicating them: the source rewrites the title, description, type and labels on every pass, while the assigned agent, internal notes, board order and links between tickets are never touched, a ticket already in progress or done never drops back to TODO, and an issue that leaves the query keeps its ticket. The import is strictly one-way, read-only: nothing is ever written back to GitHub, JIRA, Notion or Linear. The access token stays encrypted on the user's machine and never reaches AgentsRoom servers, only the query is saved on the account so the refresh follows the project across machines. Each imported ticket shows its source, links back to the original issue and can be brought back in step on its own, without replaying the whole query. Screenshots attached to a JIRA, Notion or Linear issue are mirrored onto the ticket as real attachments, so the agent can open them rather than read a dead link. When only one ticket is wanted rather than a whole query, its reference is pasted straight into the TODO column and it comes in on its own, which is the everyday case for a developer working a shared team board. Connecting a tool is desktop-only; from the mobile app you can refresh the whole import, import a single ticket by reference or refresh one imported ticket, and all three run on the computer that holds the token. The board is not tied to the project you are looking at: its subtitle is a board switcher with a search field that lists the idea box first, then the projects open in the session, then the others, so someone who supervises several projects from the kanban changes board without closing it. The idea box is a board that belongs to the user and to no project, for ideas that have no home yet: same tickets, same editor, but it never starts an agent, and any attempt to start one opens the move dialog instead. A ticket can be moved to another board from its card menu or from the selection bar: it travels with its id, body, attachments and history and lands at the top of its column on the destination board; machine-local assignments are dropped, links to other tickets are removed, and a ticket filed by an outside reporter through the public backlog never moves, because its public page and thread belong to the board it was submitted to. All of it is on mobile too, and the idea box has its own screen next to the project list. An agent named after a ticket key of an external tracker (ARD-221, PROJ-14 login: the Linear, Jira, YouTrack and Shortcut shape) can start on that ticket by itself: a per-project opt-in setting (Project settings > Agents) sends the key as the agent's first message through a template (default: Start work on ticket {key}), once per agent and never replayed when the agent is reopened, so a skill triggered by "you are given a ticket number" fires without anyone typing the key the agent already carries in its name. Every project of the account can also be seen in ONE board: "All projects" in the head of any project board opens the backlog of every project, whichever machine the project lives on (tickets are stored on the server, so a project cloned only on another computer is readable too), filterable by project, ticket type, tag and free text, as a modal or in its own window. Each ticket opens read-only with its full description, can be moved between TODO, Pending and Done, and "Open in project" jumps to it on its project board when the project is on this machine. On the phone the same view is the Backlog tab of the tab bar, no desktop connection needed. Every ticket is versioned: each save that changes its title, description, type, tags, assigned agent or team, model or worktree settings (by you or by an agent) keeps the previous state, and the History button of the ticket, on desktop and in the mobile app, compares it with the current one and restores it as unsaved edits. Moving a ticket between columns is not a new version. Every ticket has an internal Comments thread where you and your agents leave notes (progress, hand-offs, blockers, questions); it is never shown to the person who reported the ticket. Agents write to it through the AgentsRoom MCP, and a project can name a lead agent (for example a product manager role) that receives each agent comment through Agent Mail to triage it. That thread is also the ticket's activity log, kept apart from its description: the checkpoints agents save in their conversations land there, and once a description reaches its size limit, the sections agents keep adding are filed there too instead of being refused, so a long autonomous workflow never loses an update. A ticket set to run in its own worktree shows its branch on the card (desktop and phone). Since v1.205.0 the board can open in its own window (Open in its own window, next to the close button of the backlog, desktop only), to keep on a second screen beside the agents: it follows the project selected in the main window, shows each ticket's agent status live, starting a ticket launches its agent in the main window, and Go to agent brings the main window forward on that agent's console. The automatic AI classification of a ticket arriving in the backlog (title, type, agent, tags, model, reasoning effort) is on by default and can be switched off from the board's quick settings or in Settings > Backlog, per project or for every project, with separate choices for whether the AI may set the model and the reasoning effort; a model or an effort picked by hand is never replaced, and with classification off the AI button still fills the ticket when clicked. On the phone, every card of the Todo column has a Start button that launches the ticket without opening it. A ticket can be locked against agents (the padlock next to the priority flag, desktop and mobile): the project assistant, Start next, triggers and every agent leave it alone, for a ticket still being thought through or too risky for now, while a human can still start it by hand. ### Linear Import (Linear issues onto the backlog, one AI coding agent per issue) https://agentsroom.dev/features/linear-issues Since 1.217.0, AgentsRoom imports Linear issues into a project's backlog so each one can be handed to an AI coding agent. A personal Linear API key (Linear Settings > Security & access, read access) opens one workspace; several workspaces can be connected, each with its own key and a name (for consultants and agencies working for several clients), and each project remembers the workspace its import uses. Filters: Assigned to me (checked by default), teams, projects (or No project), status types (Triage, Backlog, To do, In progress, Completed, Canceled) and the teams' own statuses; preview, then import up to 300 issues at a time. A single issue comes in by its key (ENG-123) or a linear.app link from the To-do column. Each ticket carries the issue's Markdown description plus a context block (priority, estimate, status, team, project, cycle, parent, sub-issues listed, not imported as tickets), and the images and files uploaded to the issue (up to 10) are downloaded and attached. Refresh updates tickets without duplicating them and never overwrites the assigned agent, notes, board order or links. Strictly read-only: only GraphQL queries reach Linear, nothing is written back (no status change, comment or closure). The API key is stored encrypted on each computer and never reaches AgentsRoom servers; only the query follows the project on the account, and a machine without the key shows Reconnect with a "Linear () not connected" badge. From the mobile app: refresh the import or import one issue, both run on the desktop. Any of the 14 supported agent CLIs works on an imported issue. Boundary with Linear's own options: Linear's official MCP server (https://mcp.linear.app/mcp, read-only variant /mcp/readonly; claude mcp add --transport http linear-server https://mcp.linear.app/mcp for Claude Code, codex mcp add linear --url https://mcp.linear.app/mcp for Codex) gives one agent tools to read and change Linear from its session, and OpenAI's Codex for Linear runs an assigned issue in a Codex cloud chat on OpenAI's machines; the AgentsRoom import puts the issues on a board with one agent per issue on the user's own machine, in any CLI, and both can be used together. ### Agent Teams (Multi-Agent Workflow Orchestration) https://agentsroom.dev/features/teams Visual multi-agent workflow editor for AI coding agents. Chain Claude Code, Codex CLI, GitHub Copilot CLI, OpenCode, Antigravity CLI, Aider, Grok Build, Mistral Vibe, Kimi Code, Amp, oh-my-pi, Freebuff, Devin, Cursor, Command Code and Muse Code agents on roles like Dev, QA, PM, Security and DevOps using an n8n-style React Flow canvas (the same engine behind n8n, Make, Pipedream and Retool). Every node is an agent with its own provider, model and step instructions. Edges can carry conditional flag checks (e.g. qaPassed equals true) to enable branching, feedback loops and retries with a configurable max-cycles guard. When an agent finishes its step, AgentsRoom builds a structured handoff payload (feature summary, git diff, changed files, touched areas, risks, test hints, flags), appends a note to a shared NOTES.md scratchpad in the workspace, and spawns the next agent with that payload as its starting context. A team declares HOW its roles are embodied, and the choice is made when the team is built. In relay mode (the default, and what every team built before the setting already does) ONE agent plays every role in turn: it hands its work over, becomes the next role in the same session, and never loses the context, but the session that wrote the code is also the one that reviews it. In team mode every role runs as its OWN live agent, alive side by side while the run needs them, writing to each other in real time with team_send; a teammate starts the first time the graph or another agent addresses it (once a step has handed off and the run can no longer return to it, its console is put to sleep to save memory and wakes with its conversation when addressed again; an opt-in team option, Close each step's console when it hands off, closes every finished step's console, loops included, so a later visit starts fresh), joins with no memory of the run, and catches up through the shared notes and the git diff, which is what makes its review an independent one. Two steps can play the same role (two Full-Stack Developers in one team, since v1.208.0): give each step a name (Display name, or the Name each step button of the editor) and each one gets its own address, so they can write to each other, while the bare role keeps working as an alias. Team mode has a second switch: with free-form conversation off a teammate may only write to the roles its node points to (the graph stays the contract, so a gate cannot be routed around), and with it on anyone writes to anyone, in any direction, and to several at once, so a tester can brief the front-end and the back-end developer in the same message and the back-end developer can answer the designer directly instead of going back through the lead. Inter-agent communication INSIDE a run is exposed through a dedicated MCP server (agentsroom-team), which is scoped to that run and dies with it (the permanent, project-scoped channel between saved agents is Agent Messaging, listed below) that gives every agent a robust set of tools (team_get_context, team_read_notes, team_post_note, team_read_inbox, team_roster, team_send, team_ask, team_read_timeline, team_read_diff, team_complete_step). These tools survive Claude context compaction because MCP tools are re-injected at every turn, and a UserPromptSubmit hook reminds the agent of new notes before each user message. A teammate that needs an answer marks its message as waiting (expectsReply), ends its turn, and is woken by the reply landing in its console, while the recipient is told to answer first; sends are budgeted per sender, per pair of roles and per ten minutes, and a duplicate of a message already sent is refused, so two agents cannot loop on each other or flood the team. NOTES.md and state.json are append-only and atomic, so they survive crashes, restarts and machine reboots. Five seed templates ship with the app: Build then verify, Spec build verify, Bug hunt, Release shield, and Feature squad (the messaging mode, four agents alive at once writing to each other in any direction). Run a team on any backlog ticket in one click. A run does not have to start with a click either: a trigger can point at a team instead of a single agent, so the pipeline fires on a calendar rhythm, on the quota window of your AI plan, or on a GitHub, GitLab, Slack, Linear, Sentry or CI event, see Scheduled Tasks (https://agentsroom.dev/features/scheduled-tasks) and Webhook Triggers (https://agentsroom.dev/features/webhook-triggers). Ephemeral agents per run, auto-destroyed on dismiss. Global teams in ~/.agentsroom/teams or project-scoped teams committed to the room. The AI dev team workflow editor for Claude Code, Codex, GitHub Copilot CLI, Antigravity, Aider, Grok Build, Mistral Vibe, Kimi Code, Amp, oh-my-pi, Freebuff, Devin, Cursor, Command Code and Muse Code, the multi-agent orchestrator that finally lets your AI agents work like a real engineering crew. A run no longer has only one way to stop. Besides the End node, a team can carry an AWAIT node: a pause the graph takes on purpose to ask the human something. The run parks instead of finishing (consoles kept alive, nothing destroyed), the question written on the node is shown in the run box on the desktop and on the phone, a native notification and a phone push announce it, and the moment you type an answer the run RESUMES on its own along that node's outgoing connection, with your answer carried into the next step's handoff payload alongside the diff and the flags the previous agent reported. When the Await node has conditional connections, your answer is also a DECISION: each connection is offered as a choice in the answer box (desktop and phone), and the one you pick sets its flags, exactly as an agent reporting them would, and is the route the run takes; a node whose every way out is conditional asks you to pick. An agent that cannot settle a question on its own therefore routes to the Await node instead of routing to End: the workflow asks you rather than ending, and picks itself back up without you having to nudge each agent by hand. The editor now validates the graph before you run it: blocking errors (missing Start or End, duplicate edges, two edges on the same condition, an invalid fan-out) and non-blocking warnings (a flag no step ever produces, a condition on an edge leaving Start, a node whose every outgoing edge is conditional) are listed in a checks panel and the guilty edges are recoloured on the canvas. While a run is alive its definition is frozen against MCP writes: nodes, edges, max cycles, step instructions, skills, check command, role, provider and model become read-only for agents, and a loaded skill cannot be rewritten either, because an agent must not rewrite the rule that governs it. You, the human, keep editing everything from the interface at any time. A node can be marked read-only: its agent is launched without write access to the project (no file edit, no git commit or push, no shell write), while reading, tests, lint, git diff and the team tools stay open, so a review, security or release-gate step judges the work without being able to fix it, and two review branches cannot collide writing the same correction. The refusal comes from the CLI itself on Claude Code (--disallowedTools), Codex (--sandbox read-only), Grok Build (--deny rules), Antigravity (--mode plan) and OpenCode (plan agent pinned through its inline config), and from the step prompt alone on the other CLIs; the review nodes of the shipped templates ship with it on. A node can also carry an entry check (entryCheckCommand): a command the runner executes before the step's agent is even launched, on every entry, loop-backs, resumes and parallel branches included; a non-zero exit, a cut-off or a command that cannot start never starts the step (zero model turns), and the node's entryCheckPolicy either blocks the run with the command's exit code and stderr on the timeline, or skips to the step you designate (entryCheckSkipTo). That is where an operational kill switch holds whether or not the agent reads its instructions, the exit-side check command being measured only once the work is done. Reasoning effort is pinned per step for the providers that expose it, parallel fan-out delivery is acknowledged rather than fire-and-forget, and a team run can be launched and followed from the mobile companion, with step progress and access to the current agent's terminal. A run launched on another computer of the account, by hand or by a webhook, shows on every other computer and on the phone as a real team box (its steps, its cycle counter, the machine it runs on) instead of loose agents named after their session titles, and a team run works on a project opened on a remote SSH server. A step can run in its own disposable checkout (Own checkout on the step): a git worktree cut from a snapshot of the run's workspace, uncommitted work included, so parallel steps that measure or review no longer overwrite each other's files; nothing written there reaches the run's branch, and the editor warns when two parallel steps share one tree and one of them can write. An agent building or repairing a team from its terminal no longer has to guess the wiring rules: capabilities_get on the AgentsRoom MCP server returns the connection contract the runner actually applies (node kinds and their fields, where the handoff flags that route a run come from, how the next node is picked and what happens when none matches, every blocking and warning rule, two known-good example graphs, and how a run is started, polled and finished), and teams_save accepts a dry run that validates a graph and writes nothing. The same tool describes the connector itself: which tool families this install advertises, which feature module failed to load and why, and whether the desktop is reachable, so a missing capability is answered instead of guessed. Since v1.187.0 a parallel branch that shares the working tree with other writing branches is told their names in its prompt and asked to re-read its files before trusting them; the handoff of each branch lists the files that changed in the shared tree during the fan-out ("Shared working tree:" line in its risks), and a console started twice for the same step is killed before it can write anything. In Relay mode, an optional team setting, Compact the context before each next step (off by default), makes the relay console run its CLI's /compact between steps, so the next role does not carry the whole history; the step instructions, the handoff and the shared notes are handed to the next step as usual, and CLIs without a manual compaction command skip it. Teams made for a single task can be marked Delete this team after its run (one-off team, off by default), and the Configure tab of the Teams window finds unused teams (never run, not run in the last 30 days, created by an agent) and deletes the selection in one confirmation. A run that reached End waits for you to finish it (finishing commits, merges its worktree and closes its ticket); the opt-in team setting "Finish after inactivity" (1 minute to 24 hours, 30 proposed) finishes it once no step has worked for that long, never cancelling a run that still works or waits for you. A "Wait for me" step can offer route choices: its conditional connections become options under "Your decision", the pick sets their flags and the run takes that connection, on desktop and phone. The Dynamic Island can show each team run as a single team icon (Settings > Dynamic Island > Team runs). A run also reports to the agent that drives it: when an agent started the run with backlog_start_next, AgentsRoom sends that agent an Agent Mail each time the run reaches End (or stops short of it on a step whose flags matched no connection), gets blocked, waits for you, finishes or is cancelled, with the run id, the ticket, the state, the stall reason, the last handoff flags and the next step, so a coordinator agent can finish the run, commit and start the next ticket within seconds instead of polling; Team settings > Callback agent (teams_save callbackAgentId) sends it to another saved agent or to nobody. ### Agent Messaging (agent to agent mail between the permanent agents of a project) https://agentsroom.dev/features/agent-messaging The saved agents of a project become permanent members that can write to each other directly, whichever CLI each one runs: Claude Code, Codex, GitHub Copilot CLI, OpenCode, Antigravity CLI, Aider, Grok Build, Mistral Vibe, Kimi Code, Amp, oh-my-pi, Freebuff, Devin, Cursor, Command Code and Muse Code. Seven MCP tools on the same AgentsRoom MCP server carry the whole surface: agents_list_live (the project roster with each member's live runtime state, unread count and current backlog ticket), agents_send (write to one member, to several, or broadcast to everyone, and get back the state of each recipient's console), agents_message_status (read back where a sent message stands for each recipient, so a sender never confuses a silence that means not delivered yet with a silence that means read and declined, and never sends the same thing twice to chase an answer), agents_read_inbox (read the calling agent's mailbox, with a peek mode that marks nothing), agents_reply (answer inside a thread and mark the parent replied), agents_ack (accept, decline or report done, with a note) and agents_report_status (declare a work phase, a blocker or a provider rate limit). The same tools also reach ANOTHER project of the same account: agents_list_live and agents_send take an optional project argument, so an agent that finds a bug in a shared library or a tool its repository depends on tells the agent that maintains it directly, with the same rate limits and pause controls, instead of opening a console there or filing a duplicate ticket; the answer comes back to the sender's own inbox. Each project also has its own PROJECT INBOX: agents_send with to "inbox" (and project for another project of the account) writes to the project as a whole rather than to one of its agents, for the common case where the sender does not know which agent over there owns the subject. Any agent of that project can read it (agents_read_inbox with projectInbox), take a request on (exclusive, so two teammates never do the same request twice), decline it for the project with a reason, or answer it, and the answer comes back to the sender; the request is announced to the project's Coordinator (by default its project assistant, below), and otherwise waits for the user in a box at the top of the agent list, where one click hands it to an agent of the project, starts a new agent on it, or declines it. Every project also gets a PROJECT ASSISTANT (called chief of staff before October 2026): a saved agent created automatically when the project opens, shown at the top of the project, as the first row of the project card above Ideas and planning and the agent counters (a foldable "Project assistant" section; when the project card is not on screen the same block heads the agent list), named after the project ("MyApp assistant"), with its own portrait, the project's logo on its avatar where other agents show their ticket type, and a hover tooltip that says what it does, and marked as the project's Coordinator. It is also one click away from the projects home, on the desktop and on the phone: every project card ends with a "Project assistant" bar (its portrait with a dot for its state) that opens its console directly, without opening the project first and creating the assistant if the project never had one, and going back (the title bar's Home button on the desktop, the console's back arrow on the phone) returns to the list, so moving from one project's assistant to the next takes two taps; above that bar the card shows the project's counters, the agents that need you, to review and working (the same words as the agent list) and its backlog tickets in progress and in review. The user tells it what they want; it turns the request into a backlog ticket, hands it to the best suited agent with agents_send, follows up when that agent goes quiet (agents_message_status, agents_list_live, agents_resume for a closed console), has the result checked by someone other than its author, and triages the project inbox, so a teammate never sits idle on a message nobody followed up. It never writes code and only creates a new agent after the user's explicit yes. It can be hidden in one project (its right-click menu, a long press on the phone, or Project settings > Capabilities & permissions) or in every project (Settings > AI providers & accounts), on the desktop and on the phone; hiding is the only way to put it away (its card has no close, delete, duplicate or fork button, and it keeps its full size even before its console is opened), and an assistant that already exists stays in the list as an ordinary agent when hidden. The identity of a member is its saved agent rather than a terminal session, so it survives a CLI restart, a model change and a provider change, and a runtime registry links that permanent member to whatever CLI session it currently runs in. The order is what matters: a message is written to disk BEFORE anyone tries to deliver it, so an agent that is offline, a CLI that crashes or an app restart can never lose one. Delivery is a side effect that waits for a good moment: it is held while the recipient is thinking, held while the recipient is waiting on an answer from the human (writing into that prompt would answer in the human's place; a setting, off by default, lets it through after a number of minutes the user chooses when nobody answers, and the agent is told its question is still open), and by default no console is started just to deliver mail, so an offline member's messages simply wait and the app shows them waiting. A setting, "A message may start the recipient" (off by default), lets a queued message open that member's console in the background, resumed on its previous conversation when one is recorded (never in a project you closed: there the message waits until you open the project again); a console that starts while mail waits for it is told in its boot brief to read its inbox before it asks its user for work, so agents can hand work to each other without a human relaying it. What lands in the terminal is a short notice (sender, subject, bounded preview) rather than the body, and reading the body through agents_read_inbox is what marks the message read, which makes the receipt describe something that actually happened. Delivered, read, accepted, declined and replied are separate appended events, never an overwritten value. A conversation between two agents (same pair, same subject) is capped so two polite agents cannot loop forever: 12 messages by default, up to 100 for long autonomous development and review cycles (Settings, "Messages per conversation"). The cap never arrives without warning: from half of it every send tells both agents how many messages are left, from 80 % of it the app refuses a send that does not carry a checkpoint (state of the work, decisions, evidence, blockers, next action) and saves that checkpoint in the project and in the Comments of the linked backlog ticket, and at the cap it hands the checkpoint back with the way forward, while each agent's mail shows the count and lets the human extend one conversation in one click. The sender is never an argument: the server stamps it from the calling CLI's own identity, so an agent cannot send under another agent's name. Three deliberate non-goals, worth quoting rather than inferring: this is NOT a second task board (the Backlog stays the single place where formal work lives, and a message can reference a ticket but never replaces one), NOTHING is promoted automatically from a thread into the Project Memory, and there is NO blocking wait tool, because freezing a tool call until a reply arrives depends on an MCP timeout the app does not control and that each provider sets differently: the supported pattern is send, finish the turn, be woken by the notice when the answer arrives. Agent Teams keeps its own role, and the boundary is the lifetime rather than the act of messaging: a team run in team mode also has agents writing to each other, but they are ephemeral nodes addressed by role in a graph, their inbox lives under the run directory and dies with the run. Agent messaging is continuous collaboration between permanent saved agents, addressed by name, for as long as the project exists. A permanent member can start a team run; a team run node is never promoted into a permanent member. The same page also documents the HUMAN side of that layer, which is a different button and a different guarantee: the broadcast that sends one message to every agent whose console is currently open, detailed as its own entry below (Agent Broadcast). The page also documents one real incident rather than only the happy path: on 7 September 2026 an agent working on AgentsRoom itself ran a single git command on 109 files it took for leftovers and destroyed the uncommitted work of five other agents sharing the same checkout, then reported itself, wrote the full list of destroyed files to disk and sent each of the five its own list through agents_send, and two of them had rebuilt their work before a human had read the report. The point of that section is the boundary of the feature: messaging does not prevent an agent from breaking something, it makes the five other agents hear about it from the one that caused it, with the exact list of what to redo. Keywords: agent to agent messaging, broadcast message to all ai agents, send one message to all my agents, broadcast to all Claude Code agents, message all running ai agents at once, multi agent broadcast, ai agent communication, ai agents that talk to each other, agent mail, ai agent inbox, cross cli agent messaging, cross project agent messaging, message an agent in another repository, project inbox for ai agents, message a whole project, shared agent inbox, project assistant agent, chief of staff agent, ai project manager agent, agent that delegates work to other agents, keep ai agents from going idle, Claude Code to Codex messaging, persistent ai agent team, permanent agent roster, mcp agent messaging tools, ai agent read receipts, offline agent message queue. ### Agent Broadcast (one message sent to every open agent at once, from the desktop or from the phone) https://agentsroom.dev/features/agent-messaging#broadcast Say one thing to your whole room of AI agents in a single send. A megaphone in the agents toolbar appears as soon as one console is open and says how many will hear it (message the 3 open agents): you type the instruction once and every agent with a live session receives it, whichever CLI each one runs, Claude Code, Codex, GitHub Copilot CLI, OpenCode, Antigravity CLI, Aider, Grok Build, Mistral Vibe, Kimi Code, Amp, oh-my-pi, Freebuff, Devin, Cursor, Command Code and Muse Code, so one broadcast can brief a Claude agent, a Codex agent and an Aider agent in the same breath. Every open agent arrives pre-selected as a chip carrying its live status (free, working, waiting on you) and any of them can be unticked before sending, so the two agents you would rather not interrupt mid-turn stay out of it. The message is written straight into each console exactly as if you had typed it there yourself, and every copy carries a header naming the other recipients and forbidding the agent to relay it, which is what stops five agents given one instruction from each starting the same work or from writing to each other about it. The answer is a per-recipient report rather than a single Sent: delivered, queued and failed are counted separately, because a fan-out that says Sent over two refusals leaves you believing the whole room was told. Two boundaries are deliberate. A broadcast NEVER boots a console: open agents are the recipient list and not a starting point, so an agent with no live session is simply not a recipient and nothing wakes ten CLIs or spends ten quotas behind your back; and an agent whose CLI is still starting keeps its copy queued instead of losing it, then receives it seconds later. It also works from the phone: the mobile companion has the same megaphone above the agents list, the open agents of the room arrive pre-selected, and the fan-out still runs on your desktop, so the header, the queueing and the per-recipient report are identical to the ones you get on the machine. This is the human's send, not the agents': it is human-initiated only, with no MCP tool behind it, because agent to agent fan-out stays on agents_send and its durable mailbox, rate limited on purpose so a chain of agents relaying each other cannot become a message loop. Distinct from Message Queue, which stacks several prompts for ONE agent, and from Agent Teams, which orchestrates a graph of roles: broadcast is one instruction, said once, to all of them. Keywords: broadcast message to all ai agents, send one message to multiple agents, message all running ai agents at once, multi agent broadcast, send a prompt to every agent, one prompt many agents, broadcast to all Claude Code agents, tell every coding agent the same thing, mass message ai coding agents, agent megaphone, group message ai agents, broadcast from phone to desktop agents. ### Open Space (every project and every agent on one screen, answered from a single composer) https://agentsroom.dev/multi-agent-dashboard#open-space A full-screen view of the WHOLE account rather than one project: every project you have open, every agent inside it, on one board with a column per state, most urgent first: waiting for your answer, to review, working, available (and, on demand, the agents you marked as done). The columns use the same states and the same words as a project's agent list. Filters narrow the board by project, role, CLI and machine, with a search across agents and tasks; each project's agent list has an Open Space button that opens the board already filtered on that project, and removing the project chip widens it back to the whole account. It is not another dashboard to read, it is where you ANSWER: one composer sits at the bottom of the screen, you type @ to pick an agent, write, send, and the message lands in that agent's terminal in its own project, exactly as if you had gone looking for its tab. Mention several agents and they all receive the same instruction, with the same broadcast header the agents toolbar uses. Nothing is rewritten on the way, so an answer sent from here is the answer you would have typed in the agent's own session, and a message aimed at an agent that is mid-turn is queued rather than dropped. An agent that asked through a Structured Questions card (https://agentsroom.dev/features/clarifying-questions) shows that question on its card in the waiting column, and Reply docks the same card above the composer, with its options, its own answer field, Not clear? and Close: the question is answered from the board without opening the agent's console, while what you type in the composer still reaches the agent as a plain message. On the phone, the Activity tab shows the same question under the agent's name. A line of stat pills across the top (each can be hidden; Details unfolds the full band) summarises the day across every project: how long the fleet ran, prompts sent, agents still waiting, activity rate and what your providers report as consumed, with per-provider logos when several subscriptions are stacked; a cell with nothing to say disappears instead of showing a permanent zero. An Anomalies button asks the project assistant to review the fleet and report what looks wrong (an agent stuck on the same question, a project nobody has answered today, a run that never ended). A row of project tiles above the board, with a red dot on the projects where someone waits, filters it; the sidebar shows as its compact rail while the board is open, and clicking a project tile there still leaves the Open Space and takes you into that project. This is the answer to "I do not know which agent is working on what" and to "I want one place to reply to every agent instead of navigating from one to the next", for someone running agents across five or ten repositories at once. Desktop only for now: the phone covers the transverse view with the Activity tab and the Companion feed, not the unified composer. Keywords: reply to all my agents from one place, one screen for every AI agent, AI agent control panel, AI agent control room, cross-project agent view, single composer for multiple agents, mention an agent with @, answer every coding agent without switching tabs, account-wide agent list, who is waiting on me, multi-project agent inbox, kanban board of AI agents, filter agents by project, role or CLI. ### Agent Morphing (Live Role Switching, Context Preserved) https://agentsroom.dev/features/agent-morphing Switch a running AI agent's role on the fly, without losing context. Agent Morphing injects a role-change prompt into the live session, so the same agent becomes a Product Manager, a Fullstack Developer or a QA engineer instantly: same session, full conversation memory, no respawn and nothing to re-explain, unlike spawning a new agent that starts from a blank context. Morph from the agent header on desktop (a chevron on the role, like the model selector) or from the agent sheet on mobile, into any of the 14 built-in roles, The Agency experts or community agents, with search. The agent's visual identity mutates instantly (avatar, color, sidebar name, terminal tab), a morph trail records every role traversed (PM to Dev to QA), a fresh eyes option gives review-type roles a critical verification posture, and you can adopt the new role's default model, switched live in-session when the CLI supports it. Provider-agnostic (Claude Code, Codex CLI and other agent CLIs) and built on the single-agent morphing engine of AgentsRoom Team Workflows, which is also selectable as the relay mode of an Agent Team, the alternative being one live agent per role messaging each other. One agent, a whole team: live role switching and mid-session persona switching for AI coding agents. ### Agent Fork (duplicate a running AI agent with its whole conversation) https://agentsroom.dev/features/fork-agent Fork a running AI coding agent in one click and get a twin that already carries its entire conversation: same role, same CLI, same model, and the context that matters, the decisions taken, the approaches ruled out and the files already read. On Claude, Codex and Grok the fork is the CLI's own session fork, so the twin inherits the real session file and, on Claude and Grok, is resumable from its first second; on every other supported CLI the twin starts a fresh session and is handed the parent console's transcript to read, and AgentsRoom writes that fallback on screen instead of degrading silently. The twin is a persistent agent of its own (it keeps a link to its parent but is listed like any other agent and outlives it), the two consoles then run in parallel on two separate conversations, and the original agent never stops, slows down or sees anything. To only ask the agent a question without a second agent, use Ask on the side (next section). Keywords: fork an ai agent, fork claude code session, codex fork session, duplicate a running ai agent, clone a coding agent with its context, copy agent conversation, branch an ai agent conversation, exploration branch, parallel ai agents, second opinion from the same agent. ### Ask on the side (side questions to a running AI coding agent, /btw-style, without interrupting it) https://agentsroom.dev/features/side-questions Ask a running AI coding agent a question without asking the agent: the round Ask on the side button at the bottom right of its console, next to Read aloud, opens a bubble, and the question runs in the background against a copy of the agent's conversation, so the agent's turn is never interrupted, nothing appears in its terminal and its history never contains the question or the answer. On Claude Code, Codex and Grok the copy is a fork of the real session (Claude and Grok resume one side conversation for every follow-up, Codex re-forks the parent with the side thread in the prompt); on GitHub Copilot CLI, OpenCode, Mistral Vibe, Antigravity CLI and Kimi Code a fresh session is handed the console transcript, and the bubble's subtitle says which of the two answers. Read-only where the CLI provides a verified mode: plan mode on Claude and Grok, a read-only sandbox on Codex, the plan agent on Mistral Vibe; elsewhere no flag is invented and the CLI's approval default keeps a run with nobody to approve from writing to disk. The answer streams into the bubble as Markdown with a live phase line and a seconds counter; each tab keeps its own thread and up to five tabs run in parallel; closing the bubble cancels nothing (the round button spins, then shows a badge with the number of answers to read) while closing a tab stops its run; a new tab starts on a lighter, faster model on Claude, Codex, Grok and Antigravity (Sonnet on Claude), another model can be picked in the bubble header, and a conversation too long for it is answered again on the agent's own model. Copy an answer, or Send to the agent, which only pre-fills the composer. The same side question works from the iOS and Android apps (agent action sheet and console dock), run by the desktop in the same tab. Compared with Claude Code's own /btw (an overlay in the terminal, context only, no tools, a single response per question) and Codex CLI, which has no /btw command in version 0.163.0 (checked on 2026-10-20). Not available on Aider, Amp, oh-my-pi, Freebuff, Devin and Cursor, whose one-shot mode is not verified yet: the button does not show. Side threads are not saved once the agent's console closes. Keywords: claude code btw, codex btw, codex btw alternative, side question ai agent, ask an ai agent a question without interrupting it, background question coding agent, read-only agent question. ### Customize Agents (Custom and Community AI Coding Agents) https://agentsroom.dev/features/customize-agents Build, share and install AI coding agents. AgentsRoom ships 14 built-in agent roles (DevOps, Fullstack, Frontend, Backend, Architect, QA, Marketing, PM, Security, Mobile, Git, SEO, i18n and Brainstormer), plus a Custom role you define, specialist agents from The Agency and community agents shared by other developers. Create your own custom agent with its own name, description, vibe, category and system prompt, stored at your account level and available in every project, with a server-generated avatar and an auto-translated name and description. A custom agent can also carry your skills and saved connections (servers, databases, dev commands): every agent created from it, on the desktop or from the phone, starts with them attached, and they stay private even once the agent is published. Any agent already tuned in a project can be reused everywhere: right-click it and choose Save to your agents, and its CLI, model, system prompt, permission mode, capabilities and skills are saved to your account, privately. In every other project the Add agent window lists it under Your agents, ready to add in one click, and a right-click there edits or deletes it. A saved agent's avatar (an uploaded image or a preset) is set once and shared: agents added from it follow it, an existing agent adopts it from Edit agent, and changing it later updates those agents in every project, on the desktop and on the phone, without touching their prompt, model or conversation, while an agent given its own avatar keeps it. Share any agent with a teammate in a single drag through the in-app chat (they import it in one click), or publish it to the community: after a moderation review it appears in the Community tier of the Add Agent picker and on the /agents page, credited to your public pseudonym, with creator badges as unique installs grow and a top-creators leaderboard. The same chat sharing also carries prompts, skills, dev commands and SSH connection metadata (never secrets). A global agent search spans built-in roles, The Agency specialists and community agents at once. Provider-agnostic: every agent works with Claude Code, Codex CLI, GitHub Copilot CLI, OpenCode, Antigravity CLI, Aider, Grok Build, Mistral Vibe, Kimi Code, Amp, oh-my-pi, Freebuff, Devin, Cursor, Command Code and Muse Code. The custom AI agent builder and community agent marketplace for AI coding: build your own coding agent, share agents with your team, and level up together. Agents you already wrote for your CLI are picked up too: AgentsRoom detects sub-agent definitions on disk (markdown files with frontmatter, at project scope and at user scope) and offers to import them as AgentsRoom agents, so a repository that already carries a squad of sub-agents does not have to be re-declared by hand. Detection is automatic, creation never is. Agents can do it too through the AgentsRoom MCP server: search the whole catalog (built-in roles, The Agency, community agents and your own), create a custom agent in your account and submit it for publication, each creation or submission only after your explicit yes. Deleting saved agents in bulk (since v1.223.0): the eraser button above the agent list opens Delete agents in all projects, which lists every saved agent of the projects open in AgentsRoom grouped by exact name, removes a name from every project or project by project, and offers Select N duplicates; an agent at work is never deleted. On the phone, ask your assistant: the agents_delete tool deletes saved agents by id or exact name, here or in every open project, after one confirmation card for the whole batch, also answerable from the mobile app; no answer within 2 minutes deletes nothing. ### Agent Suggestions (describe the task, get the right AI agent) https://agentsroom.dev/features/agent-suggestions An AI agent advisor built into AgentsRoom for developers who do not know which AI agent to use. Click the sparkle next to the agent search, describe the task in plain language ("write a launch blog post", "audit the login flow", "build prompts for image generation") and the advisor suggests the best-suited agent, each pick with a one-line reason written in your interface language plus up to two ranked alternatives. Candidates come from your whole roster: free agents already in your room first (flagged with an "In your room" badge), then the 14 built-in roles and a catalog of 260+ specialists from The Agency and community agents, including your own custom agents. Ranking is by specialty fit, not convenience: a true specialist to add beats a loosely-matched agent you already have. One click adds the suggested agent with its full persona, opens its terminal and pre-fills the typed task in the composer as a draft, never auto-sent. Complements the fuzzy agent search (role-name queries) with task-shaped queries no keyword search can resolve. Provider-agnostic: the suggested agent runs on Claude, Codex, GitHub Copilot CLI, Antigravity CLI, OpenCode, Aider, Grok Build, Mistral Vibe, Kimi Code, Amp, oh-my-pi, Freebuff, Devin, Cursor, Command Code or Muse Code. An agent recommendation engine, AI agent picker, agent selector and agent matching concierge: describe the task, get the right agent, assign it in one click. Included on every plan with a monthly allowance, unlimited on Pro, one free try without an account. When the monthly allowance is spent, attaching your own OpenAI API key in the app keeps it running on your key, billed to you by OpenAI at cost. **Video (1 min 14 s):** [Agent Suggestions, shown in the real app](https://youtu.be/B4aQfaRAZRc). The only agent open is a frontend developer and the next task is a launch blog post. A click on the sparkle next to the agent search, the task typed in plain words, and the advisor names the agent that fits (a marketing specialist in this take) with a one-line reason and two alternatives, agents already in the room marked. Add and assign the task adds it to the project and opens it with the task waiting in its message box, not sent until Enter. Subtitled in every site language. ### AI Commit Messages (generate clean Conventional Commits from the real diff) https://agentsroom.dev/features/ai-commit-messages An AI commit message generator built into the AgentsRoom commit panel and review mode. Click the sparkle on the commit message field, optionally type a rough draft ("fix temp pdf"), and it writes one clean commit message from the real git diff of the files scoped to the commit (per-agent filter and excluded files respected), in Conventional Commits format, following free-text per-project format rules like "always bug(TICKET) : Description" that sync with your account. The diff is sent only on an explicit click and never stored server-side; it stacks on a free deterministic pre-fill that derives the message from the backlog ticket title and type, the agent's session title or its latest notification, and credits public backlog reporters by first name. Included on every plan with a monthly allowance, unlimited on Pro, one free try without an account. When the monthly allowance is spent, attaching your own OpenAI API key in the app keeps it running on your key, billed to you by OpenAI at cost. **Video (1 min 20 s):** [AI Commit Messages, shown in the real app](https://youtu.be/NDs2A1qAMIQ). An AI coding agent fixes a checkout total and changes three files, listed under its name in the Changes tab; the commit message box says wip, a click on the sparkle with the rough draft "fix coupon total" returns one clean message read from the real diff (a fix prefix, a short subject, a short body), and Use this message puts it in the box while the commit itself stays your click. ### Browser Automation (Agentsroom Browser MCP) https://agentsroom.dev/features/browser-automation Browser automation for AI coding agents. AgentsRoom embeds a real Chromium browser inside every project room (Electron WebContentsView, persistent per-project session for cookies and localStorage, isolated by partition) plus the AgentsRoom Browser MCP server (agentsroom-browser) that exposes the browser to your AI agents through the Model Context Protocol. Tools shipped today: browser_navigate, browser_click, browser_type, browser_screenshot, browser_evaluate, browser_wait_for, browser_get_state, browser_get_logs, browser_set_viewport, browser_go_back, browser_go_forward, browser_reload. Canvas-rendered web apps (Compose Multiplatform for Web on Kotlin/Wasm, Flutter Web) work too: selectors pierce open shadow roots the way Playwright's do (plain CSS, or host >>> inner), and browser_click / browser_type take trusted: true to send real mouse and keyboard events through Chromium's input pipeline (CDP), plus a click at x / y viewport coordinates and a force option for accessibility overlays with pointer-events: none, so an agent can log in and walk such an app without a hand-written Playwright script. browser_set_viewport resizes the page viewport so the agent reviews a layout at a real width: device presets (iPhone SE through iPad Pro) give true mobile semantics (viewport meta tag honoured, touch events, devicePixelRatio, mobile user agent), a raw width covers desktop breakpoints, and the embedded panel resizes with it so you watch the same page the agent is judging. After every page-changing action, an inline base64 PNG screenshot (capped at 1.6 MB) is appended to the tool response so the agent visually verifies its move, which is the single biggest reliability win for agentic browser automation. Console logs (log, warn, error) are queryable so the QA agent can detect React hydration warnings, useEffect issues, network 404s, CORS failures and runtime exceptions that unit tests would miss. The bridge between the MCP subprocess and the Electron browser runs on 127.0.0.1 only, on an OS-assigned port, authenticated with a 32-byte hex token regenerated at every desktop boot. Smart URL handling: localhost:3000 becomes http://localhost:3000 instead of triggering a 'cannot open application' dialog. Auto-targets the localhost tunnel preview, a detected dev server, or https://localhost:3000 by default. Wired into Agent Teams so a QA node spawns with browser access automatically. Works with Claude Code, Codex CLI, GitHub Copilot CLI, OpenCode, Antigravity CLI, Aider, Grok Build, Mistral Vibe, Kimi Code, Amp, oh-my-pi, Freebuff, Devin, Cursor, Command Code and Muse Code through the standard MCP protocol. Use cases: end-to-end smoke tests, regression tests, visual regression QA, console error hunting, form validation testing, accessibility audit, design QA against Figma, live preview tunnel verification, customer bug reproduction from public backlog tickets. Dev and staging sites behind an .htaccess password (HTTP Basic or Digest) open too, since 1.220.0: the browser asks for the username and password in a Sign in to this site window and sends them to that site only. Ticking Remember for this project, or adding rules in the HTTP sign-in tab of the QA context (a host such as preprod.example.com, or *.example.com for every subdomain, like the MultiPass extension), lets the browser answer by itself, for you and for the agents driving it. Agents never see the password: it is stored encrypted on the computer and follows the account to the user's other computers end-to-end encrypted when password sync is on. Pages in the built-in browser follow the operating system's light or dark theme by default; the Page theme button of the browser toolbar forces them light or dark without changing the AgentsRoom window, and the choice follows the account. Roadmap: a native AgentsRoom Browser as a first-class browser feature, plus React Native MCP and Electron MCP servers so AI agents can also drive mobile apps and desktop apps for end-to-end testing. The Playwright MCP / Puppeteer MCP / Selenium / Cypress alternative for AI coding agents that need a real, persistent, debuggable browser, not a fresh headless instance on every tool call. **Video (1 min 15 s):** [Browser Automation, shown in the real app](https://youtu.be/BbmqAf63rpQ). An AI coding agent allowed to drive the browser built into AgentsRoom (one switch in the access list at the top of the browser panel) adds a newsletter signup to a shop page running locally. It opens the page itself, types a test email and clicks Subscribe, sees that the form stays on screen next to the thank-you message, fixes its own styles and tries again, then reports what it saw in the browser. Subtitled in every site language. ### Chrome control (AI agents drive your real Chrome through the AgentsRoom extension) https://agentsroom.dev/features/chrome-control Chrome control: agents drive your real Chrome through the AgentsRoom extension. Every Chrome profile is a named target (Pro, Personal, Client), so one agent can work on your pro account and another on your personal one at the same time, each in its own tab, with your sessions, cookies and extensions; the browser can sit on another machine of your account, relayed end-to-end encrypted with a key the relay never holds, the same transport as the mobile companion. It is part of the AgentsRoom Browser MCP server, so it works with every agent CLI (Claude Code, Codex, GitHub Copilot CLI, Cursor, OpenCode, Grok Build, Mistral Vibe, Kimi Code, Aider and the others), including CLIs that ship no browser extension of their own: the extension belongs to AgentsRoom, not to the model vendor. The agent calls browser_list_targets then browser_select_target by name, and the usual browser_navigate, browser_click, browser_type, browser_screenshot, browser_evaluate tools act on that Chrome, and chrome_upload_file (since 1.194.0) attaches a file from the agent's own machine to a file input, an editable area or a drop zone, ten files and 6 MB per call, the content never entering the model's context. Driving is off by default and switched on per browser from the extension popup ("Let my agents drive this browser"), the first action opens a fresh tab so the agent never takes the tab you are reading, and Chrome shows its own "AgentsRoom started debugging this browser" banner for the whole session. The embedded browser stays the default target. When several computers of the account run Chrome at the same time (since 1.195.0): a Chrome seen on the same computer as the desktop is labeled "This computer" and takes its computer's name by default ("Chrome · Mac Mini"), one profile can be checked as the default Chrome of that machine (stored locally, also settable by an agent with chrome_select_browser makeDefault), and an agent that names no Chrome gets the checked default first, then the only online Chrome of its own computer, then the only online Chrome anywhere, and an error naming chrome_list_browsers otherwise; an explicit choice by the agent is never overridden. Token saver mode (beta, off by default, switched on from the desktop or the extension popup): instead of a screenshot after every action, the agent reads the page with chrome_read_page (a filtered, capped list of the clickable elements, each with a short ref such as ar12 that click and type accept) and chrome_get_text (capped readable text), and gets a screenshot only when an action fails or when it asks for one. Measured: a screenshot costs about 1,400 to 1,800 tokens, a page outline 140 to 820 (2 to 13 times fewer), so a five-action scenario drops from 7,000 to 9,000 tokens to 400 to 2,500. Works for forms (inputs, buttons, checkboxes with their state, passwords masked); open shadow DOM is traversed, and in Chrome so are iframes, cross-origin ones included (an ad platform's setup wizard, an embedded editor): chrome_get_state names them f1, f2..., the outline prints their refs as f1:ar10003, and chrome_click, chrome_type, chrome_wait_for, chrome_evaluate take frame: "f1". chrome_click also sends a real mouse click (trusted: true) or clicks a point of the screenshot (x / y), which reaches whatever is there when nothing else can. The same mode applies to the embedded browser (browser_read_page, browser_get_text), which does not enter iframes. AgentsRoom shows the estimated token cost of every browser action for every agent CLI (a badge per call in the trace, a 24-hour total per mode), and the tokens actually billed per tool for Claude and Codex (session details). Unlike Claude in Chrome, not tied to one account or one provider: it is the Claude in Chrome alternative when your agents are not Claude, when you need several accounts driven at the same time, or when the Chrome is on another machine; the two extensions can be installed side by side. Keywords: AI agent control Chrome, let an AI agent use my browser, Chrome extension for AI coding agents, browser agent on multiple Google accounts, remote browser control, Claude in Chrome alternative, reduce browser agent token usage, AI agent screenshot token cost. ### Public Remote Backlog (Feedback-Driven AI Development) https://agentsroom.dev/features/public-backlog Expose your AgentsRoom project backlog as a public, unlisted or restricted feedback portal wired directly to your Claude Code, Codex CLI, GitHub Copilot CLI, OpenCode, Antigravity CLI, Aider, Grok Build, Mistral Vibe, Kimi Code, Amp, oh-my-pi, Freebuff, Devin, Cursor, Command Code and Muse Code agents. Clients, users or external contributors submit bugs, feature requests and questions, upvote tickets that matter to them, leave comments in a visible thread, and track progress on an optional read-only roadmap view (Planned / In development / Shipped with customizable status labels). Every ticket lands in the same backlog your AI agents execute against: drag it to In Progress and a Claude agent starts coding immediately with the client's exact wording as its prompt. Includes a 3 KB embeddable JavaScript widget for any website, an AgentsRoom Chrome extension that files tickets from any web page with one click (with selected text auto-captured as context, works for both public backlogs and the signed-in user's own projects), magic-link authentication for restricted backlogs, branded automatic client emails (in-progress, resolved, team reply, hourly digest, invitation), a 30-day redirect on slug rename to preserve backlinks, a custom subdomain `{slug}.backlog.agentsroom.dev`, and per-client notification preferences. Duplicate reports merge into a single ticket in one action: the AI combines the titles and descriptions (editable before you confirm), upvotes add up, comments and screenshots move over, every reporter of every merged ticket stays subscribed and is notified when the fix ships, and the links already sent to them redirect to the surviving ticket. Feedback-driven AI development, AI-powered client portal for agencies and freelancers, Canny / Featurebase / Fider / UserVoice alternative for teams building with AI coding agents. ### Idea Radar (Idea Board That Clusters User Feedback Into Themes) https://agentsroom.dev/features/idea-radar The idea management board that sits next to the AgentsRoom backlog and holds everything you have heard but not arbitrated yet. User feedback lands raw from the support chat, the public submission form, a demoted backlog ticket, a manual note or the mobile app, and is stored as a signal: the exact verbatim, its author, its source and its date. The verbatim is immutable, no route and no agent can rewrite the sentence a person actually typed. Signals cluster themselves into ideas and ideas into themes (a cheap model call on arrival, plus an on-demand recluster pass over the whole corpus that never dissolves a pinned theme), duplicates are surfaced by embedding similarity before they become two separate builds, and every idea carries the number of people who asked for it rather than a score somebody invented. Because the atomic unit is the signal and each signal already carries its reporter, merging two ideas cannot drop anyone: it is a property of the schema, not a rule a developer has to remember. Five lenses read the same corpus: a plain list of every idea (search, filter by status or theme, sort by date, requests or votes, and the default view), themes (affinity mapping), an impact/effort matrix whose positions are written onto the record, an opportunity solution tree with an explicit unattached column as the anti-graveyard guardrail, and a semantic constellation map for finding duplicates and gaps. The Radar is an extra tab on the existing public feedback board, same slug and same host, with the three visitor-facing tabs named Ideas, In progress and Shipped instead of project-management jargon: visitors submit, upvote, comment and follow, and an idea posted by a visitor stays private to its author and to the owner until it is qualified. A Product Manager AI agent (or Brainstormer, UX Researcher, business analyst) runs in the Radar panel with full read access through MCP and proposes reclustering, merges, impact/effort scores and the next ticket with the verbatims that justify it, but promoting an idea and replying to a reporter stay human actions. The bridge with the backlog runs both ways: promote a ripe idea into a backlog ticket and every reporter of every signal becomes a follower and is notified, or demote a ticket you will not build this quarter back into an idea that stays visible and votable. Bulk cleanup of a backlog column into the Radar counts people rather than tickets, sends one message per person instead of one per ticket, and stays cancellable for ten minutes. Automatic clustering works with your own OpenAI key. Available on mobile with the same data and actions, the matrix and the tree becoming a sorted list. Keywords: idea management software, idea board, feature request board, user feedback board, product feedback tool, feedback triage, idea backlog, public roadmap, idea voting, product prioritization, impact effort matrix, opportunity solution tree, affinity mapping, automatic clustering of user feedback, duplicate feature request detection, AI product manager, continuous discovery, voice of the customer. The Canny / Productboard / Featurebase alternative for teams whose backlog is executed by AI coding agents. ### Ticket Scoping (Frame Fuzzy Feedback Into a Product-Faithful Mockup) https://agentsroom.dev/features/ticket-scoping Turn a fuzzy user feedback ticket into a framed, validated request before any code is written. One click on a feedback ticket spawns a temporary Product Manager AI agent that explores your project's codebase, understands the real product it targets (mobile app, website, desktop app or dashboard) and its visual identity, then builds a single self-contained HTML mockup that faithfully reproduces that product with the requested change applied in context, not a generic wireframe. The mockup is published through the backlog_publish_mockup MCP tool and the preview link comes back to you for review; by default it is not sent to the reporter, so you decide whether to share it. Scoping is deliberately a validation step: it never starts the task, never moves the ticket to In Progress, never sends a work-started notification, never writes files and never commits. A two-way conversation lives on the same ticket, you comment on the backlog and the message lands in the reporter's in-app feedback chat, they reply and it returns as a comment, one thread and one source of truth. The natural extension of the public remote backlog and the feedback chat, it bridges a vague user suggestion and exactly the right build. Works with Claude, Codex and Antigravity. Keywords: ticket scoping, backlog scoping, scope a feature request, turn feedback into a mockup, AI mockup from feedback, Product Manager AI agent, feature validation, requirements clarification, feedback-driven development, backlog refinement. The agent that performs the scoping is configurable: a global Scoping Agent profile, overridable per project, decides the provider and model that frames the idea, instead of inheriting whichever executor the ticket happened to carry. ### Multi-Provider Support https://agentsroom.dev/features/multi-provider Run AI coding agents with 16 different providers side by side: Claude (Anthropic), Codex (OpenAI), GitHub Copilot CLI (GitHub), OpenCode, Antigravity CLI (Google), Aider, Grok Build (xAI), Mistral Vibe (Mistral AI), Kimi Code (Moonshot AI), Amp (Sourcegraph), oh-my-pi, Freebuff (Codebuff), Devin (Cognition), Cursor (Anysphere), Command Code and Muse Code (Meta). Each agent can use a different provider and model, and a default reasoning effort per CLI can be set globally (Settings > AI providers) and per project since 1.194.0: an agent without an effort of its own inherits it at launch, clamped to what the launched model offers. Switch provider mid-conversation while keeping full context thanks to automatic handoff summaries that include modified files, session activity and work progress. Each agent also has a per-agent CLI options field: extra launch flags passed straight to that agent's CLI, overriding the provider-wide default set in Settings. This is the escape hatch to pin a model or version the picker does not list (for example a flag like --model opus-4.8 to use a previous Opus release an account still has access to) or to pass any other CLI flag, for one agent only. When those flags already pin a model, AgentsRoom adds none of its own, so the CLI only ever sees one: that is how an agent reaches a model alias served by an external OpenAI-compatible gateway (a local router such as OmniRoute, OpenRouter or LiteLLM), and picking Default in the model picker has the same effect with no flag at all. Environment variables come at three levels, merged key by key: a provider-wide block in Settings, a PROJECT block every agent of that repository inherits whatever CLI it runs on (so a repo's own token or staging URL is set once instead of on every agent, and a quick agent that owns no saved blueprint carries it too), and a per-agent block that wins over both. One KEY=value per line, which is the only way to point a CLI at a model BACKEND rather than another CLI (an OpenAI-compatible gateway such as a local OmniRoute, OpenRouter or LiteLLM instance, or a company proxy, wired with OPENAI_BASE_URL or ANTHROPIC_BASE_URL). A value can reference a secret from the built-in Secret Manager, resolved at launch, so the token never reaches a prompt or a transcript. In harness vocabulary this is the harness-agnostic layer: 16 agent harnesses running in parallel on the same working tree, each keeping its own agent loop, tools and permissions, with one dashboard above them. Your own MCP servers reach every provider too: declare a server once, in Settings (every agent of every provider on the machine), per project (every agent of that repository, whatever CLI it runs on) or per agent, as the usual mcpServers JSON or from a list with a switch per server (an inherited server can be turned off for one project or one agent alone), and AgentsRoom writes it next to its own servers into the native config of the CLI being launched, in that CLI's own format (a private launch file for Claude Code and Copilot, the generated home for Codex and OpenCode, the project-scope config for Grok, Mistral Vibe, Kimi, Antigravity, Amp, oh-my-pi, Freebuff, Devin and Cursor). An Add from catalog button searches the official MCP registry (name, logo, description, verified publisher) and writes the declaration for you, secret reference included. A remote server with a bearer token or a local command both work, and a header or env value can reference a secret from the built-in Secret Manager, resolved at launch on your machine, so the credential never sits in a prompt, a transcript or the repository. Since v1.188.0 every model list (launch menus and dialog pickers, desktop and mobile) has three sort orders, Power (most capable first, the default), Price (cheapest first) and Popular (most launched by the community first), remembered across lists; when one CLI serves several subscriptions (OpenCode: OpenCode Go, Z.AI Coding Plan, Z.AI pay-as-you-go), a row of chips filters the list by subscription before you pick the model, and every row of the launch menus (lightning button, agent card, backlog ticket) carries a Pin button, pinned models forming a section at the top of the menu; Codex offers the GPT-6 family (Astra, Sol, Luna) with their reasoning tiers. Keywords: multi-harness setup, run Claude Code and Codex together, swap agent harness mid-task, harness-agnostic coding agent runner, project environment variables, env vars for every agent in a project, share an API token with all my agents, per project KEY=value block, custom MCP server for every agent, private MCP server with bearer token, remote MCP server on Codex Grok Kimi Antigravity, share an MCP server across providers, Cloudflare Worker MCP server for coding agents. Since 1.203.0 a Codex agent also gets a context window choice next to its model, on the desktop and in the mobile app: Standard, the maximum its local Codex catalogue announces (the default, and a global or per-project default can prefer Standard), or a custom size with an automatic compaction threshold; the choice is passed to the CLI at launch as -c model_context_window and -c model_auto_compact_token_limit, in a fresh launch as in a resume, and Claude keeps its own [1m] selector. Provider lists follow real community launches over the last 30 days, using the same source as https://agentsroom.dev/llm-usage. The server refreshes the order at most once every 24 hours, with Claude first and providers not yet ranked at the end. Desktop and mobile cache the same order locally; offline they retain their last known order, or use a shared fixed fallback. ### Claude Multi-Account (multiple Claude Code logins) https://agentsroom.dev/features/claude-multi-account Run multiple Claude Code accounts in the same IDE: a Work account, a Personal account, a client account, all signed in simultaneously. Pin one Claude account per project so every agent in that project inherits it, then override per agent when needed (cascade: agent override > project pin > global default > system ~/.claude). Accounts follow the user's AgentsRoom account across computers (name, colour, signed-in email, and the pins of projects, folders and agents), while the sign-in itself stays per computer: the token is never synced, each machine signs in once. Sign-in is fully embedded: AgentsRoom spawns a mini PTY running the official `claude` CLI with the right `CLAUDE_CONFIG_DIR`, you complete OAuth in the browser, and the status badge flips to "Signed in" the moment the credentials file lands on disk. Each account is an isolated directory containing its own OAuth tokens, session metafiles, JSONL transcripts and project history (no shared identity, no cross-leakage). That directory is also where Claude Code reads its whole USER layer from, so a fresh account starts without your slash commands, skills, subagents, `CLAUDE.md`, hooks, plugins or MCP servers (user scope, and the project scope that `claude mcp add -s local` writes into `.claude.json`): the Settings switch "Use my personal CLI configuration" links your own `~/.claude` layer into every account (and your `~/.codex` layer into the homes generated for Codex), while credentials, sessions, transcripts and usage stay isolated. AgentsRoom also lists exactly what it found in your configuration and what is currently not reaching your agents, so a missing slash command is never mistaken for a command you wrote wrong. Compatible with CCS (Claude Code Switcher) profiles: point an account at `~/.ccs/instances/` and reuse its credentials directly, no re-login required. Token usage tracking and per-agent file attribution work across all accounts thanks to a multi-directory scan that finds the right session metafile by PID. CCS / Claude Code Switcher alternative built directly into the AgentsRoom IDE, with per-project pinning, per-agent override, in-app sign-in and live signed-in status, none of which exist in shell-based switchers. Right-click a closed agent, or the flash agent button, to launch it on another account for that one launch only, without editing the agent: the usual way past a usage wall. The usage gauge in the status bar follows the account being spent, and can also show the accounts you pick side by side, or as one compact pill that lists them when hovered, so the remaining quota of every subscription is readable at a glance without opening the usage panel. ### Codex Multi-Account (multiple Codex CLI logins) https://agentsroom.dev/features/codex-multi-account Run multiple Codex CLI accounts in the same IDE: a Work account, a Personal account, a client account, all signed in simultaneously. Pin one Codex account per project so every agent in that project inherits it, then override per agent when needed (cascade: agent override > project pin > global default > system ~/.codex). Sign-in is fully embedded: AgentsRoom spawns a mini PTY running the official codex login CLI with the right CODEX_HOME, you complete OAuth in the browser, and the status badge flips to "Signed in" the moment the credentials file lands on disk. Each account is an isolated directory containing its own auth tokens and session data. Codex additionally runs against a CODEX_HOME that AgentsRoom generates per project, on every launch, so its user layer comes from that generated home rather than from `~/.codex`: the Settings switch "Use my personal CLI configuration" is what loads your own prompts, skills and global `AGENTS.md` into it. The unified Multiple Accounts panel in AgentsRoom Settings manages Claude, Codex and Antigravity accounts side by side under the same UI, with one tab per provider (an Antigravity account there is a Gemini API key, not a Google subscription login). Multiple Codex accounts AND Claude accounts in the same window: a Codex Work agent, a Codex Personal agent and a Claude agent can all run in the same project. Right-click a closed agent, or the flash agent button, to launch it on another account for that one launch only, without editing the agent. Since v1.184.0 AgentsRoom also reclaims the disk those generated CODEX_HOME directories take: the home of a deleted project or of a removed Codex account is removed at startup, and inside living homes the rollouts, sqlite logs, generated images and temp folders older than the retention you set (Settings, Codex, 90 days by default, 0 for never) are deleted, never a rollout a saved agent can still resume and never a home a running console uses; a "Reclaim disk space" button runs the same sweep on demand. ChatGPT's own account switching (OpenAI help article, October 2026) works on ChatGPT web, up to two accounts at once, and is not yet supported in the Codex desktop app or the native ChatGPT mobile apps; Codex CLI keeps one signed-in account per CODEX_HOME, which is what AgentsRoom multiplies. ### Grok Multi-Account (multiple Grok Build logins) https://agentsroom.dev/features/grok-multi-account Run multiple Grok Build (xAI) accounts in the same IDE: a Work account, a Personal account, a client account, all signed in simultaneously. The grok CLI keeps its whole local state (auth.json, config.toml, sessions) in one directory, ~/.grok by default, relocated by the GROK_HOME environment variable: one directory is one signed-in account. AgentsRoom pins an account per project so every agent in it inherits the account, per sidebar folder so a whole group of repositories starts on the same one, and per agent as an override (cascade: agent override > project pin > nearest folder > global default > the CLI's own home). Sign-in is embedded in Settings: AgentsRoom runs the official grok login in a mini terminal with the right GROK_HOME, and the signed-in badge appears by itself when auth.json lands in that directory. IMPORTANT AND COUNTER-INTUITIVE: setting XAI_API_KEY does NOT switch account. Grok uses an API key only as a fallback when no session token is active, and a stored session token takes precedence, so a key-based switch fails silently for anyone who has ever run grok login. Likewise, grok login replaces the cached session for the whole machine, which makes manual switching global and destructive. Separate directories are the only reliable lever, and that is what AgentsRoom drives. Credentials never leave the machine and never pass through AgentsRoom. Keywords: two Grok accounts, Grok Build multiple accounts, switch Grok account, run two Grok accounts, Grok work personal account, GROK_HOME, xAI account per project. ### Cursor Multi-Account (multiple cursor-agent logins) https://agentsroom.dev/features/cursor-multi-account Run multiple Cursor (Anysphere) accounts in the same IDE: a Work account, a Personal account, a client account, all signed in simultaneously. The cursor-agent CLI reads its credentials and cli-config.json from one directory, ~/.cursor by default, relocated by the CURSOR_CONFIG_DIR environment variable: one directory is one signed-in account. AgentsRoom pins an account per project, per sidebar folder and per agent as an override (cascade: agent override > project pin > nearest folder > global default > the CLI's own directory). Sign-in is embedded in Settings: AgentsRoom runs the official cursor-agent login in a mini terminal with the right CURSOR_CONFIG_DIR; Cursor does not publish where the browser login writes its credentials, so AgentsRoom does not guess a path and you confirm when the browser step is done rather than being told an account is ready when it might not be. IMPORTANT AND COUNTER-INTUITIVE: setting CURSOR_API_KEY does NOT switch account. A key is a fallback used when no session is active, and a session token already stored on the machine takes precedence, so the switch fails silently. Likewise, cursor-agent login replaces the cached session for the whole machine, which makes manual switching global and destructive. Separate configuration directories are the only reliable lever, and that is what AgentsRoom drives. Credentials never leave the machine and never pass through AgentsRoom. Keywords: two Cursor accounts, run two Cursor accounts, switch Cursor account, Cursor work personal account, CURSOR_CONFIG_DIR, Anysphere account per project, cursor-agent login multiple. ### Account Auto-Switch (keep working past a Claude, Codex or Grok Build usage limit, through a quota rule) https://agentsroom.dev/features/account-auto-switch When the Claude, Codex or Grok Build account an agent runs on is about to exhaust its usage quota mid-task, AgentsRoom hands the SAME conversation to another account you are already signed in to and the work continues. No restart, no lost context, no waiting for the 5-hour or weekly window to reset. How it works since v1.188.0 (2026-09-23): the switch is a QUOTA RULE, not a terminal watcher. A rule written in the Usage panel (footer; since v1.192.0 the panel has two columns, the quota bars on the left and the actions on the right, where the "Quota management" card sits; New rule, action "Move running agents") reads the quota bars the CLI publishes and says, for example, "when the session or the week of my most constrained account reaches 99%, move the running agents to another account"; it fires once per quota window, and a second condition on another window can be required. Nothing reads the terminal any more, so a conversation that merely talks about limits, or a file that quotes one, cannot trigger it. When it fires, AgentsRoom benches the exhausted account until its quota window resets (provider's real reset time), picks another signed-in account of the same provider with the most quota left, migrates the session transcript into that account's directory (mandatory for Claude, whose sessions physically live inside the account that created them), relaunches the CLI resuming the same session id, and sends a short instruction to continue the interrupted work rather than restart it. A pre-flight check also applies at launch: an agent starting on a benched account is bound to a healthy one instead of burning a launch to rediscover the same wall, and sibling rules can block or redirect a launch before it starts. Providers: Claude Code (CLAUDE_CONFIG_DIR), Codex (CODEX_HOME) and Grok Build (GROK_HOME): the three CLIs that publish a readable quota bar and isolate a whole account on disk, so the conversation travels with the agent. Antigravity CLI and Cursor have one quota reading for the whole machine, not one per account, so no rule can tell their accounts apart and there is NO automatic switch for them (their accounts still run side by side, rebinding an agent is manual, and the agent restarts cleanly rather than resuming). Off until you write the rule: pooling two subscriptions is a billing decision. Users who had the former global switch on got the equivalent rules created on update, named "Keep going when an account is exhausted" (session and weekly, 99%), readable, disableable and deletable like any rule. Per-account opt-out ("Never used as backup", Settings > AI providers and accounts) covers a strict work/personal or client/client separation. Every switch is announced by a line in the agent's terminal, and the account each agent runs on is visible on its card. AgentsRoom does not create accounts, share credentials or pool other people's quota: it uses subscriptions you own and are signed in to, through the account-isolation mechanism each CLI documents. Google AI Pro and Ultra subscriptions cannot be alternated on Antigravity (the CLI keeps that login in the OS keyring, one account per machine); what AgentsRoom supports there is several Gemini API keys, one per agent. Keywords: claude usage limit reached keep working, claude code out of quota switch account, codex usage limit switch account automatically, grok build weekly limit switch account, resume claude session on another account, claude 5-hour limit workaround multiple accounts, quota rule switch running agents. ### Usage Alerts (a notification before a Claude Code, Codex, Grok, GitHub Copilot CLI, Kimi, Cursor, Antigravity, OpenCode Go or Z.AI Coding Plan usage limit is reached) https://agentsroom.dev/features/usage-limit-alerts Usage alerts warn you BEFORE a usage limit, which is the opposite end of the same quota window from Account Auto-Switch (what happens once the limit is reached). The Usage panel in the footer of the desktop app already lists every quota bar each AI coding CLI publishes, for every signed-in account: Claude Code (current session, current week for all models, current week per model), Codex CLI (5-hour window, weekly window, and each limit group), Grok Build (weekly or monthly, each signed-in account read with its own session), GitHub Copilot CLI (monthly premium allowance of the active CLI account), Kimi Code (5 hours, 7 days, monthly), Cursor (billing cycle: included usage, Auto and API pools), Antigravity (5 hours and weekly, per model pool: Gemini, then Claude and GPT), OpenCode Go (5 hours, weekly, monthly) and the Z.AI Coding Plan (5 hours, weekly). Every bar now has a bell. When a bar crosses a threshold, AgentsRoom sends a native desktop notification on macOS, Windows and Linux, a push to the AgentsRoom mobile app on iOS and Android, or both, according to three separate switches (an in-app card, the native banner, the phone push). Defaults: 50%, 75% and then 90% of every bar, ON from the first launch, no default at 100% because the CLI says it itself at that point. The other way round, since v1.190.0 a bar that had reached 90% or more and then resets is announced as "{provider} quota reset" ("You can code again: Current session is back to 3%") on the same three channels, with a short success sound; the switch "Tell me when a quota I had used up is reset" (Settings > Notifications > Usage alerts) is on by default, and a muted bar announces neither. Right-click a bell (long press and keyboard work too) to give that bar its own thresholds (25, 50, 75, 90, 100%, plus the default values) or to mute it; left-click mutes and unmutes. Settings, under Notifications, "Usage alerts": master switch, default thresholds picked from the same chips (25, 50, 75, 90, 100%, at least one stays on), desktop channel on/off, phone channel on/off, and a count of the bars that have their own thresholds with a "Reset them" button. The notification title names the provider ("Claude · AgentsRoom") and adds the account name as soon as that provider has more than one signed-in account; the body names the bar, the percentage, the threshold that fired and the reset time ("Current week (all models) is at 76% (alert set at 75%). Resets Sep 24, 04:00"). Anti-spam by construction: a threshold is announced ONCE per quota window, what was announced is remembered on disk (so 80% at every refresh is one banner, not one every ten minutes, and a restart does not re-announce), a bar that jumps over several thresholds at once produces one notification for the highest, and the thresholds are rearmed when the provider publishes a new reset time or when a threshold is removed and put back (only a bar with no reset time is also rearmed once the percentage drops about ten points below the threshold). The rule is attached to what the bar IS (provider, account slot, time window, model or limit group), never to its label, so a CLI renaming its bar does not silently reset the rule to the defaults, and a new model is a new bar with its own rule. On the phone, tapping the push opens the Usage tab of Activity, which mirrors the same bars; the bells and thresholds are set on the desktop only. Thresholds are machine-local settings, not synced to the account. The desktop app must be running (the bars are polled by it), but the Usage panel does not have to be open. Not an email, not Slack, not a webhook: desktop banner and phone push only. The same Usage panel also hosts Quota kick-off, a card right under Quota management: the countdown of a 5-hour session or a 7-day weekly limit only starts with your first message and refills a fixed time after it, so the card sends that one message for you, earlier. One short line, to the cheapest model that draws from that quota (Haiku for a Claude session), through the account's own CLI, in the background, with no agent, no tab and no terminal, and Claude and Codex keep no conversation of it. Per quota, two modes: Back to back (the quota restarts the moment it refills; the next week starts when the previous one ends) or At set times (days and times, 07:00 on weekdays for example; nothing is sent if the window is already running, and clicking a session lane's timetable drops a kick-off at that hour). Kicked off at 07:00, a session you start at 09:00 refills at 12:00 instead of 14:00. Covered: the 5-hour sessions and the weekly limits of Claude, Codex and Antigravity. A weekly limit on Back to back is kicked off the moment it refills, even at night, so the next week and a fresh 5-hour session start without you; while a weekly limit is used up, the session kick-offs wait for its refill instead of failing, and the timetable shows the wait. Grok, Kimi, Cursor, Copilot, OpenCode Go and Z.AI are not listed, their periods are fixed or rolling. With several accounts, each account's quotas have their own setting and the message goes through that account's CLI. A kick-off fires while AgentsRoom is open; one missed while the computer slept or the app was closed leaves at the next opportunity if it is less than 6 hours late, and the wake setting used by Scheduled Tasks (Wake the machine for scheduled triggers) also wakes the machine to hold the exact time. A kick-off is one message and no agent: to run a real session on the rhythm of a window, that is Scheduled Tasks (https://agentsroom.dev/features/scheduled-tasks), and to spend what is left before the reset, that is the Message Queue. **Video (1 min 11 s):** [Quota kick-off, shown in the real app](https://youtu.be/1NLtNobAWjo). The Quota kick-off card of the Usage panel is set to At set times on the Claude session, weekdays at 07:00; the timetable shows the kick-off pin and the refill it brings at 12:00 instead of 14:00, and Kick off now sends one line to Haiku through the account's own CLI and answers Kicked off a few seconds later, with no agent and no tab. Keywords: claude code usage limit alert, claude usage limit notification, claude weekly limit warning, claude code approaching usage limit, notify me before claude limit, claude code 5 hour limit alert, codex rate limit alert, codex usage limit notification, grok build weekly limit alert, kimi code usage alert, cursor usage limit alert, antigravity quota alert, quota threshold notification on phone, claude quota reset notification, know when claude usage limit resets, quota kick-off, start claude code 5 hour window early, claude code session reset time, warm up claude session, codex weekly limit reset, start quota window automatically, claude quota refills sooner, kick off claude session before working. ### Use Claude Code and Codex together: quota rules (alternate providers, or block, redirect, downgrade or move agents when a quota bar crosses a threshold) Rules synchronize through the AgentsRoom account by default, including existing rules. Desktop and mobile editors offer "Synchronize this rule with my other machines"; uncheck to keep one rule local. Subscription references are portable hashes, with no email or account directory sent. A missing account stays inactive. Independent edits merge per rule, and offline changes retry after reconnection. The rotation cursor stays local to each computer. “Ignore quota rules” is off by default. Enable it for an agent, flash agent, trigger or team to retain its chosen provider, model and account. The composer banner can exempt the agent on its next launch. Provider limits still apply. https://agentsroom.dev/features/claude-codex-together Since 2026-10-06 a quota rule can share NEW agents between several providers or several accounts in turn, with the action "Alternate providers" (no threshold). The rotation has 2 to 6 rows, each a provider, optionally one of its signed-in accounts ("Usual account" by default), and a model ("Agent's model" keeps the model the agent would have started with, from its settings, the ticket or the project; "Default model" is the chosen CLI's default) and reasoning effort. Two modes: "Number of launches" (each row takes 1 to 20 launches in a row, then hands over: Claude x1 then Codex x1 is one ticket out of two on each, Claude x2 then Codex x1 is two for one; it works for any enabled provider since it counts launches) and "Quota used" (each row keeps the launches until its own session or weekly gauge has moved by its share, 1 to 100 points, for example 10% of the Claude session then 10% of the Codex week; a gauge reset also ends the turn; a plan that publishes no session window, like some Codex plans with only a weekly limit, is measured on its week). Two Claude accounts can be alternated the same way (Claude twice, a different account per row, each read on its own gauge). Scope: every launch, backlog tickets, scheduled agents, webhook calls or manual launches, one project or all projects. Guarantees: an agent already running never changes tool, and a restarted or resumed agent comes back on the provider the rotation gave it, with its conversation, without counting a new turn; nothing is written on the agent's saved settings; a row at 99% or more skips its turn and when every row is full launches go through unchanged; no notification per launch, one line in the agent's terminal and "Next launch: Codex" on the rule card. The rotation goes through the same ordered list as the other rules (a threshold rule placed higher wins). The position of the rotation is kept on the computer that runs the rule. Template "Alternate providers" creates Claude x1 then Codex x1. Since v1.188.0 (2026-09-23) the Usage panel in the footer of the desktop app hosts a "Quota management" card: quota rules. Since v1.192.0 (2026-09-25) the panel is laid out in two columns, the quota bars of every CLI on the left and the actions on the right (Manage your usage: Temporary launch override, Quota management, Quota kick-off; then Insights into your usage: the average share of the weekly limit one full session costs, yours and other users' per plan, with More info opening Robin Hood, and the split for this project and this agent; then Optimize your usage). A new rule watches any quota bar by default, or one selected time window (the bars each CLI publishes: Claude Code session and weekly windows, Codex 5-hour and weekly windows, Grok Build weekly or monthly, GitHub Copilot CLI monthly premium allowance, Kimi Code, Cursor, Antigravity, OpenCode Go and the Z.AI Coding Plan) and acts on its own when the bar crosses a threshold. Threshold actions: block a launch (every launch, scheduled agents only, webhook calls only, or manual launches only; a blocked launch prints a red line in the terminal, a blocked scheduled run or team run is cancelled with a notification naming the rule, never left hanging), redirect a launch to another signed-in account of the same provider, change the provider, model or reasoning effort of new launches temporarily (this is how a cascade is written: Claude at 99% launches on Codex, Codex at 99% launches on Z.ai; with Claude and Codex both full a new Claude agent starts on Z.ai, a block on the last provider of the chain blocks the launch; an agent already running never changes CLI), run one of your existing triggers once per window, move the agents already running to another account (the account auto-switch above), and warn me (kept for older rules; notifications now belong to Usage alerts). Five templates: Use another provider (Claude at 99% on any gauge launches new agents on Codex), Use a lighter model, Use another account, Run a recovery trigger, Alternate providers (Claude x1 then Codex x1); a blank rule exposes every action, including Block a launch and Move running agents. A condition names the provider, the account (a given one, the CLI's own home, or "Most constrained": whichever account is closest to the wall), optionally one model group when the provider publishes a separate quota per group of models (Antigravity: "Gemini Models" and "Claude and GPT models", each with a 5-hour and a weekly bar; a model's own weekly bar on Claude Code; a model family on Codex; Auto or API usage on Cursor), the window (any gauge, session, day, week, month), a comparator (reaches / drops under), a threshold, optionally "only near the reset" (fire in the last N minutes of the window) and a second condition on another window ("20% left means little if the week is at 95%"). Rules apply in the order you set (drag to reorder, a priority badge on each row): at launch the first satisfied rule wins. Each rule fires once per selected gauge and re-arms at its next reset. A rule only blocks the launches of the provider it watches: "Claude full" never stops Codex launches. Since 2026-09-29 a launch action (block, redirect, change model) only touches, by default, the launches whose model draws from the gauge that reached the threshold: with the Antigravity "Claude and GPT models" pool at 100% and "Gemini Models" at 0%, agents on a Gemini model keep starting on Antigravity and only the Claude or GPT ones fall back, each group with its own rule and its own fallback; "All models" keeps the older provider-wide behaviour. Since 2026-09-29 as well, "Change provider, model or effort" can pick the target "By source model": one row per model family of the watched provider (Fable, Opus, Sonnet, Haiku), each with its own target model and reasoning effort on the fallback provider, plus an "Other models" default row; the table is pre-filled by capability tier so Fable lands on GPT-6 Astra, Opus on GPT-6 Sol and Sonnet on GPT-6 Luna, a row set to "Do not redirect" keeps that model on its provider, and "Same model for all" is the previous single-target behaviour (reported by a user who over-spent on light agents and under-powered heavy ones). A manual account pin on an agent always wins over a rule. Rules run while AgentsRoom is open. Their configuration synchronizes through the same AgentsRoom account by default; uncheck "Synchronize this rule with my other machines" to keep a rule local. A specific AI account must also be signed in on the other computer, and each machine keeps its own rotation position. Cursor and Antigravity can be watched, with one gauge for the whole machine rather than one per account. The phone edits rules (Activity > Usage > Quota management), rotation included, the desktop executes them; an agent launched directly from the phone does not go through the launch actions. Agents manage rules over MCP (quota_rules_list, quota_rules_save, quota_rules_delete, usage_overview). Keywords: use claude code and codex together, alternate claude and codex, one ticket out of two on codex, share quota between claude and codex, combine two claude accounts, alternate two claude accounts, stop scheduled agents when claude quota is full, antigravity gemini and claude quota pools, claude code quota rule, switch to codex when claude usage limit reached, cheaper model when quota is high, block agent launch on usage limit, quota automation for coding agents. **Video (1 min 17 s)**: Filmed in the real app on two independent installations using the same AgentsRoom account: save a rule that starts new agents on Codex when Claude reaches 99%, retrieve it on the second installation, then change the threshold to 90% and see the update on the first. The video shows rule configuration and synchronization, without launching an agent. Watch: https://youtu.be/BOUCdEYcKyA ### Restore Agents and Terminals https://agentsroom.dev/features/restore-session On quit, AgentsRoom can save a snapshot of your session and restore agents and terminals on the next launch. Reopens every AI agent (Claude, Codex, GitHub Copilot CLI, Cursor and 12 other agent CLIs), every dev command tab and every working directory where you left them. Since v1.190.0 a restored command tab comes back idle and waits for a click on Start; the opt-in "Restore commands on launch" (Commands window of the project, or Settings > Dev tools for every project; off by default) re-runs only the commands that were still running at quit, such as a dev server, and leaves a finished test suite or one-shot script idle. Pick up where you left off the next morning in a single click, with zero config. Everything that can start an agent by itself is governed by one master switch, so auto-launch at startup is a deliberate choice rather than a surprise, and a restore overlay lets you skip or cancel the wave. Separately, an agent's past conversation is readable at any time: a chat-style history modal replays the CLI transcript turn by turn with rendered Markdown, clickable file paths and the attachments of the conversation, which matters because a terminal only keeps what fits in its scrollback. Since v1.205.0, when the restore at launch left some of a project's tabs closed (agents not set to start at launch, a project shown in its own window, a remote server that was not reachable yet), the project says how many sessions from last time were not reopened and offers Restore, also reachable as Restore previous sessions in the project's menu: each agent reopens, with its previous conversation when its provider supports session resume. Resume agents after an update (Settings > Global settings, under Start agents automatically at launch, off by default, since v1.223.0): after Restart to update, every restored agent with session-resume support picks up its conversation on its own instead of waiting behind a Resume card; after a normal quit the card is still offered, and agents set to never resume (app, project or agent) still start fresh. Command Code and Muse Code agents can reopen, but automatic continuation of their previous CLI conversation is not yet integrated in AgentsRoom. ### Claude Code Token Usage (per-session token meter) https://agentsroom.dev/features/claude-code-token-usage Per-session Claude Code token usage tracker built into every agent terminal. Live token counter in the agent header, next to the model, with the live context-window percentage when the CLI reports it; the badge turns orange at 60% of the context window and red at 85% (the running total never colors it: it is mostly cache reads), click-to-open session monitor with input tokens, output tokens, cache reads, cache writes, cache hit rate, message count, tool uses, models routed and ready-made tips to lower your Claude Code token usage. Reads ~/.claude/projects/ JSONL transcripts directly, no proxy on the API. The same per-session meter exists for Codex (read from the rollout files under the CODEX_HOME AgentsRoom generates per project) and, since v1.184.0, for OpenCode (tokens and cost pushed by the plugin AgentsRoom installs in OpenCode, the figures its own TUI prints, non-zero on the flat-rate OpenCode Go plan); Antigravity, Grok Build, Mistral Vibe, Cursor and Aider sessions show no token badge. The same footer surface now aggregates quota and usage for every provider that reports it, not only Claude: Codex and Grok across several signed-in accounts, GitHub Copilot CLI’s monthly premium allowance, Kimi, Cursor and Antigravity included, each with its own session, daily, weekly and monthly window. The panel groups by provider with sticky headers and a collapsible account header, so a developer holding many subscriptions can still reach the per-provider refresh buttons. A provider only ever publishes one percentage per account and per window, never a breakdown, so the same panel derives one: it splits that percentage across the open projects and the individual agents, weighting each session by what its tokens would cost at API rates, and shows the share of the current session window and of the current week for the project you are in and for the agent you are talking to. The figures are estimates and are labelled as such: usage from another machine or from the web is outside the denominator, and on a subscription the dollar amount is only the weight used to split the plan, never an invoice. Weekly and monthly quota bars carry a pace marker: the share of the quota you would have used by now spending evenly, next to what you actually used, with a status when you run ahead and a flag when unused budget expires at the reset; the pace card adds consumption day by day, work days can be set so only those count, and the same reading reaches the phone and the usage_overview MCP tool. When an account also has a 5-hour limit, AgentsRoom counts the 5-hour windows left before the weekly reset (work days, nights or not) against the full sessions the rest of the week needs, and can warn before part of the week can no longer be used. ### Session trace (what filled the context, turn by turn) https://agentsroom.dev/features/claude-code-token-usage#session-trace The token meter says how much a session used; the session trace says where it went. It replays one agent session turn by turn from the transcript the CLI writes on the computer: the prompt, every model request, every tool call with what it acted on, the bytes that came back into the context and the context they added, its duration and its errors, plus the context the CLI injected on its own (CLAUDE.md and AGENTS.md, hook output, system reminders, skill bodies). Two charts on the same time axis: the size of the context window after each request (with the window limit, so a compaction reads as a drop) and the running total of tokens billed; clicking a point opens its turn. "What filled the context" ranks every source of the session by the context it added (a tool, a skill, an MCP tool, a sub-agent, the prompts, the agent's own output, the starting context): the answer to which skill or tool to refactor. "Biggest single additions" lists the twelve heaviest one-off additions (a whole file read, a long command output, a screenshot, a skill body): where a context leaks. On Claude Code, the spend of each sub-agent in its own window is attached to the call that started it (Codex sub-agents are not attached yet), and turns can be filtered by prompt, tool, file or skill. Context added is the growth of the context between two requests, read from the usage the provider bills (not an estimate) and shared by size between what entered it. Claude Code and Codex are traced in tokens; Antigravity in bytes (its CLI records no token usage); other CLIs are not covered yet. Where: the token badge of an agent opens Session info, where a foldable Session trace section sits right under the context window gauge (folded, it shows one line of key figures: turns, requests, peak context, data into the context, sub-agents, compactions; the choice is remembered; an icon opens the full view), and the conversation view has a trace icon. Read locally, nothing is sent; it refreshes every 10 seconds while open. Not on the mobile app. Keywords: claude code context window filling up, why does my claude code context fill up so fast, which tool or skill eats my context, claude code context leak, tokens per turn claude code, tokens per tool call, claude code sub-agent token cost, codex context usage per turn, session trace, replay an agent session. ### Localhost Tunnel (Live Preview) https://agentsroom.dev/features/localhost-tunnel Built-in localhost tunnel that exposes any local dev server as a public HTTPS URL. Choose a custom subdomain (e.g. my-app.preview.agentsroom.dev), and share your work-in-progress with anyone, instantly, without deploying. Supports WebSocket passthrough for Vite HMR, Next.js hot reload, and Expo Metro bundler. ### AgentsRoom MCP (agent-pilotable IDE) https://agentsroom.dev/features/agentsroom-mcp Four MCP servers (Backlog MCP, Terminal Commands MCP, Prompt Library MCP, Browser MCP) that expose the AgentsRoom IDE itself to Claude Code, Codex CLI, GitHub Copilot CLI, Antigravity CLI, OpenCode, Aider, Grok Build, Mistral Vibe, Kimi Code, Amp, oh-my-pi, Freebuff, Devin, Cursor, Command Code and Muse Code. Agents can read and update the project backlog (and reply to public backlog tickets), list, run, read and stop saved dev commands (and create new ones in the Terminal Commands list; commands_close closes completed terminal tabs and refuses executing or unknown-state commands; completed commands rerun in their existing tab without manual cleanup; commands_stop interrupts a command or closes its terminal tab, so an agent cleans up after itself), ask a human to run the one command their own sandbox refused (commands_propose: instead of printing the line for you to paste into another terminal, the agent sends it with the reason it cannot run it, the line shows up as a Run this command? card with Play and Reject buttons in that agent's own pane, and Play runs it once in a real terminal tab the agent then reads back with commands_output; the tool executes nothing by itself, the human decides every time, there is no always allow option, and the command is neither saved nor replayed), reuse or save prompts to the Prompt Library, and drive the embedded browser to test their own work. The same app server also exposes the connections and credentials you saved in AgentsRoom, which is what makes it a command center for your servers and your data and not only for your code: ssh_list, ssh_exec, ssh_transfer, ssh_connect and ssh_connection_new (list saved SSH, AWS SSM and WinRM connections, run ONE command on a machine and get its output back, move ONE file to or from it, open one as a visible terminal tab, propose a machine that is not saved yet, or save, update and delete connections outright unless the user turned off the Agents can manage connections setting, which is on by default (ssh_connection_save, db_connection_save and the two *_connection_delete tools: the credential is never a value, the agent names a vault secret and the desktop copies it); on a WinRM host the command is a PowerShell line, read-only unless the connection's owner allows writes, and writes are confirmed by the user in the agent's pane, on the desktop or from the iOS and Android app: every one of them, only the risky ones, or none, as the owner chooses per connection), db_list, db_schema, db_query and db_connection_new (list saved MySQL, PostgreSQL and MongoDB connections, explore a schema without writing a query, run ONE read-only statement with a capped result set, propose a new connection), and secrets_list (the NAMES of the stored secrets). The same server also carries agent to agent messaging, so the agents of a project can write to each other rather than only to you: agents_list_live, agents_send, agents_message_status, agents_read_inbox, agents_reply, agents_ack and agents_report_status, with messages persisted before delivery, delivery receipts the sender can read back, and a sender the server stamps itself (see the Agent Messaging entry). An agent running a context checkpoint (handoff) routine can also start its own console over on a fresh conversation with agents_restart: once its turn ends, the same agent restarts in the same tab with the first message it wrote, the equivalent of typing /clear then resume with nobody at the keyboard (its own console only, at most one restart every 2 minutes and 6 per hour). The same server also reads and steers the account's quotas: usage_overview returns every quota bar of the Usage panel for each signed-in account, with its reset time and, on weekly and monthly bars, the pace (what may be spent by now against what is spent, days off taken into account), so an agent can check the headroom before a long task or send work to the provider with the most room left; quota_rules_list, quota_rules_save and quota_rules_delete read, create, edit, reorder and delete quota rules one at a time (rules are app-wide and the order of the list is the priority), and the tools tell the agent to check with the user before it adds a rule that blocks or redirects launches and before it deletes one (see the Quota rules entry for what a rule does). What an agent structurally cannot do is enforced in code rather than promised in a prompt: no tool ever returns a password, a passphrase, a private key or a secret value, since the desktop injects the credential itself; db_query refuses a write unless the connection is writable and the user turned on Allow agents to write for it (off by default), a check made in the desktop app because you do not need a password to run a DROP; and an agent saves a connection by itself unless the user turned the option off (Agents can manage connections, on by default): turned off, a proposal only pre-fills a creation form that the human reviews, completes and saves, because a connection an agent could register unseen would be a backdoor. The agent works with references, the app works with the secret. Every action keeps a manual UI path : MCP only adds the option to automate. Local-first, loopback-only bridge with a per-boot hex auth token. The unique edge that turns AgentsRoom from an IDE into an agent-controllable IDE. The same server also reaches the user's personal Todo list (todos_list, todos_add, todos_update, todos_delete): an agent or the personal assistant, by text or by voice from the phone, can read the list, add a task to Today, Tomorrow or Later, rename it, tick it or move it, and the change appears live on the desktop and in the mobile app; a personal task never becomes a backlog ticket that an agent could start. A small plug button in each agent's header shows whether its CLI actually loaded the AgentsRoom MCP servers, its status hooks and its skills, lists every loaded tool by name, and offers a restart when something is missing. An agent that starts a throwaway agent with agents_spawn can follow what it started: agents_spawned_list, agents_spawned_get and agents_spawned_wait report each run it launched (starting, working, done, waiting for input, exited, closed) with a short report and wait for it to settle, and agents_close closes it; an agent cannot close a run that another agent started. An agent can also delete saved agents on your instruction with agents_delete ("remove the old version of this agent from every project"), by id or by exact name, in one project or in every project open in the desktop: one confirmation card in its pane lists the whole batch and nothing is deleted before you approve, and an agent at work, running a team step or protected is never touched. The same cleanup exists without an agent in the app: Delete agents in all projects, in the agent list's tidy-up menu, lists every saved agent of your open projects grouped by name, with a one-click selection of duplicates. Shared AgentsRoom tool server (since 2026-10-19, on by default): instead of every agent CLI starting its own copy of each AgentsRoom MCP server (four or five Node.js processes per agent console, more than 300 processes for 80 consoles), ONE background process of the computer serves every console over local HTTP (127.0.0.1), each console authenticated by its own session token, about 1 MB per agent session. Used by Claude Code, GitHub Copilot CLI, Codex CLI, OpenCode and Grok Build (macOS, Linux); the other CLIs keep their own processes, and the setting (Settings > AI providers & accounts > Shared AgentsRoom tool server, overridable per project) switches back to one process per agent. ### Agent Delegation (Dev to QA test handoff) https://agentsroom.dev/features/agent-delegation Dev to QA agent delegation through a single MCP tool call. The dev agent (Claude Opus, Codex) calls run_qa_test on the AgentsRoom Test Runner MCP, an ephemeral QA agent spawns on a cheaper model (Claude Haiku, Codex mini, GPT-4 mini), runs the test via the Browser MCP, returns a pass or fail verdict and is destroyed. Token cost optimization, context isolation, cross-provider. Browser tests today, Electron tests via the AgentsRoom Electron MCP library, React Native tests on the roadmap. ### Project Statistics (time, prompts and cost per project) https://agentsroom.dev/features/project-statistics Per-project statistics for your AI coding agents: time, prompts, tokens and estimated model cost, plus cost per shipped ticket and factory efficiency. Filter by project, team and inclusive UTC dates; compare the preceding period and inspect included tickets and runs. A shipped ticket is currently Done, excluding Won't fix. Its attributable cost includes all recorded linked work, even outside the reporting period. Period spend separately includes unfinished and unassigned work. Zero shipments produce an unavailable ratio; missing prices and historical coverage are explicit. Cost observations sync to the account across computers; historical totals are not retrospectively assigned to tickets. Estimates are not subscription invoices. ### Sketch (draw and annotate, send visual feedback to AI agents) https://agentsroom.dev/features/sketch Sketch is a drawing canvas built into the AI agent composer. Open a blank canvas to sketch a mockup, a wireframe or a diagram, or open a screenshot to annotate it: circle a visual bug, draw an arrow, highlight a region, add text. The drawing is exported as a PNG and attached to the message sent to your AI coding agent (Claude Code, Codex), so the agent sees the problem instead of parsing a paragraph of description. Annotation is reachable from composer thumbnails and the file preview. Sketches stay local on your machine, the canvas never leaves the terminal, and it works with any provider whose model accepts an image input. **Video (1 min 11 s):** [Sketch, shown in the real app](https://youtu.be/nIcKEy0m_7s). A screenshot of a shop page is pasted into the message box, the pencil opens it in Sketch, the card whose Buy button spills out is circled with an arrow and two words, and the marked-up screenshot goes with a short message; the agent fixes that one button, a one-line change left in the Changes tab for review. ### Screenshot to Agent (capture a screen region and send it to your AI agents) https://agentsroom.dev/features/screenshot-to-agent Screenshot to Agent captures a region of your screen and attaches it straight into the AI agent composer. Two entry points run the same capture: a screenshot button in the composer, and a configurable global keyboard shortcut (Cmd+Option+Shift+P by default, Ctrl+Alt+Shift+P on Windows and Linux) that works from anywhere, even when AgentsRoom is in the background. It uses your operating system's native region picker (screencapture on macOS, the Snip overlay on Windows, grim, spectacle, gnome-screenshot, maim, scrot or flameshot on Linux), so the screenshot is auto-attached to the focused agent's message as a thumbnail with no external screenshot tool, no saving a PNG to disk and no dragging the file into the window. Captures are stored locally in your home folder and cleaned up automatically. The shortcut is fully customizable and can be disabled in settings. Provider-agnostic, it sends a plain PNG so any model that accepts image input (Claude Code, Codex) can read it. Desktop feature on macOS, Windows and Linux. The fastest way to give an AI coding agent visual context: capture a UI bug, a chart, a terminal output or a design reference and send it in one shortcut. ### Voice Dictation (dictate prompts to your AI agents) https://agentsroom.dev/features/voice-dictation Voice dictation built into the agent composer: dictate your prompts to your AI coding agents instead of typing them. Click the microphone button, speak, and the speech-to-text transcription is inserted into the draft at the caret, ready to review and send with Enter (nothing is sent automatically). On desktop, transcription runs server-side and the model is not a setting: it is picked from the length of the recording, an accurate default up to ninety seconds and a loop-resistant model (whisper-1) past it, because the accurate one has no repetition guard and starts looping on long or noisy audio. 21 spoken languages, including Czech and Slovak, plus automatic language detection, with a live voice waveform visualizer while recording. On desktop you can also switch on an offline fallback that runs a local Whisper model on your own machine, downloaded once, so dictation keeps working with no network and no credits. On mobile, speech recognition runs on-device so the audio never leaves the phone, and the recognized text is relayed end-to-end encrypted to the focused desktop agent. Dictating a long, precise prompt takes seconds instead of minutes: more context to the agent, fewer clarification round-trips and fewer wasted tokens. Provider-agnostic, works with Claude Code, Codex, GitHub Copilot CLI, Antigravity CLI, OpenCode, Aider, Grok Build, Mistral Vibe, Kimi Code, Amp, oh-my-pi, Freebuff, Devin, Cursor, Command Code and Muse Code. A built-in Whisper / speech-to-text dictation that targets the agent prompt directly, instead of a separate dictation app and copy-paste. Since v1.223.0 the same microphone also sits next to the answer field of an agent's question card (Structured Questions), on the desktop and in the mobile app: the transcript is added to the answer, and nothing is sent until you press Enter or Send. ### Voice Mode (two-way voice conversation with your AI agents) https://agentsroom.dev/features/voice-mode Voice Mode is a two-way, hands-free voice conversation with a running AI coding agent. Tap once and speak; the agent answers out loud in a natural voice, so you stay in the loop without typing prompts or reading walls of terminal output. It runs in the desktop app on macOS, Windows and Linux. Turn on hands-free and it keeps listening for your next turn between replies. Ask where the refactor stands and it tells you; say run the tests and report back and it does, then speaks the result. Pick the reply voice (alloy and others), keep an optional beep cue between turns, set the pause tolerance so a thinking pause of 1 to 4 seconds does not end your turn before you are done, and let language auto-detect so you speak in your own words. Choose which microphone listens and which speaker or headset plays the replies (Voice Mode, dictation and Read Aloud) without changing the system default for other apps: a level meter and a test sound check them, the choice is kept per computer, and an unplugged device falls back to the system default. Voice Mode runs on the AgentsRoom backend (speech-to-text in, text-to-speech out) and draws from the same voice credits as dictation. The same voice and the same credits also power Read Aloud (https://agentsroom.dev/features/read-aloud), which reads WRITTEN text out loud instead of holding a conversation. Distinct from Voice Dictation, which only transcribes your speech into the composer one way; Voice Mode is a live spoken back-and-forth. Provider-agnostic, works the same with Claude Code, Codex, GitHub Copilot CLI, Antigravity CLI, OpenCode, Aider, Grok Build, Mistral Vibe, Kimi Code, Amp, oh-my-pi, Freebuff, Devin, Cursor, Command Code and Muse Code. Boundary with OpenAI's own voice for Codex (OpenAI documentation, checked on 11 October 2026): ChatGPT Voice, powered by GPT-Live, is a two-way spoken conversation on Codex tasks in the ChatGPT desktop app and through Codex on iOS paired with a desktop host, on the Plus, Pro, Business, Edu and Enterprise plans, one voice chat at a time; it directs Chat, Work and Codex tasks inside OpenAI's apps; the Codex CLI also has its own /voice, a spoken conversation on the current thread (codex-cli 0.162.1, checked on 13 October 2026), while AgentsRoom Voice Mode wraps the session of any of the 16 agent CLIs, Codex included. The most natural way to keep up with a long-running agent without being chained to the keyboard. ### Read Aloud (text to speech: listen to a document, a selection or your agent's answer) https://agentsroom.dev/features/read-aloud Read Aloud is a text-to-speech reader built into AgentsRoom: it reads written text out loud in a natural synthetic voice, so you can listen to a README, a changelog, a spec or an agent's answer instead of reading it on screen. Four entry points, one player: a speaker button in the markdown file preview (next to Source) reads the whole document, a Listen button in the terminal selection panel reads whatever you highlighted, a right-click entry in the terminal reads the agent's last answer pulled from its on-disk transcript, and a speaker on the AI summary or explanation bubble reads that result. Every entry point also offers a condensed read: an AI summary of the text is produced first and that summary is what gets spoken, sized to a spoken length you choose (roughly ten, thirty or sixty seconds, ten seconds by default and configurable in settings), which turns a forty-minute changelog into a ten-second answer. You buy seconds rather than words, which is also the unit you pay in since speech is billed per character. The text is cleaned before it is spoken, so code blocks, markdown tables, bare file paths, horizontal rules and markdown markers are dropped and you hear prose, not punctuation read out character by character. A read shows a progress bar, the remaining time, pause and resume, and a control chip in the status bar that stays available after the file preview is closed, so there is always a way to stop the voice. Text is split on sentence boundaries because the speech proxy caps a single call at 4096 characters, and a single read is capped at 12000 characters (about 13 minutes of speech): past that the read is truncated and the interface says so, so one click can never swallow a month of listening. A document is read in the language it is written in, so an English README stays English even when your interface is in French, while the condensed version is written in your interface language. It was built for a dyslexic user who was copy-pasting the AgentsRoom markdown preview into a separate text-to-speech tool: the accessibility angle is real, and so is the eye-strain one, but this is not a screen reader and not an accessibility certification. Read Aloud is metered in listening minutes rather than in credits: none on Free, 30 minutes a month on Plus, 2 hours on Pro, with a dedicated row in the Free/Plus/Pro comparison table. Inside the allowance a read costs nothing; past it, reads fall back on the same voice credits as Voice Mode and dictation, and you can attach your own OpenAI API key to run them on your account. Reading a document, a selection or an AI summary works with every provider; reading the agent's last answer needs an addressable transcript, which today means Claude Code, Codex, Grok Build, Mistral Vibe, oh-my-pi and Antigravity CLI, and other providers simply report that there is nothing to read. ### Mobile Companion (dictate, attach files and share screenshots from your phone to your AI agent) https://agentsroom.dev/features/mobile-companion The Mobile Companion lets you dictate prompts and attach files from your phone to the focused desktop agent's composer. Sharing screenshots or photos to AgentsRoom from the iOS or Android system share sheet opens a destination screen above any existing agent console: choose the project, with the currently open project preselected, then choose an agent or the backlog. Add optional instructions and send; a closed agent starts automatically using the same startup and delivery services as the desktop. Agent photos travel over the end-to-end encrypted relay, with images resized and compressed first. Backlog tasks and photos are saved in the user's account through the existing task and image endpoints and work without a connected desktop, provided the phone has Internet access. The personal assistant remains an explicit destination when available. Photos remain on the screen after a failed send; a partial backlog upload resumes on the same task. Other shared files keep the Companion queue to the focused composer. Provider-agnostic, with iOS and Android phones and macOS, Windows and Linux desktops. After a screenshot of AgentsRoom on the phone, the app keeps its own copy in a pile at the bottom right, clear of the system screenshot thumbnail (Settings, Screenshots, on by default, iOS and Android 14+): one tap opens Report a bug, which files a ticket on the AgentsRoom public board with the screenshots kept private (the reporter follows the answer in Your feedback), Save to my phone and Share. Nothing leaves the phone unless you send it. The report form lets the reporter pick Bug or Idea and annotate a screenshot with a finger before sending. On the desktop, the Bug button of the footer (left of the version number) captures the AgentsRoom window, lets you drag a frame around the area that matters (the framed area and the whole window are both attached; Enter keeps the whole window only), and opens the same form: one message field whose first sentence becomes the ticket title, with dictation, and screenshots that can be annotated or removed. On the desktop more pictures can be added from the form: a screen area, the AgentsRoom window, or a pasted, dropped or picked image. On the phone, Add an image picks pictures from the photo library, including in a report opened by a shake. The Bug or idea tile of the desktop Help bubble opens the same form, and the form links to the public backlog. On iOS and Android, shaking the phone firmly while AgentsRoom is in the foreground opens the same report form without taking or attaching a screenshot. Any existing screenshot pile is preserved. Shake to report a bug is on by default and can be turned off in Settings > Help > Report a bug; this preference is synced to the account. It requires a native app build with accelerometer support. The sensor stops in the background, when the screen is locked, or while a report is open. A report can also be kept as a private draft instead of being sent: Save as draft in the same form, on the desktop and on the phone, stores the text and its screenshots in the account, visible to the author only. Drafts are listed at the top of Your feedback on every device, reopen in the form to be refined, saved again, sent or deleted. Signed-in visitors of a public board portal get the same drafts, under Your drafts. A draft edited on two devices at once is never overwritten silently: the second save offers to keep its version or load the other one. ### Personal assistant (one AI agent for your whole account, one sentence away from your phone) Codex service tier: Settings > Agents & AI > Assistant offers an assistant-specific Standard, Fast or Ultrafast override, or inherits existing Codex settings. The effective next-launch tier is shown; Ultrafast requires support from the selected account and model. The preference follows the account across computers; mobile uses the same desktop service. https://agentsroom.dev/features/assistant The personal assistant is the one agent of an AgentsRoom account reachable from the phone in a single sentence, without opening a project or picking an agent. It is called "Personal assistant" by default (in the interface language) and can be renamed; the visible label is "Assistant" (title bar button on the desktop, Assistant tab in the middle of the phone's tab bar, Settings > Assistant). Say "Talk to Bot in AgentsRoom" to Siri (fixed English App Shortcut phrase), press the iPhone Action button or a Back Tap bound to that shortcut, long press the app icon ("Talk to the assistant" / "Write to the assistant"), tap the Android home-screen widget or the "Personal assistant" Quick Settings tile, use the iOS 18 Talk to Bot control from Control Center, the lock screen or the Action button, tap the Assistant tab, or share a text from any app and pick "Send to Personal assistant": every entry point opens the deep link agentsroom://bot, the assistant's screen with the microphone already listening. The AgentsRoom speech-to-text transcribes it into the composer (Siri never dictates: the quality is the app's), the user checks or edits the transcript and sends it, then the text travels over the end-to-end encrypted relay to the desktop. There, the assistant runs through the user's own agent CLI, provider-agnostic, like any other agent: it inherits the account's MCP connectors (mail, calendar, messaging, documents) and the cross-project AgentsRoom tools, so it lists projects, reads and files backlog tickets in any of them, launches or resumes an agent there ("handle the last bug of project X"), hands a task to one of its agent teams with the brief already written (the user approves the run on a card, on the desktop or the phone, and the assistant is told when the run stops), drafts replies in the user's voice, and confirms before anything irreversible or visible to a third party. It starts a fresh conversation every day and, if the user allows it, keeps a private memory of its own, separate from the account memory the project agents read: one dossier per subject (a building's management board, investments, a running plan), contacts, a dated journal of requests (dates set by the server, not guessed by the model) and previous versions of every note to undo a change. Photos are kept with the notes: share one from the phone ("Send to Personal assistant" in the share sheet) or drop it on the assistant panel on the desktop, and the assistant files it in the right dossier, a recipe photo next to the recipe, then shows it back when asked; images are compressed, cleared of their location data, encrypted like the notes and bounded by a storage quota that depends on the plan, and the Markdown export becomes a zip with an images folder. At first use it asks what to keep: Nothing, Ask me first or Automatic, changeable at any time in its settings on the desktop and the phone; the whole memory exports as Markdown or JSON and can be erased in one click. The memory is encrypted at rest on the AgentsRoom servers with a per-account key, synced across the user's computers and phone, never readable by project agents, and refuses passwords, tokens and card numbers; notes the assistant reads are sent to the user's model provider like the rest of the conversation. The answer comes back as a push notification (tap to open the conversation, or read aloud); when a task longer than a minute ends, the desktop says the user's first name and the summary out loud. Custom avatar, one settings page on the desktop and on the phone (enable, provider, model and the account of that provider the assistant runs on, launch agents without confirmation, first-name announcement, new conversation). On the desktop the assistant panel, like the chat, can be detached into its own window from its header. When the desktop is unreachable the phone says so before recording anything; a text shared from another app is kept on the phone and sent as soon as the desktop is back; there is no server-side queue and no cloud execution. Keywords: voice assistant for developers, personal AI assistant, talk to your AI agent from your phone, Siri shortcut AI agent, Action button AI assistant, voice command AI coding agent, global AI assistant, AI assistant with memory, AI assistant private memory, AI assistant that remembers you, AI assistant that keeps photos, personal AI memory per subject, MCP connectors assistant, end-to-end encrypted AI assistant, AgentsRoom personal assistant. **Video (1 min):** [The personal assistant's private memory, shown in the real app](https://youtu.be/Wb0dfj7F0m4). Told once about a half marathon (date, goal, coach), the assistant files a Running dossier and a contact card on its own, and in a brand-new conversation it still answers with the race date and the coach to call. The assistant can have specialists (a running coach, a wealth advisor...): each is a tab of its own in the assistant panel on the desktop and the phone, with standing instructions written once like a CLAUDE.md (applied from the first message of every conversation, updated by the specialist itself when the user gives a new rule) and a dossier of its own in the private memory. **Video (1 min 18 s):** [A specialist created in the real app, with its own tab](https://youtu.be/GZwlRZTb7e8). One click on New specialist, a Running coach with its purpose and standing instructions written once, its own tab next to the assistant, and an answer to a run report that follows the rules it was given and files the week plan in its own dossier. A folder of Markdown notes, such as a git repository used as a memory, can be imported into a specialist's dossier, its CLAUDE.md or AGENTS.md becoming the instructions. A trigger (schedule or webhook) can hand its prompt to the assistant or to one specialist instead of starting a new agent. Such a trigger can also be global: created from the Triggers button of the assistant panel (or Settings, Assistant, Global triggers on the phone), it belongs to the account rather than to a project, keeps one list and one webhook URL across every machine and the phone, and always goes to the assistant or a specialist (a sync job that imports a run pings the running coach whatever project is open). The assistant and its specialists work as one team: when a request falls in a specialist's field, the assistant offers to hand it over and, on a yes, the brief lands in that specialist's tab and the result comes back; with the user's agreement the assistant also creates a new specialist. Each one reads the other dossiers of the shared private memory before advising (a key running session on Thursday becomes advice to skip drinks and sleep early on Wednesday, a tight budget one more reason), prefers reading to messaging, and messages between assistants are capped per hour. When it creates a specialist, the assistant searches the whole agent catalog (built-in roles, The Agency, community agents and the user's own agents) to give it an expert's know-how and face; when nothing fits it can create a new custom agent in the user's account and, if the user asks, submit it to the community, where it goes through moderation like any other. It also relays the agents' question cards: asked "what are my agents asking me?", it reads the open questions of every project with their options, and passes on only the answer the user explicitly gives it, never picking the recommended option on its own. ### SSH Connections (run AI agents on a remote server over SSH) https://agentsroom.dev/features/ssh-connections AgentsRoom is an SSH connection manager and a built-in SSH terminal in one. Save the SSH connections to your VPS and remote servers once, connect with an SSH key or a password, then run Claude Code, Codex or Antigravity CLI straight on the remote machine without a separate SSH client. The servers you already reach from a terminal come in as they are: AgentsRoom imports the host blocks of ~/.ssh/config, keeps the identity file each block declares, and preserves a ProxyJump through a bastion because it connects through the alias and lets OpenSSH resolve the block instead of reimplementing it. Instances with no public address and no inbound SSH port are reachable through an AWS SSM connection, opened with aws ssm start-session and authorized by the AWS profile already configured on the machine, so there is no password and no key to store in the app. Connection profiles can be scoped per project, so a project that lives on a remote box always opens its terminal over the right SSH connection. A project does not need a local clone at all: the New project dialog asks whether the project lives on this computer or on a remote server over SSH, and in the second case you pick a saved connection and the path of the repository on the host; the project opens from there, its agents start on the server in that directory, and nothing is copied to the laptop. Every saved connection also carries an Open a project on this server button, and a project of the account that has no folder on the current machine can be opened on a server the same way. Role, persona, system prompt, permission mode, skills, status tracking and the Codex account chosen for the agent travel with the agent (the account is copied to the host before the launch, a per-connection setting you can turn off); the AgentsRoom MCP tools travel too since v1.180.0: the backlog, project memory, skills, dev commands and agent mail servers are installed on the host before each launch (one bundle under ~/.agentsroom/mcp on the host, a .mcp.json written in the remote project and gitignored) and wired back to the desktop through a reverse SSH tunnel, a per-connection checkbox on by default that needs Node on the host; a CLI missing on the host is detected from the host's own shell and installed on the host over SSH from the banner of the agent terminal, instead of on the laptop; since v1.198.0 the agent menus and the agent form of a project opened on a server list the CLIs installed on that server (a CLI the laptop does not have is offered, one missing on the server sits under Not installed on ), so nothing has to be installed locally to launch an agent remotely; and a per-connection option, Keep agents running on this host when AgentsRoom closes (off by default, needs tmux 3.0 or later on the host), runs each agent inside a tmux session on the server, so quitting AgentsRoom, a sleeping laptop or a network drop no longer stops it and the next launch of the agent, from this computer, another computer of the account or the phone, reattaches to it (closing or restarting the agent still stops it; without the option the agent stops when the SSH session closes); a team run works on a project opened on a server, its team tools reaching the run through the same tunnel; and a Codex agent that hits its usage limit on the host switches account and resumes the same conversation there. A backlog ticket that asks for a separate git worktree gets it on the server too, under the remote checkout, and its agent starts there. A connection can also be tied to a client folder (Servers, connection form, Client folder of this host, none by default): every project opened on that host is filed in that folder and inherits what the folder sets (CLI and accounts, CLI options, the Quick, QA and Backlog agents, teams), on every computer of the account; the folder's environment variables and its own MCP servers apply to local launches only, they are not sent to the host. Environment variables and the other providers' account profiles stay on the local machine, and the agent form says so while the project is offloaded. Windows servers are not a special case: OpenSSH has shipped with Windows Server since 2019, so a Windows box is saved like any other connection, and a remote shell option on the connection makes the terminal land on a PowerShell prompt (Windows PowerShell or PowerShell 7) instead of cmd.exe, with nothing to install locally and nothing to change on the server. That covers the terminal: a project opened on a Windows server, with agents launched there, is not supported yet because the remote mode expects a Linux or macOS shell on the host (the dialog says so instead of claiming the folder is missing); set WSL as the default shell of the server's OpenSSH service and it behaves like a Linux host. A Windows host that only speaks WinRM, or the PowerShell endpoint of an on-prem Exchange server, is saved as a WinRM connection instead: NTLM for a workgroup machine, Kerberos for a domain member, CredSSP for a second hop (a session that must in turn reach Active Directory or a file server, over HTTPS with a checked certificate), with the domain controller and the server IP entered by hand when the workstation is not joined to the domain, and no edit to the hosts file. It runs through one Python package (pypsrp) installed once in a private folder AgentsRoom owns; agents run PowerShell through it read-only by default, and the writes the connection's owner allows wait for their confirmation, every one of them, only the risky ones, or none, as they choose per connection. Run heavy builds, GPU jobs or long-running agents on a powerful server while you keep the same visual cockpit, status tracking and notifications on your laptop. Agents reach the same connections over MCP with five tools: ssh_list returns metadata only (name, host, port, user, auth type, scope), ssh_exec runs ONE command on a saved machine and hands back its output with the exit code (or, for network appliances whose command line only works inside an open session, such as a WatchGuard firewall or many switches and routers, opens that session, waits for the device prompt and types a list of commands one after the other), ssh_transfer moves ONE file to or from it over the same channel (a WinRM host included, with C:\ paths accepted) and returns a path on your disk rather than the file itself, ssh_connect opens a saved connection as a VISIBLE terminal tab you can read, type into and close, and ssh_connection_new proposes a machine that is not saved yet by pre-filling the creation form the human reviews and saves. Agents can manage connections is on by default: ssh_connection_save and ssh_connection_delete write and remove connections outright, and even then the credential never appears in the conversation: the agent names a vault secret and the desktop copies it. An agent never receives the password, the key passphrase or the private key: they stay encrypted in the OS keychain and the desktop injects the credential itself. Where connections live: the name, host, port and user of each connection follow the AgentsRoom account, so a server saved on one computer appears on the others; SSH keys and key paths stay on the machine; passwords and key passphrases stay encrypted in the keychain of the machine where they were typed, unless synced passwords is turned on in Settings > Account (off by default), in which case they follow the account end-to-end encrypted with a key only the user's computers hold, which AgentsRoom stores without being able to read (any password can still be kept on one machine only). Nothing is ever written into the project repo. Turning the setting off restores proposing as the only route, because a connection an agent could register unseen would be a backdoor. Provider-agnostic and built for developers who code against remote servers, VPS instances and cloud machines. Since v1.205.0, a remote project whose server does not answer, typically because a VPN such as Tailscale is not connected yet when AgentsRoom starts, says so at the top of its agent list (" is not answering") with a Retry button that checks the server first, then relaunches every agent waiting for it on its conversation; a server that does not answer is given up after 20 seconds per attempt instead of hanging. A Claude Code or oh-my-pi agent of a remote project also comes back on its conversation after a restart, like a local one; agents of the other CLIs on a remote project still start a new conversation after a restart. ### Secret Manager (API keys your AI agents can use but never read) https://agentsroom.dev/features/secret-manager The AgentsRoom secret manager stores API keys, tokens and passwords in a machine-local vault encrypted through the operating system keychain with Electron safeStorage: the encryption key belongs to the OS, not to AgentsRoom. The whole vault is a single file at ~/.agentsroom/secrets.json, written with owner-only permissions (0600) and replaced atomically, so a crash never leaves it half-written and no other user account on the machine can open it. If the machine cannot offer a working OS keychain, AgentsRoom refuses to store the secret rather than falling back to clear text. A saved secret is used by name: you write {{secret:NAME}} in a dev command or in the environment given to an agent, and the reference is resolved at launch, inside the Electron main process only, into the environment of the process being started. The asymmetry is the point: the vault is exposed over MCP by exactly one tool, secrets_list, which returns the NAMES of your secrets so an agent can discover what exists and reference one in something it is about to run, and there is no code path that returns a secret value to an agent, to the interface layer or over MCP. Machine-local by design, secrets are never synced to AgentsRoom servers, never backed up in a cloud and never relayed to the mobile app. That is what makes it reasonable to let an agent run a test suite against a real service, call a paid API or deploy to staging without a single credential entering its context, and it removes the usual accidents: a token pasted into a prompt, a key hardcoded into a script an agent wrote, a credential swept into a commit. Provider-agnostic, it works the same whichever agent CLI is running. ### Database Connections (MySQL, PostgreSQL and MongoDB for AI agents, read-only by default) https://agentsroom.dev/features/database-connections AgentsRoom manages MySQL, PostgreSQL and MongoDB connections the way a database client would (engine, host, port, user, database, TLS) and gives AI coding agents a way to query them without ever holding the password. A database that is not reachable from the open internet is not a special case: the connection can be routed through an SSH tunnel or an AWS SSM port-forwarding session, built from the SSH and SSM connections already saved in AgentsRoom, which is how you reach a database sitting in a private subnet without exposing it. GOOGLE CLOUD SQL (MySQL and PostgreSQL): instead of a tunnel, the connection can name a Cloud SQL instance (project:region:instance, typed or picked from the list the user's own gcloud login can see); AgentsRoom starts the Cloud SQL Auth Proxy (cloud-sql-proxy) on a loopback port when the connection opens, with the user's Application Default Credentials, and stores no key, with optional private IP (--private-ip) and IAM database authentication (--auto-iam-authn, no database password). When the proxy is not installed or the gcloud login has expired, the error says so and names the command to run (gcloud auth application-default login). The guardrails are on by default rather than optional. Every connection is READ-ONLY when created, so a SELECT runs and a statement that would change data does not; a write requires two separate deliberate acts: in the SQL console, making that specific connection writable AND confirming the operation explicitly; for an agent (since 2026-10-05), making the connection writable AND turning on "Allow agents to write" on it, off by default, after which the agent's writes run without a per-statement confirmation. Only one statement is accepted per call, so anything stacked behind a semicolon is refused rather than executed, and result sets are capped so a wide query cannot flood a window or an agent context. A connection can be flagged as production, which hardens the confirmation. Agents work through MCP with four tools, by naming a saved connection and never handling a credential: db_list returns the connections and their metadata, db_schema explores the schemas, tables and columns without writing any SQL, db_query runs ONE statement and returns capped rows, and db_connection_new proposes a database that is not saved yet by pre-filling the creation form the human reviews, completes with the password and saves; Agents can manage connections (on by default) additionally lets an agent save, update and delete connections outright (db_connection_save), the password being copied from a vault secret the agent only names rather than typed by anyone. Agent writes in db_query require a writable connection and the user's explicit Allow agents to write opt-in, disabled by default and synced with the connection. Once enabled, writes run immediately, so only enable this for agents trusted with that database. The desktop checks the permission in its main process. The password is never returned to the agent, never written into the query and never part of the conversation. ENGINE COVERAGE, stated plainly: MySQL and MariaDB, PostgreSQL, and MongoDB are supported, each with its own driver rather than a translation layer, directly or through an SSH or AWS SSM tunnel; SQL Server, Oracle, SQLite and the rest are NOT supported, and anyone who needs one of them is invited to request it on the public backlog at https://agentsroom.backlog.agentsroom.dev. CONNECTION SYNC: the connection METADATA (name, host, port, user, default database, scope, the read-only, agent-write and production flags, and the SSH or SSM tunnel it goes through) follows the user's account, so a connection saved on one machine appears on their other machines instead of being retyped; by default the PASSWORD stays encrypted in the keychain of the machine where it was typed, so a connection arriving from another machine is flagged as needing its password once. With SYNCED PASSWORDS on (opt-in, Settings > Account, two-factor authentication required on password accounts), SSH and database passwords also follow the account END-TO-END ENCRYPTED: sealed on the computer with a vault key only the user's computers hold (AES-256-GCM), stored by AgentsRoom without being readable, updated on every computer when changed on one, with a per-connection opt-out; a new computer gets the key from an already connected one (a code typed from one screen to the other) or from the recovery key. EXPORT, IMPORT AND COPY: a database can be exported to a file, a file can be imported back into a database, and one database can be copied straight onto another of the SAME engine, including through the saved SSH or SSM tunnels. These run each engine's own official tools (mysqldump and mysql, pg_dump and psql, mongodump and mongorestore), which ship with the database rather than with AgentsRoom; when they are not on the machine the app says so and lets the user point at the folder that holds them instead of failing with a spawn error. The password is passed to those tools through a 0600 options file, never on a command line where any process could read it. Importing is refused outright on a read-only connection, the target is dumped to a file of the user's choosing before anything is written to it, and dropping and recreating the target schema is a separate opt-in whose confirmation names the database. There is no MCP tool for any of this: an agent cannot export a database, because a dump it could then read would hand it every row while the query surface is capped at 200. The point is an agent that reads the real rows instead of inventing a schema, without the access turning into an incident. ### Kubernetes Clusters (GKE, EKS, AKS or any kubeconfig context, monitored in the app and driven by AI agents) AgentsRoom saves a Kubernetes cluster as the name of a kubeconfig context (the one gcloud container clusters get-credentials, aws eks update-kubeconfig or az aks get-credentials already wrote, or any hand-written context) and opens it as a tab next to the terminals: the health of its workloads (deployments, statefulsets and daemonsets with ready versus desired replicas, and the condition that explains a stuck rollout), its pods (the same STATUS word kubectl prints, such as CrashLoopBackOff, ImagePullBackOff, Pending or OOMKilled, restarts, node, owning workload), the 80 most recent events and the logs of any pod, including the previous container after a crash. The view refreshes every 15 seconds while it is on screen, filters on one namespace or all of them, and a Problems only switch hides what is healthy. NO CREDENTIAL IS STORED: tokens, certificates and the cloud login plugin (gke-gcloud-auth-plugin, aws, kubelogin) stay in the user's kubeconfig, and the desktop runs kubectl itself, always with the saved --context. Every cluster is READ-ONLY by default; on a cluster made writable, a Restart button runs kubectl rollout restart after a confirmation that names the cluster, the namespace and the workload, louder on a cluster flagged production. AI agents reach the same clusters over MCP with three tools: kube_list (the saved clusters, never a credential), kube_status (a health summary: unhealthy workloads, pods that are not ready, recent Warning events) and kube_kubectl (ONE kubectl command given as an argv). Reads run directly; writes such as rollout restart, rollout undo, scale, delete or apply are refused on a read-only cluster and otherwise wait for the user's approval in a card in the agent's pane, also answerable from the phone; kubectl exec, port-forward, cp, config, --watch and --follow, flags that change the target or the identity (--context, --kubeconfig, --token, --as) and reading Secret values are always refused. The list of clusters follows the account across the user's computers. The mobile app shows the same cluster view read-only (workloads, pods, events, logs) through the desktop, with no restart from the phone. Works on macOS, Windows and Linux; needs kubectl and, for a managed cluster, the cloud's login plugin on the computer. Provider-agnostic: the tools are served to every agent CLI that has an MCP client. ### RDS through AWS SSM (reach an Amazon RDS instance in a private subnet, no bastion) https://agentsroom.dev/features/rds-ssm-tunnel How AgentsRoom reaches an Amazon RDS database that has no public endpoint, no inbound SSH and a locked security group: an AWS Systems Manager Session Manager port-forwarding session. You save a connection whose transport is AWS SSM (instance ID of a managed EC2 node such as i-0123456789abcdef0, AWS profile, region), then create a database connection with the RDS endpoint as its host and pick that SSM connection in the "Reach through" field. When you open the database, AgentsRoom asks the operating system for a free loopback port and spawns the AWS CLI as a child process: aws ssm start-session --target --document-name AWS-StartPortForwardingSessionToRemoteHost --parameters host=,portNumber=,localPortNumber=, plus --profile and --region when the connection declares them. That document forwards THROUGH the managed node TO A THIRD HOST, which is exactly the RDS-in-a-private-subnet case; forwarding to the node itself is the same document with host=localhost. Properties that matter: the forwarded port is bound to 127.0.0.1 only and never published on the local network, the port is picked by the OS at open time, and the tunnel is declared ready only once that port actually accepts a TCP connection (no arbitrary sleep), failing with the error the CLI printed otherwise. Authorization comes from the user's own AWS profile or SSO login, so AgentsRoom stores the instance ID, the profile name and the region and NO AWS key, NO password and NO private key for the SSM hop; prerequisites on the machine are the aws CLI and the session-manager-plugin, plus a managed node running the SSM Agent with an IAM policy allowing ssm:StartSession and a security group letting that node reach the database port. This replaces the three usual answers: a bastion host to patch and monitor, a client VPN to provision and revoke, or a database endpoint and password copied into a chat message. On top of the tunnel the normal database guardrails apply: read-only by default, one statement per call, capped result sets, production flag, and AI agents querying over MCP (db_list, db_schema, db_query, db_connection_new) that receive a result set and never the password. ENGINE COVERAGE, stated plainly: MySQL and MariaDB, PostgreSQL, and MongoDB, so on RDS that means RDS for MySQL, RDS for MariaDB, RDS for PostgreSQL, the Aurora editions compatible with either, and Amazon DocumentDB on the MongoDB side; SQL Server, Oracle and SQLite are NOT supported. The SSM transport itself is engine-agnostic (it forwards a TCP port), and what decides is the client on top of it. Keywords: connect to RDS through SSM, SSM port forwarding RDS, aws ssm start-session RDS MySQL, aws ssm start-session RDS PostgreSQL, RDS private subnet no bastion, session manager port forwarding database client, RDS without a public endpoint. ### Google Cloud SQL through the Cloud SQL Auth Proxy (reach a private Cloud SQL instance, no key stored) https://agentsroom.dev/features/cloud-sql-proxy How AgentsRoom reaches a Cloud SQL for MySQL or PostgreSQL instance that has no public IP, without a bastion VM: in a database connection, Reach through is set to Google Cloud SQL and the instance connection name (project:region:instance) is typed or picked from the list the user's own gcloud login can see (gcloud sql instances list). When the connection opens, AgentsRoom reserves a free loopback port and starts Google's Cloud SQL Auth Proxy v2 on it (cloud-sql-proxy --address 127.0.0.1 --port ), waits until the port accepts TCP, and stops the proxy when the connection closes. The proxy is authorized by the user's Application Default Credentials (gcloud auth application-default login): no service account key and no Google credential is stored by the app. Options: Private IP (--private-ip, the machine must reach the instance's VPC) and IAM database authentication (--auto-iam-authn, no database password, the user is the IAM database user). Errors are explained from the proxy's log: proxy not installed (gcloud components install cloud-sql-proxy), gcloud login expired (run gcloud auth application-default login), missing Cloud SQL Client role, no private IP, unknown instance. Same guardrails as every database connection: read-only by default, one statement per call, capped rows, and AI agents query it over MCP (db_list, db_schema, db_query; db_connection_new / db_connection_save accept cloudSqlInstance, cloudSqlPrivateIp, cloudSqlIamAuth) without ever seeing a credential. The connection follows the account across computers. Cloud SQL for SQL Server and AlloyDB are not supported. macOS, Windows and Linux. ### Push Notification API (send a push to your phone from cURL, a CI job or a cron script) https://agentsroom.dev/features/push-notifications-api One HTTPS POST sends a push notification to every iPhone and Android phone signed in to your AgentsRoom account, even with the computer off. Each inbox (per account or per project) has its own endpoint and a 192-bit send-only key passed in the Authorization header; the key can never read the inbox and can be regenerated or revoked in one click. JSON body: title (160 chars), body (16,000), optional public HTTPS image and HTTPS link, sound default or silent. An Idempotency-Key header makes retries return the same message without a second notification or a second allowance unit. A 202 means stored, not delivered. Messages stay searchable for 90 days on desktop and mobile. Monthly allowance across all inboxes: guest 10, Free 100, Plus 200, Pro unlimited; Team seats include Pro. Open it with the Push button of the project dock or from the notification settings. Sharing with selected teammates of a Team or Pro group. MCP tools: dev_inboxes_list, dev_inbox_create, dev_inbox_configure, dev_inbox_members, dev_inbox_messages, dev_inbox_test, dev_inbox_delete. Not to be confused with Agent Notifications, which tell you when an AI agent finishes its turn. ### Developer Email Inbox (one receiving email address per project) https://agentsroom.dev/features/developer-email-inbox A receiving-only email address for a project or for the whole account, made of the inbox name and a 48-character secret. Service alerts, cron and backup reports, transactional emails of your app and vendor notices land in the Mail tab of AgentsRoom on desktop and mobile, apart from the personal mailbox. Plain text only: no HTML rendering, no remote images or tracking pixels, attachments ignored; no sending and no replies. Regenerating the address cuts off the old one immediately. A JSON endpoint (title, body, sender, link, send-only key) accepts the same messages over HTTPS. Monthly allowance across all inboxes: guest 10, Free 100, Plus 200, Pro 500; Team seats include Pro; messages kept 90 days. Same MCP tools as the Push Notification API. **Video (1 min 18 s):** [Developer Email Inbox, shown in the real app](https://youtu.be/LMJYLJT-ZRI). A Mail inbox is created for a small shop project from the Service report template, its address is copied, then regenerated as if it had leaked; a test "Backup failed" message lands in the Mail tab, marked new, and opens as plain text; asked what failed, the AI agent reads the inbox with the AgentsRoom tools and answers that the disk on db-01 is full. ### Remote Fleet (run AI agents on every machine, one window) https://agentsroom.dev/features/remote-fleet Remote Fleet links every computer you own into a single unified view. The office desktop, the laptop at home, a build server in the corner: AgentsRoom shows every project and every Claude, Codex or Antigravity agent in one window, whichever machine it actually runs on. Each machine keeps running its own agents locally, and the fleet view aggregates their status, terminals and projects so you can pilot the whole fleet from wherever you are. Cross-device orchestration travels over an exclusive end-to-end encrypted relay, so your code and your agent output never leave your machines in the clear. Beyond your own machines, you can invite teammates into a project by email or pseudonym and collaborate on the same agents in real time: they attach to the agent sessions running on your machine, watch the live output and send input, with per-agent access control and a private end-to-end encrypted room per member, so a small team can treat one workstation like a shared local server without any SSH or VPN. This is not the session sharing of Claude Code itself: as of October 2026, Claude Code shares cloud sessions from claude.ai/code only (Team visibility on Team and Enterprise, Public on Pro and Max), as a link that shows the session as it was when opened, with no live updates, and a terminal session has no share link; an AgentsRoom project member attaches to the live session of any agent CLI on the host machine. Settings changed on one computer, the order of saved SSH servers and databases included, reach your other computers live while they are open, and a Machines chip in the status bar lists the computers of the account and whether each one is online. Dev terminals opened on another of your computers appear in the project's terminal bar on the desktop with the machine's name, and open from there, streaming from the machine that runs them. Since 1.213.0 the quick launch (the flash agent button) also picks the computer: a selector at the bottom of its window lists your computers, on the desktop and in the mobile app. A backlog ticket can be started on any of your machines from the board: Start still runs it on the computer you are using, and the Run on menu next to it lists your other computers that hold the project, each marked online or offline; the chosen machine starts the ticket as if you had clicked Start there, and its card shows on every machine where it runs and its live status, so tickets spread across machines and run in parallel without walking to each one. An agent can also move to another of your computers WITH its conversation: right-click it, pick a computer under Continue the conversation on, and it picks up the same conversation over there while its console here closes (This computer brings back an agent running elsewhere). Claude Code and Codex agents resume their exact conversation, other CLIs start a new session that first reads the transcript of their console; the conversation travels through a dedicated end-to-end encrypted relay room between the two machines, and files are not copied, so the agent's changes go through git. An agent running on another of your computers opens in the same Conversation view as a local one (since October 2026): its answers rendered as a chat, the answer being written shown live, and its question cards and Allow / Deny permission cards clickable from the computer you are using, the answers being typed on the machine that runs it; the toggle next to its name switches back to the streamed terminal, and the mobile app's remote console offers the same conversation view. The way to stop SSH-hopping between boxes and instead drive your entire multi-machine AI coding setup, solo or as a team, from a single screen. ### Continue on Another Computer (move a Claude Code or Codex conversation to your other computer) https://agentsroom.dev/features/continue-on-another-computer Started an agent at the office and want to keep going on your laptop? Right-click the agent, pick the other computer under Continue the conversation on, and the agent picks up the same conversation over there, where it left off: the console on the first computer closes so the conversation is never written in two places. Claude Code moves its transcript with its sub-agent transcripts and tool outputs, Codex moves its rollout, and both resume their exact conversation with their usual resume command; every other CLI starts a new session that first reads the transcript of its console, and the app says so before the move and in the console. This computer, in the same menu, brings back an agent that runs on another computer. The conversation is copied, never deleted, and travels end-to-end encrypted through a relay room created for that move, that only the two computers join; nothing is stored on a server. Project files are not copied: the agent's changes go through git (commit and push where it worked, pull on the other computer). Both computers must be signed in to the same account, have the project and be online. The same move is available from the AgentsRoom mobile app, through the paired desktop. ### Git Worktrees (one checkout per ticket or agent, prepared, reviewed and merged) https://agentsroom.dev/features/git-worktrees A git worktree manager for AI coding agents, for every CLI AgentsRoom runs (Claude, Codex, GitHub Copilot CLI, Cursor and 12 other agent CLIs). A backlog ticket asks for its own checkout with "Code in a separated worktree for this task" (pick an existing worktree or type a new branch); an agent gets one from the Workspace card of the Add agent window (Main, an existing worktree, or New); a saved agent or a default profile can turn on "New worktree per agent" (branches agents/