Install the complete code assistant

Lemniscate provides the confined execution environment for code agents, deployed inside your perimeter. Where no agent, no model proxy and no inference engine are in place, Lemniscate also provides the extension for VS Code, JetBrains and the terminal, the agent, the model access gateway and the setup of the inference server. This page describes what gets installed, on which machine, and points you to the page that covers each element.

If you already have an agent, a model proxy and an inference engine, the path for you is Integrate Lemniscate into your stack.

The four roles

The reference architecture separates four roles, each on a physical or virtual machine (security white paper V3, section 3.1).

Role	What it carries	What it connects to
Developer workstation	The extension alone: instruction, diffs, validation requests.	The gateway, over TLS, and nothing else.
Gateway services	The gateway, its database and the administration console.	The execution host, the engine, the directory, the SIEM.
Execution host	One sandbox per session, with no network, with a copy of the repository.	Nothing: it never initiates a connection.
Inference server	The engine and an open-weights model.	Nothing: only the gateway host connects to it.

None of these flows leaves your perimeter, and no component sends data to the vendor (security white paper V3, sections 3.3 and 11.3).

The setup order

Each role depends on the one before it in this list.

1. The inference server. The gateway serves nothing as long as no engine answers behind it.
2. The gateway services. The database, then the gateway and the console. This is where you declare the engine, the accounts or the directory, and each project’s policy.
3. The execution host. The gateway opens one sandbox per session there.
4. The workstations. The extension knows only the gateway’s address.

Installation and every update start from signed artifacts, delivered through a private registry or on media, and are applied by your team. Neither the services nor the extensions update themselves (security white paper V3, section 9.3).

The inference server

The gateway connects to any engine that exposes an OpenAI-compatible API (security white paper V3, section 3.4). The model is open-weights, and you can replace it without changing the session guarantees: they are held by the gateway and the sandbox, not by the model. For agent sessions, the white paper recommends an Artificial Analysis intelligence index of at least 34, as a criterion of effectiveness and not of security (section 8.1). It also recommends the safetensors format and verifying the fingerprint of the weights (section 8.2).

The engine listens only on the inference server’s internal network, and your filtering allows only the gateway host to reach it. Neither the extensions nor the sandboxes know its address.

Once the engine is running, you declare it to the gateway: Declare a model served by the gateway.

The gateway services

The gateway authenticates the developer, applies the project policy, drives the session, logs and revokes. The database holds the accounts, the policies and the log. The console is reserved for administrators (security white paper V3, section 06).

• Discover the gateway brings up the three services on one workstation and routes a first call through them. This is a discovery setup, not a production procedure.
• Open the administration console describes the first opening of an installed console.
• Set workstation policy from the console describes what the administrator grants and withdraws.
• The gateway refuses to start covers each shutdown message at startup.

The execution host

The sandbox runs on a dedicated host or on the workstation (security white paper V3, section 4.4).

The dedicated execution host is the reference mode. Sandboxes run there on a machine separate from the gateway’s, no container engine is required on the workstations, and the execution environment is single and hardened by the administrator. This mode is the one chosen for sensitive and Restricted Distribution perimeters.

The variant runs the sandbox on the workstation, in an unprivileged container with no network. It suits cases where the workstation baseline already includes a container engine. What the workstation must then provide is described in Prepare the terminal session container.

The choice is made per perimeter, with your security officer.

The workstations

The delivery archive contains the three forms of the extension.

• VS Code: Your first session in VS Code goes from the archive you received to a first answer about your code.
• JetBrains: Edit code with Lemniscate in a JetBrains IDE.
• Terminal: the lemni command, described in CLI commands.

Each developer receives the gateway’s address and the means to authenticate to it from the administrator: Give an API key to a team.

Where to start

• You administer the deployment: start with Discover the gateway.
• You are a developer and your organization’s gateway is answering: follow Your first session in VS Code.
• You are a security officer: Verify that no data leaves establishes, on the delivered artifacts, that they emit nothing.

Once you have your first session, Delegate a task to a subagent shows how to hand part of the work to a secondary agent.