Connecting VS Code and IntelliJ to the Forge Network

The fastest way to kill adoption of a secure coding assistant is to make engineers leave their editor to use it. A tool that lives in a separate browser tab, requires a context switch to paste code into, or breaks muscle memory built over years in VS Code or IntelliJ will get used exactly as often as policy forces it to be used, and not once more. Forge's premise is that a sealed appliance and a native IDE experience are not in tension. The sealing happens at the network boundary, not inside the editor, so the day-to-day experience of writing code with Forge should feel almost indistinguishable from writing code with any other assistant, minus the part where anything leaves the building.

The editor is the interface, the appliance is the backend

It helps to be precise about what actually changes when Forge sits behind an IDE plugin instead of a cloud API. VS Code and IntelliJ both already speak a well-worn pattern for AI assistants: an extension in the editor captures context (open files, cursor position, relevant symbols) and sends a request to a completion or chat backend, then renders the response inline or in a side panel. Cloud copilots point that request at a vendor's endpoint over the public internet. Forge points it at an address on the enclave's own network.

Nothing about the editor-side experience has to change to make that true. The Forge extension for VS Code and the Forge plugin for IntelliJ implement the same interaction patterns engineers already expect: inline completion as you type, a chat panel for multi-turn questions about the codebase, explain-this-function and generate-tests affordances tied to a selection. What's different is invisible at the UI layer: every one of those requests resolves to a host inside the boundary, is answered by a model that has never seen a token of training data from outside it, and never touches a network segment that can reach the public internet. The plugin is thin by design. The intelligence, the repository index, and the retrieval layer all live on the appliance side, which is also why the plugin has so little to be compromised through. It is a client, not a cache of anything sensitive.

What "connecting" actually means here

Connecting an IDE to Forge is closer to pointing an internal tool at an internal service than it is to authorizing a SaaS integration. There is no OAuth flow against a vendor identity provider, no API key issued by Element 31, no external account to create. Authentication runs against whatever identity provider already governs access inside the enclave: the same directory service that gates the internal wiki or the internal issue tracker governs who can address the Forge endpoint and with what scope. From the network's perspective, a developer's laptop opening VS Code and reaching Forge looks exactly like that laptop reaching any other internal service on the LAN: a request that never crosses the enclave boundary in either direction.

That has a practical consequence for how security teams evaluate the plugin during onboarding. There is no egress rule to add, because the plugin has nowhere to reach outside the segment it's already on. Reviewing it is a matter of confirming what the extension talks to, one internal address, one internal identity provider, rather than auditing a list of third-party domains, telemetry endpoints, and update servers the way a typical marketplace extension would require. Teams that have been through an extension security review before tend to find the Forge review shorter, not because the bar is lower but because there is categorically less surface to review.

VS Code and IntelliJ, treated as peers

Forge does not treat one editor as primary and the other as an afterthought. Engineering organizations in Element 31's buyer base are routinely split: backend and infrastructure teams gravitating toward IntelliJ and its JetBrains siblings, other teams standardized on VS Code, and a coding appliance that only serves one half of that population would leave the other half exactly where it started, working without repo-aware assistance or, worse, working around the appliance with something ungoverned. Both plugins are built against the same underlying Forge interface, so a completion, a chat answer, or a repository-grounded explanation should behave consistently regardless of which editor asked for it. The model doesn't know which IDE is on the other end of the request; it knows the repository, the query, and the context window it was given.

That consistency matters more than it might sound like it should, because it's what lets a security team write one policy instead of two. Data handling, logging behavior, and what does or doesn't leave the enclave are properties of the appliance and the network path, not of which editor plugin happens to be installed. A review that covers the VS Code integration covers the architectural claim for IntelliJ as well. The editors differ, the boundary doesn't.

Rollout without a re-education campaign

The reason IDE-native integration gets called out as its own concern, rather than treated as a footnote to "Forge has an API," is adoption economics. Security and platform teams can mandate a tool; they cannot mandate that engineers like using it, and a tool nobody likes gets quietly routed around. Because the Forge extensions sit inside the editors teams already run, rollout looks like a plugin install pushed through existing endpoint management, not a new application to learn, a new workflow to document, or a new browser tab engineers have to remember to open. The repository index that makes Forge's answers relevant to your codebase, rather than to code in general, builds automatically once the plugin is authenticated. Engineers don't maintain that index by hand any more than they maintain a local search index for their IDE's built-in symbol lookup.

The tradeoff, and it is a real one, is that the plugins can't reach out to a marketplace for arbitrary third-party extensions the way a normal IDE setup can. That permissiveness is exactly the surface a sealed deployment exists to remove. Teams evaluating Forge should expect the editor to feel familiar and the extension ecosystem around it to feel deliberately smaller. For a development environment where the entire point is knowing precisely what can talk to the codebase, that reduction isn't a missing feature. It's the same design discipline that governs the rest of the appliance, expressed at the one surface every engineer touches all day.

Where this sits in the line

The IDE integration is Forge doing what Forge is for: putting a repo-aware coding assistant in front of engineers who work on source that cannot be sent to a cloud model, without asking them to change how they work to get it. It is not a general-purpose model access layer: Czar is where training and fine-tuning workloads on sensitive data live, and it is not a hardware program built around one buyer's specific deployment, which is Chassis territory. Both plugins run against the same Substrate platform underneath every appliance in the line, so the guarantees a security review establishes for the editor integration are the same guarantees that hold everywhere else Forge is deployed.