Security and privacy
Where credentials live, what leaves the machine, and how the panel is architecturally kept from touching your filesystem directly.
Credentials
Your ML.ai access token is stored in VS Code's SecretStorage and passed only to the locally-launched engine process, through its environment. It's never returned to the panel after saving, never displayed again, and never included in copied diagnostics.
ML.ai requires its own access token. It does not migrate or reuse an existing OpenCode CLI credential already configured on the same machine: every install starts signed out.
The engine's network posture
The bundled engine listens on localhost only, behind a generated password. Every call the engine makes is checked against a central blocked-endpoint policy before the request goes out.
Architecture
Panel (React, presentation only)
→ editor message passing →
Extension host (Node: validation, secrets, filesystem, engine lifecycle, routing)
→ authenticated localhost HTTP/SSE →
Bundled engine
→ model provider / MCP servers / editor's language serversThe panel itself has no filesystem, process, or network access of its own. Every message it sends is validated on the extension-host side before anything happens. This boundary is enforced by an automated test, not by convention alone.
What actually leaves the machine
| Data | Destination |
|---|---|
| Prompts, selected file content, tool results | The configured model provider |
| MCP tool input | The specific MCP server that tool belongs to |
| Everything else | Nowhere |
Blocked at the network layer
These are blocked by policy, not merely unused: a stray call, a future feature, or a compromised panel message can't reach them either.
| Route | Why |
|---|---|
| Terminal UI routes | Not applicable to an editor extension |
| Interactive PTY routes (current and legacy) | No user-facing surface this release |
| Engine self-upgrade | The engine is versioned together with the extension |
| Session sharing (create and revoke) | Would publish prompts, file contents, and command output to a public URL. Verified against a live engine. Both directions are blocked so create can't be re-enabled through a working revoke path, or vice versa. |
Two decisions that change your safety posture
Both are designed to be visible rather than silent:
- Always on a permission prompt: creates a persistent rule, saved globally when the workspace isn't a Git repo. Mitigated by the saved-permissions list with per-rule revoke. See permission prompts.
- Auto-approve: answers prompts immediately. Mitigated by being loud when on, off by default, never persisted, and answering once rather than durably. See auto-approve.