FusionAI for VS Code

FusionAI brings project-linked AI Chat, explicit workspace context, read-only analysis, and reviewable code proposals into VS Code. It uses the same FusionAI account and backend as the web product; it does not install a separate model provider or require a provider API key in VS Code.

Get started

1. Open a local folder in VS Code. Trust the workspace before sharing source or requesting edits.
2. Run FusionAI: Sign In from the Command Palette or the FusionAI Activity Bar view. Complete sign-in in your browser and allow the return to VS Code.
3. Run FusionAI: Select Project to select an existing FusionAI project or create one, then link it to this workspace. The workspace-to-project mapping and IDE chat history are stored locally in VS Code; they do not sync with web Chat.
4. Run FusionAI: Ask to open streamed Chat. You can cancel an in-progress response.

The built-in fusionai.serverUrl default is the production FusionAI service at https://divine-benevolence-production.up.railway.app. A local server is used only if you explicitly set this preference to http://localhost:3000. Non-local HTTP origins are rejected. Switching origins cancels pending sign-ins and separates credentials by origin; sign in separately to each server.

Chat and workspace context

Plain Chat does not read your files. You can explicitly attach the current file or selection, or use FusionAI: Add Context for a cursor symbol, a bounded set of files, text-search results, Problems, and Git changed-file diffs. Symbol context uses the editor's language provider, is previewed by name/path, and is revalidated against the same document version before sending. Editor actions such as Explain, Debug, Review, Refactor, and Generate Tests prepare a prompt and context for your review; they do not send automatically.

Analyze Workspace is a separate, bounded read-only workflow. It asks for run-scoped permission before file tools are used. Its tools list/search/read files and diagnostics, inspect the symbol at your cursor, find definitions/references/workspace symbols through VS Code language providers, and discover resolved relative imports. Symbol locations and import paths are retrieval hints, not proof of file contents; the agent must read source to describe implementation. The run shows its procedural phases and completed tool activity. You can cancel it. It cannot execute commands or write files.

FusionAI: Verify Workspace (Approved Commands) is a separate opt-in run that may request a small set of typed Git status/diff checks, npm lint/typecheck/test/build scripts, or npm install --ignore-scripts. It is not an arbitrary shell. Every command requires its own modal approval showing the working directory, risk, and package script where applicable. Unknown or destructive commands are blocked. Execution has a timeout, bounded output, cancellation, a sanitized environment, and a local metadata-only audit record. Verification scripts are project code and may have side effects, so review the displayed script before approving.

FusionAI: Runtime Status, Start Managed Dev Server, and Stop Managed Dev Server provide a local development-server workflow. FusionAI can start only a recognized local dev script after approval, tracks that child process, and stops only servers it started. Status probes a small set of loopback ports; an HTTP listener discovered there is not attributed to your project without matching managed-process evidence. A newly started process is not called ready until a later status observation confirms a response. Managed processes are stopped on extension shutdown. The Verify Workspace agent can request the same bounded runtime tools, with separate approvals for start/stop.

FusionAI: Inspect Local or Staging App starts a separate bounded agent run with browser tools in addition to the approved workspace/runtime tools. It uses a fresh isolated headless Edge/Chrome profile; it does not attach to your personal browser or copy its cookies. Navigation is limited to http://localhost:<port> or exact HTTPS origins you add to fusionai.browserStagingOrigins. The FusionAI production origin is excluded. Every navigation, click, fill, reload, and screenshot needs a separate modal approval. The browser blocks off-origin requests and WebSockets. Bounded visible text, sanitized console warnings/errors, and network method/path/status/timing metadata can be shared with FusionAI; request/response bodies, headers, cookies, and query strings are not sent. Screenshots open locally in VS Code and are not sent to the model; the agent cannot make visual claims from their pixels. Approving a click or fill can change the staging/local app's state. Browser access requires an installed Microsoft Edge or Google Chrome binary; no browser download is included in the VSIX.

FusionAI: Architecture Review uses those same approval-gated repository, runtime, and local/staging browser tools in a longer bounded investigation. Its report separates Observed in browser, Confirmed in code, Confirmed at runtime, Inferred, and Unknown. A listed path or language-server hint is not proof of implementation; a browser screenshot captured only for your local review is not visual evidence for the model. If a source, server, or page cannot be inspected, the report should say so instead of guessing.

FusionAI: Inspect Connected Services uses your existing FusionAI server-side connections to discover and call reviewed read-only MCP tools. Each discovery and read requires its own approval showing the connector, tool, and bounded arguments. The extension never receives GitHub, Railway, Supabase, or other provider credentials. Currently supported read surfaces include GitHub, Railway project/service metadata, Supabase schema/documentation metadata, Linear, Notion, Google Drive, and Slack where connected in FusionAI. Remote mutation tools, deployments, SQL execution, credential/key reads, and unreviewed tools are not exposed by the IDE bridge. Supabase's hosted connection uses read-only mode and restricted feature groups. The server and extension both withhold large or secret-like results; external results remain untrusted data, not instructions. Connect or reconnect services in the FusionAI web settings first.

