Skip to content
Version 1.0.0

Control what the JetBrains plugin writes and sends

Where the plugin reads and writes on the workstation, why no telemetry leaves it, and what the diagnostic report written on the workstation contains.

This page answers an audit question: on a developer workstation, what does this plugin touch, and what leaves the workstation?

The exact values of the settings mentioned here (label, default, persistence file) are in the JetBrains plugin reference, generated from the code.

Move the folder the plugin reads and writes

Section titled “Move the folder the plugin reads and writes”

By default, the plugin reads and writes in ~/.lemniscate: configuration, sessions and logs.

To move it, set the LEMNISCATE_GLOBAL_DIR environment variable before starting the IDE, not from a terminal opened inside the IDE:

Fenêtre de terminal
export LEMNISCATE_GLOBAL_DIR=/opt/lemniscate/dev-42

The action that opens the core log from the IDE (Open Logs) follows this variable and looks for logs/core.log in the relocated folder. If the file does not exist yet, it shows a notification saying so.

On the first read, if no configuration exists, the plugin writes a sample configuration, which does not point to your gateway. Put the configuration that points to your gateway in place before the first session: the workstation knows only that address (security white paper V3, section 3.3).

Both the plugin and the core can write this default configuration. For an audit, read the file present on the workstation rather than the template in the code.

The only Lemniscate-related flow from the workstation goes to your gateway. Nothing goes to the vendor: no telemetry, no error report, no license check (security white paper V3, sections 3.3 and 11.3).

The plugin emits no telemetry. The reporting library is not packaged in the archive delivered to a customer: there is nothing to turn off. Errors are written to the IDE log, on the workstation, and stop there. The tutorial Verify that no data leaves runs the artifact check on the archive.

The plugin shows no incident submission button. The JetBrains platform offers one in its error window only if the plugin declares an errorHandler extension point; the plugin declares none. It does not emit usage metrics either.

The plugin can produce a local diagnostic report. Look for the action Write a Diagnostic Report on This Machine (Find Action, Ctrl+Shift+A).

It asks the core to write a dated folder under <dossier du produit>/diagnostics/, then opens its lead file in the editor. Nothing is sent, and no setting adds a send step. The product knows no destination for this folder; if the report has to reach someone, you pass it along yourself.

The folder holds three plain text files:

  • LISEZ-MOI.md: what the folder contains, and what was removed from it;
  • rapport.md: product version, host environment, build profile, core state, model and gateway name, enterprise policy in effect, latest errors;
  • journal.txt: the last 200 lines of the product log.

The content is redacted before being written: addresses (URLs), file paths, email addresses and character sequences long enough to be a key are replaced with a neutral label. The report names the model and the gateway; it does not collect the access key, the gateway address, or the content of your files. These are text files: you can read them before passing them along.

The product does not delete these folders. Delete them when you no longer need them.

Lemniscate does not manage identities: it relies on yours. The developer is authenticated against your directory (OpenID Connect), through the gateway, and their session is tied to their identity and to a project (security white paper V3, section 6.1).

There is no account with the vendor. The plugin calls no vendor service, and no license check leaves the workstation (security white paper V3, section 11.3). Authentication uses the workstation’s only flow, the one that goes to your gateway.

The plugin declares Ctrl+J, Ctrl+Maj+J and Ctrl+I (Cmd on macOS) in its descriptor. It does not modify the IDE’s keymap: when another action claims the same combination, it keeps it, and the conflict is resolved in Réglages › Keymap.