Backlog accepts invalid status in list and update Runtime accepts a status outside the documented enum, persists it, and can query it back. Runnable reproduction / implementation sketch backlog_list({"status":"in_review","limit":5}) backlog_update({"taskId":"<disposable-task-id>","status":"bogus"}) backlog_get({"taskId":"<disposable-task-id>"}) backlog_list({"status":"bogus","limit":5}) Steps Run the invalid list filter. Write bogus status to a disposable task. Fetch and filter by bogus. Restore or delete the task. Safety Use a disposable task. Restore it immediately if it matters. Observed Invalid filter returns success; invalid write returns ok:true and persists; bogus filter returns the task. Expected / proposed Enforce todo, in_progress, pending, or done at runtime. Why it matters Tasks can disappear into unsupported states and simple agents may trust invalid writes.

Add an orchestrator layer above Agent Teams: one "god orchestrator" agent that decides and dispatches the work to a swarm of sub-agents at runtime, instead of the user wiring every node of the graph by hand up front. That is the gap with today's Teams, where the human designs the whole flow before it runs. Two users converge on the same request. agent67 filed it as an "AI harness swarm monitor" and frames it as "an AI office": a live view of the swarm working, which drew reactions and community brainstorming. grube386 backs it independently and points at Munder Difflin as prior art with the same concept but, in his words, a really clunky UI: the differentiator here would be AgentsRoom's UI plus the orchestrator option. Both insist it must stay an OPTION, "not for everything but as an option", never the default way teams run.

Access to agents and the relevant blast radius using a central credential over public network infrastructure using emails as a username means high blast radius by construction. Security is already generally prioritized for the product - this is both philosophically and pragmatically a logical next step in recognition of that

Thinking something like a pill or banner, effectively indicating whether (latest) skill/hook/mcp servers for the product are actually available in any given agent / team member session.

backlog_update can mutate sibling-project tasks by ID A write from ARBT resolves and changes a task UUID belonging to another project. Runnable reproduction / implementation sketch backlog_get({"project":"<sibling-project>","taskId":"<sibling-task-id>"}) backlog_update({"taskId":"<sibling-task-id>","status":"pending"}) backlog_get({"project":"<sibling-project>","taskId":"<sibling-task-id>"}) // Restore original status immediately. Steps Read a sibling task and record status. From the current project, update the UUID without project. Read the sibling task again. Restore its exact original status. Safety HIGH RISK. Prefer preserved evidence. If rerun, restore in the same sequence. Observed The current-project write returns ok:true and the sibling task changes. Independently reproduced and restored twice. Expected / proposed Current-project mutations must not resolve sibling-project task IDs. Why it matters Project-isolation failure capable of corrupting unrelated backlog state.

The Kimi CLI supports /btw. Bring the side-question mode to it too, so a question can be asked without stopping the run.

Expose team-aware effective execution metadata A valid team assignment appears only as task.teamId; effectiveExecutor looks like null/default single-agent execution. Runnable reproduction / implementation sketch backlog_update({"taskId":"<disposable-task-id>","teamId":"<valid-disposable-team-id>"}) backlog_get({"taskId":"<disposable-task-id>"}) Steps Create a disposable Codex team: Start to Worker to End. Create a task without overrides. Assign the team and fetch the task. Delete both fixtures. Safety Use disposable task and team fixtures. Observed task.teamId is valid, but effectiveExecutor has no team ID, name, graph, or discriminator. Expected / proposed Expose resolved team identity or mark single-agent metadata not applicable. Why it matters Models need an extra teams_get; smaller models may overwrite a correct team assignment.

Provider usage should be shown in the bottom at all times, this way we have good visibility of usage in all providers. Please check Orca status line.

