
The former Windsurf became Devin Desktop - not just an editor but several execution environments around one agent: the local IDE, Devin Local, Devin Cloud, Cascade and the shared ACP protocol. How to pick a surface for a task, what limits the agent in each, and how to prove a result before it reaches the repository.
Windsurf, which many knew as a standalone editor, became Devin Desktop - the local face of Devin, Cognition's AI engineer. The rename is not cosmetic: with it the editor stopped being a single window and turned into a set of surfaces around one agent. A local IDE with Tab and Command, Devin Local with explicit permissions and a sandbox, separate worktree sessions and subagents, cloud VMs with a long horizon, the shared ACP protocol for third-party agents, and the Cascade legacy from the Windsurf era. They share part of the configuration, but they run in different environments and with different trust boundaries. To understand Devin Desktop is to stop seeing a single interface and start seeing a system of environments, each with its own context, its own permissions and its own way to prove a result.
This book takes Devin Desktop from the first run to autonomous work. First - the new map: how the surfaces differ and how to pick the right one for a task. Then a controlled foundation: installation on three platforms, sign-in and settings import, git as a safety net, a first safe cycle. Next daily work in the editor: Tab and Command, code lenses, the terminal, browser preview, models and the repository index. After that - the prompt as a contract: context, the Ask/Plan/Normal modes, the proof cycle, cost. Then Devin Local as the main agent on your machine: permission rules, the sandbox, worktrees, subagents. Next configuration: AGENTS.md, rules, skills, MCP, hooks, plugins. After that - the Command Center, Spaces, Cloud and ACP. Then Cascade and migration from Windsurf. And at the end - security, privacy, commands, troubleshooting and full references.
The material rests on one distinction. Where a command name, a configuration field, a path, an event or a limit is described directly in the Devin documentation, the book relies on the primary source. Where a technique only follows from documented behavior, it is an engineering conclusion: useful, but not passed off as a product requirement. That split matters more than convenient generalizations, because a setting pays off only when its source, its allowed value and the cost of a mistake are clear.
You can read in order - the chapters run from the map and the foundation to daily work, autonomy, configuration, the cloud, migration and security - or go straight to the one you need: each ends with how to verify the result. Devin changes fast, so everything volatile - the model catalog, prices, the availability of beta features and team policies - is shown here as a dated snapshot, while the current state is always checked with a live command and the official page rather than from memory. At the end there are a glossary and references for surfaces, permissions, configuration and commands.