When the configuration fails to load

A red banner reports Error loading … and Chat is disabled until a model is available. The chat stops responding. The banner offers three commands: Help, Reload and View.

This banner means that configuration loading stopped on a fatal error. It is neither a model failure nor a network failure: the product refuses to start on a configuration it did not understand in full.

Start with View: the configuration page shows the details of the error and names the cause in most cases.

The causes, in the order you meet them

A badly declared model

Validation rejects a model without a name, or whose provider is not a string. The message cites the index of the offending model, for example Model at index 2 has an invalid or missing 'title'. The index counts from zero, in file order. The title in the message is the name written in workstation.yaml.

A neighbouring case is not fatal: a model whose contextLength and completionOptions.maxTokens are too close together. Validation requires at least 1000 tokens of margin and emits a warning below that, because the question would be truncated.

For the list of accepted provider values, see Model providers; for the expected shape of the file, The configuration file.

A field whose type does not match

models, context and the session commands must be lists; a boolean field, such as disableSessionTitles, must be true or false. A quoted disableSessionTitles: "true" is a string and not a boolean, and the error is fatal.

A referenced block that does not exist

The message Failed to load config due to missing blocks means that the file imports a block (a model, a rule) that could not be resolved. The list of missing blocks is shown below the message. Each entry is either a misspelled name, or a block your organization does not have access to.

The file is not valid YAML

Irregular indentation, a colon in an unquoted value, a tab: parsing fails before any validation, and the message carries the offending line and column. To check the file outside the editor:

python3 -c "import yaml,sys; yaml.safe_load(open(sys.argv[1]))" ~/.lemniscate/workstation.yaml

A secret that nothing resolves

A value written ${{ secrets.MA_CLE }} is substituted at load time. When no source provides it, the block that carries it stays incomplete and joins the list of missing blocks from the previous message.

Four places are consulted, in this order: the process environment variables, the ~/.lemniscate/.env file, the .lemniscate/.env file of the open repository, then a .env at the root of that repository. An empty value is ignored and the search continues with the next source. One line per value:

MA_CLE=sk-exemple-remplacez-cette-valeur

A read error on the .env file does not interrupt loading: it is written to the log as Error reading ~/.lemniscate/.env file, and the secret stays unresolved. In this case the banner does not name the cause; the log, described below, carries it.

A provider forbidden by your organization

This case is not fatal: the configuration loads, and a model is missing. If the configuration page shows Model provider "…" is forbidden by your organization's policy, an organization policy forbids that model provider on the workstation. The entry is discarded, even if its API key is valid, and the other models in the file load. The rule is set by the fleet administrator: editing workstation.yaml does not lift it.

Two items carrying the same identifier

Settings come from several stacked files: the repository one (.lemniscate/project.yaml), the machine one (~/.lemniscate/workstation.yaml), and those that either of them includes. Two items with the same identifier (id:) coming from two files refuse to load. The message names both files:

The rule `house-style` is defined in both .lemniscate/project.yaml and
~/.lemniscate/workstation.yaml. Add `replaces: house-style` to the one in
.lemniscate/project.yaml to take its place, or give one of them another id.

Two fixes, your choice: give one of the two another identifier, or declare that the closer one replaces the other:

rules:
  - id: house-style
    replaces: house-style
    name: House style
    rule: "Noms explicites, en anglais"

A replaces: that points to nothing also refuses to load. That is the case of a typo, and the refusal makes it visible.

Two block files with the same name (.lemniscate/rules/house-style.md in the repository and on the machine) are the same case: a block file carries the identifier of its file name.

An include that does not read

include: only accepts local paths, relative to the file that writes them or absolute. Three possible refusals, each named in the message: a file not found, a network address (https://…), and an include loop. In this last case, the message shows the full chain of includes.

A leftover config.yaml

The machine file is called workstation.yaml. A ~/.lemniscate/config.yaml is not read, and its presence without workstation.yaml refuses startup:

~/.lemniscate/config.yaml is no longer read: the settings file of the machine is now
workstation.yaml, so that the file of a repository can be named project.yaml without
the two sharing a name. Rename it to ~/.lemniscate/workstation.yaml — its contents
do not change.

The fix is the rename; the content does not change.

Starting again from a configuration that loads

When the cause stays out of reach, set your file aside and let the product recreate one:

mv ~/.lemniscate/workstation.yaml ~/.lemniscate/workstation.yaml.avant-panne

Reload in the banner reloads the configuration without restarting the editor. A fresh file is written, the chat starts again, and you reintroduce your blocks one by one until you find the one that breaks.

Watch out for the old format. A ~/.lemniscate/config.json is read only if workstation.yaml is absent. Moving the YAML therefore brings the JSON back, with its own errors: move both to start from scratch.

Finding the logs

The banner only shows the last message. The log keeps the full trace of loading, call stack included. It is the file to attach to a bug report.

The file is the same on all three environments: ~/.lemniscate/logs/core.log.

A second file, ~/.lemniscate/logs/prompt.log, records what was sent to the models. It contains the content of your exchanges: read it over before attaching it to a report.

Environment	Path
VS Code	Lemniscate: View Logs command, which opens the developer tools
JetBrains	Open Logs action, which opens ~/.lemniscate/logs/core.log
lemni	no dedicated command: read the file

To attach the last lines to a report:

tail -n 100 ~/.lemniscate/logs/core.log

If LEMNISCATE_GLOBAL_DIR is set in your environment, every path on this page lives under that directory and not under ~/.lemniscate.