So instead of the normal file browser and editor, if we can integrate the Visual Studio Code server, if we can do the integration for that, that would be great. I mean, it's pretty simple to integrate it. And, you know, we can use that as a way to definitively view our project and run things. Or, you know, it doesn't even have to be integrated as Visual Studio Code, you know, editor. So it's just that the IDE that currently ships with it is kind of a little, you can't really do much with it, is what I'm saying. And the view of it is kind of, like, I mean, it's getting there. But, you know, it's just a basic one. But I think the way that we could push this further is to instead of building it out yourself, initially just put Visual Studio Code server integration into it. Just drop it in. It works out of the gate. And then you could even have it pop out like you do the terminals, too. Like, you can have it pop out and be separate so where you can see everything on a different screen or, you know, in a different pane. Like, right now I'm running at 4K TV. And I can see agent's room. I can see everything else on my stuff. And then agent's room is concealed to a separate corner. So, you know, I can have Visual Studio Code server integrated with agent's room and I can have it on a different little section of my screen and be able to manage and see my files a little bit better instead of, like, it being hidden inside the file browser there is now. https://code.visualstudio.com/docs/remote/vscode-server

User requests a Sandbox setting feature to control command execution and resource access within AgentsRoom. Key requested permissions include allowing or denying commands, path locations (inside or outside projects), and filename patterns via prefix or regex. Additionally, the user suggests a UI to manage these permissions easily. A special feature requested is custom slash commands to combine bash or file scripts for shorthand commands, reducing AI token usage. The user also proposes secret management in dev mode to securely inject secrets at runtime (e.g., into .env files) without AI agents accessing or reading them. The team should design and implement a comprehensive Sandbox permission system with UI controls, support for custom slash commands, and secure secret injection mechanisms.

This one neat! https://agentsroom.backlog.agentsroom.dev/tickets/ba673383-dc84-4185-9f47-78ab0e9bee97 Thanks for bringing up alive! I'm talking all the CLI out there, as someone might use their own preferences CLI i.e jcode, codegraff, prime-agent, commandcode, cursor CLI & etc I'm thinking to combine the CLI with my open weight subs, but curious as well if it possible for agents to talk each other like this, so Cursor CLI Agents do the planning, then handoff/delegate to Command Code CLI for execution, as I'm not quite understand how this works https://agentsroom.dev/features/agent-delegation but I believe it was optimized for Codex + Claude only cmiiw

Steps: 1. Call agents_spawn with a bounded Codex prompt that replies COMPLETE and exits. 2. Save the returned agent.id. 3. Call agents_list({}); the ephemeral run is absent. 4. Call agents_get({agent: returnedId}); it returns not found. 5. Attempt to query state, wait for completion, or close only that owned ID; no supported MCP operation exists. Expected: Expose owned ephemeral run list/get/status/wait/result/close operations with parent ownership, timestamps, completion/error summary, and rejection of attempts to close unrelated agents. Observed: The spawn response explicitly says the coordinator will not be notified and must tell the user to watch the tab. agents_list/get cover saved configurations only. A later spawn was rejected because eight throwaway agents were still counted as running.

So basically the idea is about the account selection feature. Whenever you spawn up a project manager or something like that and you want to use that specific account, you know, like for work or the default account, you literally have to dictate to the agent and tell it, hey, I want you to use this, this or that, instead of telling them, hey, I want you to spawn up GPT 5.6 Sol High or Extra High or just Codex Spark and stuff like that. It'll actually use whatever is available. It'll even use Claude. If you have Claude as your provider as well, unless you give a context to explicitly not use Claude, it'll use Claude as well, even if you have no usage. So you'll have your PM delegating to other agents that it doesn't have any context whether the usage is expired or anything like that. So if we have an account that is locked on to a specific PM or agent or something like that, it can only call up agents for that specific account unless you specify otherwise to the agent. I think that would cut a lot of the confusion in a way. Or we can have like a little button, you know, somewhere visibly on the harness or something that can do that. Like I know that we already have one, like when we have multiple agents working with the same provider with a different profile where you can just click on the little agent, it'll say, it'll tell you whether it's from the default or work profile. But I feel like we can expand it a little bit more to make it easier for users to delegate tasks without having to do too much work in the harness.