FusionAI: Run Coding Skill opens the first-party server catalog: Architecture Review, Security Audit, Test Writer, Release Review, UX Debug, and Documentation. Pick one, then enter a task. A skill narrows the instructions and declares a fixed repository/runtime/browser tool profile; it does not pick a model, bypass approvals, or write files. Test Writer and Documentation return drafts for review in Chat. Use the separate proposal commands to make changes. Release Review can request approved checks, but never publishes or deploys.

FusionAI: Controlled Engineering Workflow coordinates a single task through plan, read-only source inspection, a human-selected multi-file proposal, one approved package test, approved local/staging browser inspection, and a final report. You explicitly continue at every checkpoint. Each source read, edit application, command, and browser action retains its own approval; the workflow cannot skip phases or apply a model-selected path. It stops if a phase fails or the 20-minute between-phase budget expires, then reports only completed checkpoints. Long individual phases have their own limits. Browser-tool success is not proof that the requested behavior passed; read the browser-stage observations and limitations. This is not unattended autonomy, deployment, or release automation.

FusionAI: Propose Change targets the active file or exact selection. Describe the requested change, review the result in VS Code's native diff, then choose Apply or Reject. Apply uses a VS Code workspace edit, leaves unsaved buffers unsaved, and supports normal Undo. If the source changes while a proposal is pending, Apply is blocked and you must generate a new proposal.

FusionAI: Propose Multi-File Change lets you explicitly select up to six modify, create, rename, or delete operations. Only selected modify-file contents are sent to FusionAI after a source-sharing confirmation; the model returns replacement text for selected modify/create targets and cannot choose paths or perform local file operations. Review each native diff, then Apply All or Reject All. Apply rechecks every source fingerprint/version and destination before a single VS Code WorkspaceEdit. Deletions require a separate confirmation. VS Code guarantees all-or-nothing for text-only WorkspaceEdits; resource operations such as create/rename/delete can stop after an earlier operation on failure. FusionAI attempts to restore recognized partial changes, but you should inspect the workspace if VS Code reports an apply failure. The reviewed proposal remains available until applied or rejected.

Source sharing and security

Source context is opt-in. When you send attached context or approve read-only analysis, the selected content or tool results are transmitted to the FusionAI backend and may be processed by its model providers to answer your request. The extension does not silently index your repository. It requires a trusted, local file workspace for source access and edits; it rejects paths outside the workspace, symlink escapes, hidden and common secret files, and detected high-confidence credentials. These safeguards cannot detect every secret, so review context before sharing it.

Sign-in uses a browser-mediated, one-time authorization code and PKCE. The code returns to vscode://balochdev.fusionai/auth-callback; access tokens are not placed in the callback URL. Sessions are stored in VS Code SecretStorage, scoped to the configured server origin. Sign Out removes the current origin's local session and pending authorization state; it does not revoke an existing browser session or tokens held by other clients.

FusionAI: View Local Action Audit shows the last 100 locally stored metadata records for approved or attempted terminal, browser, connector, and edit actions. It never displays source, prompts, tokens, command output, or connector results. FusionAI: Show Diagnostics shows only the extension version and aggregate local action outcomes/timing. Neither command uploads telemetry or opens a support ticket; review any copied information before sharing it with support.

Current limitations

• IDE chat history and project links are local to VS Code; they are not the same as web conversations.
• Multi-file proposals are explicitly target-selected and human-applied. Terminal tasks are limited and separately approved; there is no unrestricted shell or autonomous file editing.
• Workspace analysis is read-only, limited in scope, and requires approval per run. It is not an autonomous engineering agent.
• Local file workspaces are supported for source context and edits; remote/virtual workspaces are not yet supported for these flows.
• Symbol/definition/reference results depend on the installed language extension and may be unavailable; relative-import discovery currently covers bounded relative module imports, not package-manager dependencies or a persistent semantic index.
• Runtime management supports recognized local next dev, Vite, and Astro scripts in the first workspace folder. It does not take ownership of a server that was already running or deploy to staging/production.
• Browser inspection uses an isolated unauthenticated profile. Cross-origin assets are blocked, so pages relying on external CDNs may render incompletely. Screenshot pixels remain local evidence; model-side visual analysis is not yet wired. Browser evidence is not proof of private infrastructure.
• Connected-service inspection requires an existing per-user OAuth connection and can only call a small reviewed read subset. Railway/Supabase connection and tool discovery still need live owner verification; no write/deploy/SQL workflows are provided through this IDE bridge.
• Live end-to-end acceptance of every IDE-HARDEN-1 flow remains in progress. Packaging and automated tests alone do not establish that gate.
• Team-wide policy administration, centralized audit retention, and production SLO monitoring are not available in this release candidate. IDE project access is enforced for the signed-in user by the existing FusionAI backend; this is not an organization-governance system. Operational diagnostics are local and user-invoked, with no automatic telemetry upload.

For problems or feedback, use the support options in the FusionAI web app.