Devin Cloud is easiest to picture as the same Devin, only more powerful and not tied to a laptop. Half of that is true and therefore dangerous. A cloud session does run on its own VM with a desktop, a browser and computer use, and it keeps working after you close the laptop. But the words more powerful and without a laptop also mean in a different environment, and it is exactly this part that the naive picture omits.
The naive move from here is to throw the current local task into the cloud as is and expect it to continue from the same place. It seems logical: the agent is the same, the repository is the same, so the state must be the same. The first handoff action reinforces that feeling - the transfer looks like a continuation in the cloud, in one motion.
It breaks at the environment boundary: a separate VM is a separate filesystem, a separate network and a separate state. The cloud does not see your local uncommitted state: only what reached the repository and the environment configuration goes to the cloud. Uncommitted edits, locally running services, variables from your shell - all of it stays on your machine, and the agent in the cloud honestly works without them.
The professional mechanism here is to assemble the task's environment explicitly rather than to hope for an invisible transfer. To the cloud you pass the repository and the branch, the setup steps, the secrets through a supported mechanism, and the acceptance criteria. The result comes back not as changes on your disk but as a branch and a pull request that you then review. That is, the cloud is not a continuation of your session but a standalone run from a fixed state. Setup describes how the environment is brought to a working state: installing dependencies, migrations, starting the needed services - everything long since done on your machine and therefore invisible, which in a clean VM must be performed anew.
Why the cloud is built as a separate surface rather than a remote copy of your laptop. A long horizon is possible precisely because the VM does not depend on your machine: it survives a closed lid, a dropped network and a client restart. The price of that independence is exactly that the cloud knows nothing you did not hand it explicitly. You cannot be both independent of your machine and able to see its unfixed state - it is the same boundary taken from two sides.
The cost of ignoring this boundary is double. The first is functional: a task that needs your local services or uncommitted files will honestly run in the cloud with the wrong state, and the result will miss. The second is security: a separate machine is a separate attack surface. Network policy, repository access and secrets are set to the minimum, and production credentials are passed neither into the prompt nor into tracked files - there they would outlive the task and become a leak.
The cloud is justified where a long and isolated run is exactly what is needed: an extended reproduction, a broad test run, a separate PR, a task that benefits from a clean environment without your local clutter. The sign of such a task is that you do not mind closing the laptop while it runs, and you can describe its input and output without referring to whatever is open on my machine right now. It helps to gauge in advance whether the task reproduces on a clean machine from the description alone - if not, it is first brought to reproducibility and only then sent to the cloud.
You should judge the result of cloud work by the pull request in a clean environment, not by the feeling that the agent did something. Green checks in the cloud are valuable precisely because they passed without your local scaffolding: if a test is green there, it rests on the passed environment, not on a service you happened to have running. The diff in the PR is read the way any external diff is - because to your machine it is external.
Hence the engineering conclusion: treat a cloud task as a run on someone else's machine, not as a continuation of your own. Everything needed to reproduce and verify must be inside the repository, the environment configuration and the acceptance criteria; everything you keep in your head or uncommitted does not exist for the cloud. This is a consequence of the design, not a nitpick: the environment boundary is objective and is not bypassed by a convenient assumption.
The typical failure is the agent in the cloud does not see my file and why do the tests fail, everything is green locally. The symptom is one: the state you counted on stayed on your machine - uncommitted, in a local service or in a shell variable. Before blaming the agent, check that everything needed is committed and passed, and that secrets were passed through a secure mechanism rather than as a line in the prompt - most often the discrepancy is explained by exactly the environment boundary.