Currently it just feels like im talking to the terminal. Which is fine, but it would be great to have a richer chat interface where you can receive images, diagrams, etc, for accurate reviewing and guiding agents. The chat interface is nimbalyst and pivio is phenomenal.

It would be cool if the leaderboard, like if we had like the most submitted tickets or whatever, if you guys hosted like your own AI model and it gave us credits for that for submissions. I mean, it would be kind of like a cool feature where we would just be able to like code for like, I don't know, an hour or something like that, you know, unlimited or something. And it would just be an incentivized reason for people to submit tickets. I mean, I don't really care for it. I mean, I'm gonna submit tickets regardless. But yeah, so that would be kind of funny. I mean, some people would like it. But yeah, rewards.

The user reports that the mobile agent chat experience in AgentsRoom feels clunky, with streaming often breaking or stalling and messages lacking smoothness. They find the overall UX messy, which is a major pain point since chat is their primary interaction mode on mobile. They suggest examining competitors like Paseo for inspiration on streaming, conversation flow, and chat experience on small screens. The user is willing to provide more detailed feedback and examples if needed. The team should prioritize enhancing the mobile chat's streaming reliability, message smoothness, and overall user experience to better support mobile workflows.

Today a team node's guardrails live entirely in stepInstructions and in the skills it loads. That makes every guardrail advisory: it holds only for as long as the LLM reads the text and complies. We run an operational kill-switch (a repo variable that must halt all automation instantly) and we had to implement it as "first line of every node's instructions" — which means a node that simply doesn't follow the instruction runs anyway, and nothing notices. checkCommand doesn't cover this. It's an exit gate: it runs in the handoff path, after the agent has already completed the step. By then the work is done. There is no hook between entering a node and the agent acting. Proposal — entryCheckCommand + entryCheckPolicy on the node, symmetric with the existing checkCommand/checkFlag, but executed by the runner before spawning the agent. Exit 0 proceeds; any other exit, a timeout, or a spawn error blocks the run. entryCheckPolicy chooses between blocking the run and skipping to a designated node. Acceptance criteria 1. With the check command returning non-zero, the run blocks at the first node having consumed zero LLM turns — verifiable in the run's token accounting. 2. The block is visible in the UI with the command's stderr, not a silent skip. 3. A node without entryCheckCommand behaves exactly as today. 4. Command timeout and spawn failure are treated as failure (fail-closed), never as success.

First-use feedback on OpenSpace: the project name is sometimes missing on an agent, double-click does not open the console, the transition from to-review to seen is unclear, agents cannot be pinned when there are many, and a concierge section is missing from the project folder view.

Set completedAt when backlog tasks become done A successful transition to done leaves completedAt null. Runnable reproduction / implementation sketch backlog_update({"taskId":"<disposable-task-id>","status":"pending"}) backlog_update({"taskId":"<disposable-task-id>","status":"done"}) backlog_get({"taskId":"<disposable-task-id>"}) Steps Create a disposable todo task. Move it to pending, then done. Fetch it and compare status, updatedAt, and completedAt. Delete the fixture. Safety Use a disposable task and delete it. Observed status is done and updatedAt changes, but completedAt remains null. Expected / proposed Transitioning to done should set completedAt; reopening should clear it. Why it matters Completion latency and reporting cannot use the existing timestamp. Simple agents may treat null as incomplete state.

Screenshots can already be pasted or dropped into the composer, but there is no visible attach button: add a paperclip that opens a file picker.

Allow the user to offset the position with a slider that adjust by the pixel on both X & Y Axis

so i connected all the connection line in the team workflow, even added the step instruction for each agents, and im facing a problem that when i click "send to the next agent" the next agent doesnt automatically start, and it just shows black input cli page

