The install is two clicks and a sign-in, and the interesting part happens after the second one. The extension itself is deliberately thin: a side panel, an inline diff viewer, and a renderer for the agent's plans and artifacts, sitting on top of the VS Code install you already have [3]. The code that does work is not in there. On first launch the extension silently installs a local `agy` backend service, the same engine that powers the standalone desktop app and the CLI [4]. Planning, terminal execution and the browser subagent all run in that runtime, powered by Gemini [6]. A service that installs itself so you never have to open a terminal is convenient, but it is still worth knowing what it is listening on.
Because the backend is shared, one authentication carries the same entitlement, permissions and conversation history to every surface [5]. Four editor extensions [2], plus the desktop app and the `agy` CLI [13], add up to six front ends over one machine-local process and one credential [14]. The permission decision is therefore made once, on the account and the daemon, and not per editor.
The dev.to walkthrough [15] states two configuration objectives before it gets to any demo: configure the permission engine so the agent only does what you approve, and lock down the browser subagent so it never touches your personal Chrome data [7]. The second one is the tell. That step only makes sense if the component is not already isolated. What the excerpt does not print is the setting name or its shipped value, and the default is what an engineer who clicks Install actually inherits. The post confirms a permission engine exists, but the actual defaults are not something I can cite.
There is a real gate in the workflow. For any non-trivial request the agent produces an implementation plan rather than editing files straight away [11], and while a task runs, a toolbar above the input tracks open file changes, running terminal processes and any artifacts produced [12]. For that to function as review rather than as a progress indicator, the plan has to enumerate the terminal commands before they execute and let you refuse them individually. The material describes the tracking; the granularity of the refusal is left unstated.
The engineering is clean: a thin UI shell sits on one runtime, with sign-in unified across the app, the CLI and the editors [5]. That design is also precisely why the evaluation moves off the editor. In my context I would give this a container with a repo checkout and a throwaway browser profile before I gave it my laptop and my logged-in Chrome, and the reason is the runtime's terminal and browser reach [6], not anything about the model.
