In Cascade, auto-executing commands looks like a clear settings panel: four levels - Disabled, Allowlist Only, Auto and Turbo - plus two lists of terminal commands, allow and deny. The panel is familiar from the Windsurf era, and the first impulse when moving to Devin Local is natural: carry these settings over one to one, the way you carry a config from an old editor into a new one. The words are the same, after all - allow, deny, level of autonomy.
The naive move is treacherous precisely because almost everything in it sounds plausible. Allowlist Only resembles an allow rule, the deny list resembles a ban, Turbo resembles full freedom. It seems enough to rewrite the same patterns in the new place and the agent will behave as before, just under a new name. The expectation rests on a similarity of vocabulary, not a similarity of mechanics.
It breaks at once on a fact from the documentation: Cascade's auto-execution levels do not apply to Devin Local at all. Devin Local knows nothing of Disabled, Auto and Turbo - it has a different model: permission rules deny, ask and allow over tool scopes, a separate permission mode and a system sandbox. Between Allowlist Only and Turbo, Cascade also has an intermediate Auto, where the model itself judges safety and anything risky still goes to confirmation - but it too stays part of a different model, not a switch of Devin Local. There is nothing to carry over in terms of switches; what must be carried over is the intent behind each legacy pattern.
The most dangerous divergence hides in the word deny. In Cascade the deny list is a soft boundary: a command on it will never auto-execute, but the agent will always ask for confirmation, and a human can still run it. In Devin Local deny is the highest priority: the rule is checked before ask and allow, and on a match the action is blocked immediately and overridden by nothing. The same word in two environments gives the opposite guarantee - there, a pause before running; here, a wall.
Hence the working technique: carry over not the syntax but the intent, and re-examine each pattern one by one. For every legacy rule, ask what you actually wanted - for the action to run on its own, to always ask, or to be impossible. The answer decides which of the three scopes - allow, ask or deny - it falls into in Devin Local.
A short map below helps lay out the typical intents. Allowing tests automatically is an allow on Exec(npm test). Always asking before a git mutation is an ask on Exec(git) together with narrow allows for the safe status and diff, so that reading does not prompt you needlessly. Never running sudo is a deny on Exec(sudo), and now that is a real ban, not a request to confirm. Full autonomy is not Bypass but a combination of Sandbox and Autonomous: freedom to act inside a boundary the operating system holds.
| Legacy intent | Devin Local |
|---|---|
| Allow tests automatically | allow Exec(npm test) |
| Always ask before git mutation | ask Exec(git) plus narrow allow for status/diff |
| Never run sudo | deny Exec(sudo) |
| Full autonomy | Sandbox + Autonomous, not Bypass |
Why this way and not a single Turbo toggle. Devin Local separates two axes: how much the agent does without asking, and what it is physically allowed to do. Turbo blended them into one sense of omnipotence - auto-execute everything except deny. Devin Local separates the permission mode from the sandbox, so wide autonomy need not mean removing protection: the agent can act without confirmations and still stay inside a sandbox that does not let it past the permitted paths and network.
The cost of ignoring this distinction is two-sided. Copy a Cascade deny literally, and a soft request to confirm turns into a hard wall: a command you did sometimes run by hand is now unavailable entirely. Confuse it the other way - reproduce the feel of Turbo through Bypass - and you remove the sandbox where you only meant to drop the extra confirmations, handing the agent not freedom inside a boundary but the boundary itself.
You must verify the migration not by eyeballing the config but by behavior in Devin Local. Run a command from deny - it should block at once, not ask. Run an allow - it should pass without a question. Run an ask - it should stop and ask. Three short runs on the Devin Local machine itself, not in Cascade, show that the intent was carried over correctly rather than merely rewritten in similar words.
The typical failures grow from one root - carrying over syntax instead of intent. A rule "stopped letting things through" - because a Cascade deny became a hard deny in Devin Local. The agent "suddenly started doing everything itself" - because Turbo was mentally equated with Bypass and the sandbox was dropped. A rule "did not work" - because a Cascade level was written where it does not exist. The sign is the same: a legacy switch was carried over as is, without once asking what it was after. Ask about the intent first, and most of these surprises do not happen.