The hooks currently registered are PostToolUse, UserPromptSubmit, Stop, Notification and PermissionRequest. PreToolUse isn't among them, and the file hook is async: true — fire-and-forget, so it is structurally incapable of denying, not merely unconfigured. The practical consequence: even with a gate on node entry, a pause triggered in the middle of a long step is never seen. The agent read the gate on entry and keeps going for the next 20 minutes, possibly through a commit, a push or an external publish. This is a plain TOCTOU window and it cannot be closed from the instruction side. Proposal — a PreToolUse hook, synchronous, with an explicit refusal contract: a non-zero exit (or a permissionDecision: "deny" payload) blocks the call and returns the reason to the agent as a tool result. Ideally matchable by tool name, so the cost is paid only on the calls that matter (writes, commits, external publishes). Acceptance criteria 1. A hook returning "deny" prevents the tool from executing; the agent receives the reason and can react instead of crashing. 2. The hook is synchronous — the tool does not start before the decision. 3. A hook that errors or times out is treated as deny, not as allow. 4. Overhead is measurable and confined to the matched tools.

Detect and pause duplicate in-flight agent work Harness-driven collision detection should protect usage before agents duplicate active, planned, or shipped work. Runnable reproduction / implementation sketch onAgentProgress(snapshot) -> findSimilarWork(active agents + planned/in development/shipped tickets) -> confidence >= 0.90: checkpoint + soft pause + notify -> confidence >= 0.70: inject related-work context Steps Track each agent objective, scope, files, and progress. Compare against agents and backlog lifecycle states. Inject related context without an MCP call. Checkpoint and soft-pause only high-confidence duplicates. Let users stand down, redirect, merge, or resume. Safety Product proposal. Similarity alone must never hard-kill an agent. Observed Agents explicitly told to inspect the backlog still filed differently worded duplicates. Sanity review repeatedly consolidated overlapping roots. Expected / proposed Prevent duplicate work while preserving user control and avoiding destructive cancellation. Why it matters Reduces wasted tokens, overlapping implementations, duplicate tickets, and concurrent work obscuring features.

It would be nice to have the backlog tickets linked to github issues per project. If I create a new github issue, it would appear in the task list if I have linked my project in the setting s

Profile settings report object type but return arrays claudeProfiles and codexProfiles declare type object while their values are arrays. Runnable reproduction / implementation sketch settings_get({"key":"claudeProfiles"}) settings_get({"key":"codexProfiles"}) Steps Fetch both profile settings. Compare declared type with JSON value shape. Safety Read-only. Redact local profile paths in public screenshots. Observed Both report type object; both values are arrays. Expected / proposed Expose an array type or explicit collection schema. Why it matters Typed clients need exceptions; smaller models may parse the wrong shape.

User reports that on the mobile app, when using Open Hands sessions, they cannot open or type messages. Additionally, the agent does not know how to send messages in Open Hands sessions. The team should investigate and resolve the issue preventing typing and message sending in Open Hands sessions on mobile devices.

I believe onorca had this one: https://www.onorca.dev/docs/review/github#reviews:~:text=GitHub%20PR%20conversation%20comments It able to see the github comment, and can queue & schedule to send to the agent, along with copy, reply, react, threading supports and stuff. I think agentsroom missing this features, the backlog should also be integrated, so all the task from this 3rd-party tools can integrated/imported to backlog

Some CLIs offer a /btw command to ask for information without stopping the current flow. Same thing here: query an agent without interfering with its work.

User Christian Gilman inquired about using local TTS engines like Qwen3 TTS within AgentsRoom. Currently, AgentsRoom only supports built-in Voice Mode using its backend for TTS and does not allow routing TTS output to local or external TTS models. The user requested the ability to tap into the AgentsRoom backend to route TTS to their local model. The team should evaluate and implement a feature to enable users to configure and use local TTS engines for speech output, potentially by allowing routing or integration with local TTS models. This would enhance flexibility beyond the current built-in voice features.

Native and app store deliverable packaging is nice in some ways - but also a significant hurdle in others (slower, walled garden gated mobile client updates; drift between desktop installation and mobile surface in any given pair of mobile client and desktop install; etc.). PWA ready webapp servable from the desktop gateway itself means hitting the ground running and potential for lockstep parity and interoperability in a given "deployment". Tailscale readiness out of the box would be a nice bonus.

