You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Thanks for describing the use case. Keeping a long-running agent team working after your desktop goes offline is a cloud-execution requirement; remote access to a desktop alone would not meet it.
I checked the current public source at 81b666a. The available paths and boundaries are:
Run the CLI on an always-on machine you control. The headless CLI provides mcode exec for shell/CI jobs, with structured progress/results, run limits, and session continuation. A remote VM is a possible deployment approach: install/configure the CLI there and keep the workspace and session data on persistent storage. You would need to manage process lifetime and recovery yourself. In particular, the documented headless behavior cancels on SIGHUP, so simply starting it in an SSH shell and disconnecting is insufficient. Headless also returns an interaction error when it needs a human response; use an interactive host for that work. This is a deployment approach, not a verified hosted-service offering or a guarantee of uninterrupted execution.
Build an interactive host around ACP.mcode acp supports session updates, permissions, and cancellation over stdin/stdout. A browser-based host would still need a server-side bridge, authentication, workspace isolation, persistent storage, and job/reconnection handling. ACP itself is not a Web server. The existing integration discussion is Third-party desktop client integration: is ACP the right surface for embedding mcode? #176.
Multi-agent delegation is already present, but it is separate from hosting. The public runtime retains subagent/task services. See [Feature]: Expose mavis orchestrator via mcode exec --team (CLI parity with Desktop GUI Team button) #135, especially the author's later correction that basic CLI delegation is prompt-driven and does not require a --team flag. That does not establish Desktop Team UI parity or durable cloud orchestration.
The published source scope covers TUI/headless/ACP and excludes cloud handoff and cloud-executor implementations; it does not provide a ready-to-deploy Web edition. #101 is the related Web-mode request. I have not validated a hosted Web product against your requirements, and cannot give a delivery date here.
To make this request actionable, are you looking for an officially managed Web service, or a self-hosted Web UI on your own server? It would also help to know the expected task duration/concurrency, whether tasks need desktop-only tools or private-network access, and whether continuing after a server restart (as well as closing the browser) is required.
This is source/documentation triage; I have not run a long-duration cloud deployment test. Keeping this open as a product request pending those details.
Activity
hetaoBackend commentedon Sep 19, 2026
Thanks for describing the use case. Keeping a long-running agent team working after your desktop goes offline is a cloud-execution requirement; remote access to a desktop alone would not meet it.
I checked the current public source at
81b666a. The available paths and boundaries are:mcode execfor shell/CI jobs, with structured progress/results, run limits, and session continuation. A remote VM is a possible deployment approach: install/configure the CLI there and keep the workspace and session data on persistent storage. You would need to manage process lifetime and recovery yourself. In particular, the documented headless behavior cancels onSIGHUP, so simply starting it in an SSH shell and disconnecting is insufficient. Headless also returns an interaction error when it needs a human response; use an interactive host for that work. This is a deployment approach, not a verified hosted-service offering or a guarantee of uninterrupted execution.mcode acpsupports session updates, permissions, and cancellation over stdin/stdout. A browser-based host would still need a server-side bridge, authentication, workspace isolation, persistent storage, and job/reconnection handling. ACP itself is not a Web server. The existing integration discussion is Third-party desktop client integration: is ACP the right surface for embedding mcode? #176.mcode exec --team(CLI parity with Desktop GUI Team button) #135, especially the author's later correction that basic CLI delegation is prompt-driven and does not require a--teamflag. That does not establish Desktop Team UI parity or durable cloud orchestration.The published source scope covers TUI/headless/ACP and excludes cloud handoff and cloud-executor implementations; it does not provide a ready-to-deploy Web edition. #101 is the related Web-mode request. I have not validated a hosted Web product against your requirements, and cannot give a delivery date here.
To make this request actionable, are you looking for an officially managed Web service, or a self-hosted Web UI on your own server? It would also help to know the expected task duration/concurrency, whether tasks need desktop-only tools or private-network access, and whether continuing after a server restart (as well as closing the browser) is required.
This is source/documentation triage; I have not run a long-duration cloud deployment test. Keeping this open as a product request pending those details.
sirinath commentedon Sep 19, 2026
I am looking for an officially managed Web service included in the subscription plan.