What does not exist

This page lists what Lemniscate does not do. It has two parts: the product’s negative commitments, taken from the security white paper V3 (section 11.3), then the surfaces inherited from another project, which appear in the product and lead nowhere.

No source code index

Lemniscate builds no index of your source code. The agent explores the repository on demand: it lists folders, searches files for a pattern and reads the ones it needs, during the session (security white paper V3, sections 3.2 and 11.3).

So there is no derived, persistent copy of the code: no embeddings database, no repository map kept from one session to the next. The source code lives on the workstation and in the sandbox’s working copy, which is destroyed along with it (security white paper V3, section 8.3).

There is no embeddings model to declare, and no setting enables indexing. If a product screen brought you here by offering to add an embeddings model, no action is expected from you.

The other negative commitments

Each of these commitments corresponds to an absence of code, which an audit can verify (security white paper V3, sections 3.3 and 11.3).

No data sent to the vendor

The product sends nothing to the vendor: no telemetry, no error report, no license check. It contains no usage reporting function. No component has a destination outside your perimeter, and you can verify this on your own network with the flow matrix (security white paper V3, sections 1.3 and 3.3). The flow details are in Where the data goes.

No training on your code

No customer data is used to train or fine-tune a model. The model is yours, served by your inference engine; the product only passes it the context of a request, for the duration of that request (security white paper V3, sections 1.3 and 8.3).

No identity, no secrets, no network for the agent

The agent has no account and no identity on the forge. No key, no token and no environment variable from the workstation is mounted into the sandbox. The sandbox has no network interface: no destination is reachable, external or internal (security white paper V3, sections 4.1 and 4.3).

So the agent pushes nothing. You integrate the approved diff under your own identity, with your usual tools and through your review process.

No direct channel from the workstation to an execution machine

The workstation talks only to the gateway: that is its only Lemniscate-related flow. No route exists between the workstation and the execution host, or between the workstation and the inference engine, and the extension knows only the gateway’s address. The control channel to the execution host is opened by the gateway, and by the gateway alone (security white paper V3, section 3.3).

So no command links a workstation to a session running on another machine, and no workstation acts as a session for another workstation.

No change without your approval

Nothing is applied to your repository without a human decision. Every write the agent keeps is presented to you as a diff, and you accept or reject it (security white paper V3, sections 4.1 and 5.4). The sequence is described in The lifecycle of an agentic session.

No automatic updates, no external service

Neither the gateway services nor the extensions update themselves. An update is delivered by the vendor, through your private registry or on media, then verified and applied by your team; the previous version is kept for rollback (security white paper V3, section 9.3).

The product runs without any external service: isolated mode has no connection to the vendor (security white paper V3, section 3.4).

The inherited surfaces

Lemniscate comes from another project. That project came with an online service, a control plane and a registry of shared content, and part of the workstation code still knows how to talk to it.

That service is not operated. The commands, settings and screens that depend on it exist in the product: they are displayed, they autocomplete, they appear in the help. They lead nowhere.

The sections below name them, because these paths fail late, with messages that look like configuration errors.

How to verify this

You can see it in the repository:

• the address of the vendor control plane lives in core/control-plane/adressesDeLEditeur/; in an installation that designates no control plane, the address fields hold a sentinel value that no HTTP client can reach;
• the repository contains no server half of this service;
• the artifact built for a customer installation (profile on-premise) replaces the modules that talk to this service with absent twins, which refuse and name the reason (packageRegistry, depotDeSession and sessionsHebergees in extensions/cli/src, core/egress).

On the CLI side

A vendor account. There is no identity service operated by the vendor, and lemni login does not address one: the command asks your deployment where your corporate directory is, and signs a named person in against it. Faced with a deployment that publishes none, it refuses with one sentence naming the administrator to contact. lemni logout clears the session stored on the workstation.

What does not exist is the vendor account, not the sign-in.

Published content. The flags --rule, --prompt, --mcp, --agent and --config accept a propriétaire/paquet identifier, which designates a resource published in an online directory. That directory is not operated. Such an identifier stops the session with a refusal that names what was requested and the local form that replaces it.

Each of these flags has a local form, which works: a file path for all five; text given inline for --rule and --prompt; an address for --mcp; the name of an agent discovered in the project’s .lemniscate/agents/ or in your home directory for --agent.

--org <slug> designates an organization to the control plane and does not resolve here. --model <nom> names a model that your configuration declares; it resolves locally and works.

Hosted execution. lemni remote creates a workspace through a central service, and lemni remote --id asks that same service for the tunnel to a running session. The on-premise artifact refuses both paths and names the reason.

Storing a session outside the perimeter. The original project stored a session’s conversation and diff in storage managed by its vendor, and uploaded screenshots and logs there. The on-premise artifact does not carry these paths. A session is reconstructed from the logs kept by the gateway services (security white paper V3, section 7).

Updating from the workstation. /update installs nothing: Lemniscate is not published on npm, and the on-premise artifact reports no version to install. An update is delivered to you, then your team verifies and applies it; see No automatic updates.

A less visible fallback. The root command lemni reads a ~/.lemniscate/workstation.yaml file. Without it, and with no open session, configuration resolution falls back to a remote default configuration, which it requests from the missing API, and startup fails. This is not a flaw in the local configuration: it is the fallback going elsewhere to look. A local configuration file makes the CLI self-contained.

On the VS Code extension side

Background agents. The background mode and the actions that go with it (create an agent, list agents) go through the control plane client. The path also requires a repository hosted on GitHub.

Account sign-in. The authentication provider and the lemniscate:// link handler are registered when the extension starts, which makes the entry point visible. Creating a session refuses and says why: its target is the service that is not operated.

On the configuration side

The uses: block. The workstation.yaml schema accepts the uses: propriétaire/paquet form everywhere, with with: and override:, to reuse a block published elsewhere. Resolving such an identifier calls the control plane registry.

The same key has a local form, which works: an identifier that starts with ., / or ~, or that carries the file:// protocol, designates a file on the workstation and never leaves the machine. Everything else is read as a package identifier. The key is written the same way in both cases:

models:
  # Chemin local : résolu sur le poste.
  - uses: ./blocs/relais-interne.yaml
  # Identifiant de paquet : aucun annuaire ne le résout ici.
  - uses: proprietaire/paquet

Model autocompletion. The editor offers a fixed list of common model identifiers when you type uses: under models:. This list is injected into the JSON schema, so it appears in the IDE, but every entry would be resolved by the remote registry. An accepted suggestion does not produce a valid configuration.

provider: free-trial. The free trial that went through the original project’s proxy is no longer supported. Models that declare it are removed at load time.

What is not affected

The gateway services, llm-gateway, gateway-db and gateway-admin, have nothing to do with this inherited service. They are delivered to the customer, run on the customer’s side, and depend on no vendor control plane. Their configuration lives in their database, not in a remote registry.

“Part of the product talks to a service that does not exist” does not mean “the product depends on a service that does not exist”. The path from the code editor to the language model, through the gateway, is self-contained end to end; see The role of the gateway and Architecture.

How to recognize a new case

Three signals, in the code and in use:

1. the surface mentions an organization, an account, a shared assistant, a registry or a remote agent;
2. its execution path goes through the vendor control plane client (core/control-plane/client.ts), and not the organization policy that the customer’s gateway serves;
3. it asks for an identifier of the form propriétaire/paquet.

A surface that ticks these boxes leads nowhere, whatever the local configuration.