I do a lot of Android Studio testing with real wireless devices, and I think Agents Room could significantly improve mobile QA by integrating directly with the local development environment. If Android Studio is running and a connected device is available, the harness could detect that automatically and expose the device/session to the agent. The agent could then launch the app, navigate through screens, test responsiveness across device sizes, reproduce issues, capture errors, and assist with debugging. The same concept could apply on macOS with Xcode, iOS simulators, and connected iPhones. ### Key idea Instead of requiring the agent to constantly search for this context, **Agents Room Harness should provide it proactively.** For example, the harness could detect: * Android Studio or Xcode is running * Connected physical devices * Active emulators/simulators * Current application/build * Device model, resolution, orientation, and OS version * Relevant logs, crashes, or build errors The harness could then inject that information into the agent's context only when needed. This would make QA much more reliable than relying primarily on browser testing, especially for native applications, responsiveness, and device-specific issues. It could also reduce token/usage costs. I've noticed agents sometimes spend a significant amount of context searching for information the harness could already know. If the harness gathers that information locally and simply tells the agent, the agent can immediately focus on the task instead of spending usage discovering the environment. Essentially: **make the harness more context-aware so the agents have to search less.** That could improve autonomous QA, debugging, responsiveness testing, and overall efficiency while potentially reducing agent usage considerably. Just my two cents. You guys have done an amazing job with Agents Room, and I think this could make the development workflow even stronger.

The user requests a more advanced and robust chat agent experience on the Android app, noting that the current implementation feels raw and fragile. The development team should improve the Android chat agent's stability, usability, and feature set to match or exceed other platforms. This may include UI enhancements, performance optimizations, and additional chat functionalities. Other platforms appear more mature, so aligning Android with them is desirable.

Expose explicit settings nullability A boolean setting can return null without metadata describing nullable/unset state. Runnable reproduction / implementation sketch settings_get({"key":"skipMemorizeOnClose"}) settings_get({"key":"claudeProfiles"}) settings_get({"key":"codexProfiles"}) Steps Fetch all three settings. Compare declared types, values, and isSet. Check whether nullable and array shape are explicit. Safety Read-only. Observed A boolean returns null with isSet:false; profile arrays are labeled object. Expected / proposed Expose nullable/unset metadata and accurate collection shape. Why it matters Models infer schema; smaller models may conflate unset with false.

This is not big enough to hold my whole description I will break it down into the comments of this ticket

User feedback highlights a fundamental mismatch between AgentsRoom's current agent-centric model and developers' needs for task/worktree-centric workflows. Key requests include: - Invisible, zero-friction Git worktree lifecycle management: tasks should automatically spawn isolated ephemeral worktrees, allow multiple agents to operate within them, and clean up after completion without manual overhead. - Integrated, intelligent 3-way merge conflict resolution powered by AI, matching or exceeding tools like JetBrains or GitKraken. - Lightweight, high-performance AST-level refactoring capabilities comparable to WebStorm but without heavy resource consumption. Additionally, the user notes onboarding and documentation focus too much on features rather than practical workflows, causing confusion about support for parallel multi-worktree task development. The team should prioritize shifting the product model from agent-centric to task/worktree-centric, build seamless worktree management and AI-assisted merge conflict resolution, and improve documentation to clearly explain these workflows.

Users want OmniRoute integrated as a first-class provider in AgentsRoom to enhance functionality. This integration would allow for automatic failover, token compression, and better usage tracking, streamlining the user experience and providing access to a wider range of models.

