Remote development seems to be just the same thing, only on another machine. In an agentic IDE it is not: when the code, the config, the terminal and the secrets live on different machines, the question of where exactly an action runs stops being obvious - and it is on that question that all of the agent's security rests.
The naive move is to assume that since there is one editor window there is one environment: a permission, a path and a command work where you are looking at the screen. Local intuition is carried onto the remote automatically and usually unnoticed - until the first divergence, when a deny does not fire and a command goes to the wrong place.
It breaks on the fact that the place of execution diverges from the place where you sit. Devin Desktop carries its own Remote-SSH for Linux hosts, and third-party Microsoft Remote-SSH or open-remote-ssh may conflict with it - two extensions fight for one role, and behavior becomes unpredictable. Dev Containers work with local and remote Docker and the reopen, attach and logs commands. WSL is marked beta. In each of these cases the agent may act not on your machine.
It is worth separating these scenarios, because each has its own mechanics. Remote-SSH moves the whole session to a Linux host, and the built-in client is best kept alone, without third-party ones on top. Dev Containers give a reproducible environment in Docker: reopen opens the project inside the container, attach connects to an already running one, logs shows what happens there. WSL is a beta bridge into the Windows Linux subsystem, convenient but marked early, and leaning on it as a stable foundation of the process is premature. Knowing which of the three scenarios you have matters more than remembering their names: it decides where to look for a file, a config and a failure.
The key shift is fixed in the changes: in stable 3.7.16 Codemaps and the MCP config open from the remote machine for WSL, SSH and a dev container. So the code index and the tools are taken from where the code lives, not from where the window is open. That is correct in substance - the agent sees the project's real filesystem - but it overturns the naive picture of locality you are used to.
The professional mechanism is simple: before launching the agent, map the layers. Where the workspace lies, where the config is, where the MCP process runs, where the terminal is and where the credentials are. Five answers set which machine does what and remove most future surprises before the agent's first action, not after the post-mortem of why it did the wrong thing.
Why this matters more than it seems. A permission glob and executables may resolve on the remote host, not locally. A deny written for a local path may, on the remote machine, point at nothing or somewhere else. The security boundary follows the filesystem, and the filesystem is now someone else's - and a rule correct locally can silently fail to fire on the host, leaving open what you thought was closed.
The cost of a false assumption of locality is concrete: a command run in the wrong place; a deny that did not fire on the remote; a secret duplicated across two layers and leaked from the less protected one. The last is especially treacherous: the same token placed both locally and on the host is protected by the weaker of the two layers, not the stronger, and one hole is enough to void the second protection. So a secret is kept in one place per layer, not smeared between local and remote for convenience.
When the remote layer is justified. When the code and its environment truly live on a host, in a container or in WSL: the closeness of the tools to the code matters more than the convenience of a local window, and reproducibility of the environment is worth its overhead. If the project is local, an extra remote layer adds nothing but new places to go wrong - and it should be removed, not tolerated out of habit.
Verify not memory but the approval card. Before confirming an action, look at the CWD in the card - it names the real directory and machine where everything will happen. Confirm that the permission glob covers the very filesystem where the agent runs. If you work through a third-party Remote-SSH, check that it does not conflict with the built-in one, and keep just one on a conflict. These glances take seconds and remove a whole class of confusion.
The typical failure is keeping one secret across several layers; writing a deny for a local path while executing on the remote; installing a third-party Remote-SSH over the built-in one and hitting a conflict; taking WSL beta for a stable foundation of the process. The sign is the same: an action is discussed as if it will run the same anywhere. Name the layer and look at the CWD - and the difference you were missing becomes visible before, not after, the action.