Devin Desktop is easiest to take for a single application with a set of features. In practice it is six different execution environments around one agent, and confusing them is the main source of the product's "capricious" behavior. The same word in two places means different things, because behind it stand a different filesystem, different permissions and a different trust boundary.
The naive model is clear: there is Devin, it has capabilities, and where they are shown is an interface detail. From it grows the expectation that a setting from the editor applies in the cloud, that a permission from one session extends to all of them, that "the agent" is the same everywhere. Each of these expectations breaks at an environment boundary - usually at an inconvenient moment, when the agent did something other than what you thought was allowed.
It breaks on the fact that the place of execution sets both the context and the permissions. The Editor lives locally and handles Tab, Command, navigation and preview, but it is not an autonomous project agent. Devin Local runs on your machine with its own permission model. Devin Cloud runs on a separate VM with its own environment and network. An ACP agent usually launches as a local subprocess, but under someone else's terms. Cascade stays local for legacy processes with different modes, hooks, MCP and memories. The Command Center is a management interface that does not run the task itself but gathers local and cloud sessions into a single queue by status.
Why there are several environments rather than one universal one. Each surface is a deliberate trade of closeness to your state for reach and autonomy. The Editor, with its inline mechanisms Tab and Command, sits right next to the cursor and your context, but does not run a project on its own. Devin Cloud, by contrast, knows nothing of what did not reach the repository and the cloud environment's configuration, yet it survives a closed laptop and holds a long horizon. Collapsing them into one executor would either strip local work of its immediacy or force a cloud task to depend on your machine. Different environments are different points on one trade-off, not a random fragmentation.
It helps to lay this out on one map once, so you pick a surface deliberately rather than by whichever window is already open. Below is such a table: where an environment runs, what it is for, and what its main boundary is. You return to it when deciding where to run a specific piece of work.
The technique that holds everything else together is to always name the surface in full. "Run the tests" is ambiguous: in the Editor it is the terminal under your permissions, in Devin Local it is Exec under permission rules, in Devin Cloud it is a command in someone else's VM, in ACP it is an action of a third-party agent. Until the surface is named, neither the context, nor the permissions, nor the way to verify the result is defined.
The cost of mixing is concrete. Send to the cloud a task that needs your local services and uncommitted files, and you get an agent that honestly works with the wrong state. Grant an ACP agent access without reading the provider's terms, and you carry the code and the billing outside Devin's policy boundary: the documentation warns directly that for external ACP agents Devin's privacy policy and legal terms do not apply, and billing goes straight to the provider.
| Surface | Where it runs | What for | Main boundary |
|---|---|---|---|
| Editor | Locally | Tab, Command, navigation, preview | Not an autonomous project agent |
| Devin Local | On your machine | Repository-wide changes, tests, tools | Its own permission model |
| Devin Cloud | A separate VM | Long and background tasks | Separate environment and network |
| ACP agent | Usually a local subprocess | External compatible agent | Provider's terms, data and billing |
| Cascade | Locally | Support for legacy processes | Different modes, hooks, MCP and memories |
| Command Center | Management interface | Sessions, statuses, Spaces | Does not run the task itself |
Each surface has its own zone. A local edit with a clear diff - the Editor or Devin Local. Long background work with the laptop closed - Devin Cloud. A specific third-party agent ecosystem - ACP, after checking the provider. An old workflow or memory - temporarily Cascade. Watching everything at once - the Command Center. A surface is chosen for the task, not for the window that is already open.
A separate trap is the word "plugin", which has three different meanings here. The first is an editor extension from the Open VSX catalog inside Desktop; in stable 3.7.16 the former Plugins section was renamed to Extensions. The second is a Windsurf Plugin that brings Cognition's capabilities into JetBrains and other editors. The third is a Devin agent plugin that bundles rules, skills, hooks, MCP and subagents and extends the agent itself. These are three independent chains of trust, and the type must be named in full.
You should check where you are before, not after, an action. See which surface is active and which agent is chosen; for ACP open the provider's terms; for an extension check the publisher, the permissions and the update source; for an agent plugin check what exactly it brings into rules, hooks, MCP and subagents. Each of these glances answers one question: whose environment this is and whose rules apply in it.
The typical failure is treating a symptom on the wrong layer. "The setting did not apply" - because it belongs to another surface; "the agent did not see the file" - because it works in a cloud clone; "the command was not found" - because it lives only in the CLI or moved to Next. Before hunting for a bug, name the surface and the plugin type - most often the explanation is already there.