## Demande Un utilisateur abonne (Andrea, profil consultant, non developpeur) signale que le principal manque d'AgentsRoom aujourd'hui n'est pas une fonctionnalite mais **une documentation complete et a jour**. Il n'a trouve aucun endroit ou parcourir l'ensemble des features, des concepts et des options de configuration. Pour se lancer, il a du **faire scraper les pages du site agentsroom.dev par une IA** afin de se reconstituer une vue d'ensemble du produit et de se faire expliquer, etape par etape, comment demarrer. Plusieurs mois apres, il estime n'utiliser qu'une fraction du produit. C'est un signal de retention et d'activation, pas un confort editorial : le cout d'entree est paye par chaque utilisateur qui n'est pas developpeur professionnel. ## Verbatim (Andrea, par email) > If I had to point out the main thing that is still missing for me, though, it would be comprehensive and up-to-date documentation. > > For someone who is not a professional developer, the first step into AgentsRoom was quite difficult. When I started, I actually ended up using AI to scrape and analyse the different pages of the AgentsRoom website, just to build a complete picture of the available features and have the AI explain to me step by step how I could start using them. > > Even now, there are several parts of the product that are still not completely clear to me, and I'm quite sure I'm only using a fraction of what AgentsRoom can actually do. > > Having a proper docs section where I could easily browse all current features, concepts, configuration options and some practical examples or workflows would make a huge difference, especially for users like me who are technical enough to experiment, but don't necessarily have a software engineering background. Contexte utilisateur, sur le reste du message : il est satisfait du produit, cite la polyvalence et l'orchestration de plusieurs agents / projets / outils sans devoir tout faire rentrer dans un workflow unique, et dit qu'AgentsRoom est le premier outil qui lui donne le sentiment de pouvoir construire quelque chose de complexe par lui-meme (apres des essais frustrants sur VS Code, Cursor et Windsurf). ## Ce qui est demande Un espace documentation navigable, qui couvre : 1. **Les concepts** : projet, agent, role, provider CLI, team, backlog, skill, prompt, memoire projet, commandes dev, backlog public, cloud agents. 2. **Toutes les features actuelles**, une entree par feature, avec ce qu'elle fait et ou elle se trouve dans l'app. 3. **Les options de configuration** : reglages Settings, providers et modeles, MCP, hooks, worktrees, partage de donnees. 4. **Des exemples pratiques et des workflows de bout en bout** : premier projet, premier agent, un ticket backlog joue par un agent, une team, le backlog public, le mobile. 5. **Un parcours de demarrage** explicitement pense pour un utilisateur non developpeur. ## Existant a auditer avant d'ecrire Le contenu produit est aujourd'hui eclate et aucun de ces points d'entree ne joue le role d'une documentation : - `site/src/app/[locale]/features/*` : pages marketing par feature, orientees conversion et SEO, pas reference. - `site/src/app/[locale]/guides/*` : guides existants, couverture partielle. - `site/src/app/[locale]/blog/*` : articles, non structures en reference. - `site/src/app/[locale]/skills` et `/prompts` : catalogues, pas de doc d'usage. - `site/public/llms.txt` : vue machine, pas destinee aux humains. - Le changelog est en `noindex`. ## Points de vigilance - **i18n** : le site est publie dans toutes les locales de `site/src/i18n/routing.ts`. Une doc complete traduite a la main dans 20 langues est un chantier a chiffrer AVANT de commencer. Le decoupage en lots (concepts d'abord, features ensuite) fait partie du travail de cadrage. Rappel de la regle du depot : aucune locale ne se remplit avec de l'anglais. - **Fraicheur** : le probleme signale est autant "complete" que "up-to-date". Une doc qui derive est pire que pas de doc. Prevoir des le cadrage comment elle reste synchrone avec les livraisons (la regle CLAUDE.md "une feature modifiee doit etre refletee cote site" doit pointer vers la doc, pas seulement vers la copy marketing). - **SEO** : ne pas cannibaliser les pages `/features/*` qui portent deja des requetes. Definir la propriete des requetes avant de creer les URLs (voir `context/SEO.md`). ## Definition of done - Un cadrage ecrit : arborescence proposee, perimetre du premier lot, cout i18n estime, regle de fraicheur, arbitrage SEO vis-a-vis de `/features/*`. - Validation de ce cadrage avant toute redaction.