Configuration file

These keys are the ones the validation schema describes. A key that is absent from this page is not rejected for that reason: the schema leaves several objects open, and the site teaches elsewhere keys that work without appearing here, those of a model first among them. See what this page does not cover, at the bottom.

The two files, and what each one decides

Settings live in two files, in the same format:

File	Scope
~/.lemniscate/workstation.yaml	the machine, across all projects
.lemniscate/project.yaml	the repository, shared by the team working in it

The machine file decides every key. The repository file decides only the team’s content: context, docs, metadata, name, prompts, rules, schema, version. Everything else, written in a repository file, is ignored: the tool says so at load time, naming the file, the key and the reason.

The prompts key no longer does anything

Writing a command in the configuration file was removed on 2026-08-26. The prompts key is still accepted so that your configuration keeps loading, but its content is no longer read: it produces no command, neither in the IDE nor in the terminal. At load time, the tool names the block and says what to write instead.

What replaces it: a command file placed in .lemniscate/prompts/, whose name becomes the command’s name. Copy the block’s body as is. See Writing a custom command.

Why this removal: there were two ways of writing the same thing, and users had no way of knowing which to choose. The command file is the one the documentation teaches, the one /init writes, and the one a team shares through its repository.

Why this asymmetry: cloning a repository must not be enough to decide what runs on the machine that cloned it. Without this rule, a versioned file could impose the server your calls go out through, turn off certificate verification, or run a command. A new key is closed by default: a repository can decide it only if it is added to this list, deliberately.

For the keys it decides, the closest one wins: what the project says takes precedence over what the machine says. A file can include another with include: (local paths only); the included file becomes one more layer, placed immediately below the one that includes it, and a file included by a repository file decides no more than it does.

In lists, an item can carry an identifier (id:), separate from its displayed name. Two items with the same identifier coming from two layers refuse to load, unless the closest one declares replaces:: no value is replaced without the file declaring it. An item without an identifier always adds up.

Above all of it, your organization’s policy: if a file sets something the policy imposes, the tool displays it at load time and applies the imposed value.

Key names are not translated: they are written as is in these files.

The schema carries no descriptions. This page therefore lists the keys, their type and whether they are required, without explaining what each one does. The day the schema is annotated, the descriptions will appear here without anyone having to rewrite this page.

At the root

Key	Type	Required
include	list of string	no
name	string	no
version	string	no
schema	string	no
metadata	object	no
env	object	no
requestOptions	object	no
execution	object	no
documentation	object	no
formatter	list of objects	no
models	list (2 accepted forms)	no
context	list (2 accepted forms)	no
data	list (2 accepted forms)	no
mcpServers	list (2 accepted forms)	no
rules	list (2 accepted forms)	no
prompts	list (2 accepted forms)	no
docs	list (2 accepted forms)	no

The execution key

Session limits, loop detection and delegation safety nets. What each key does, and its defaults, are explained on Execution guardrails and Delegating to subagents.

Key	Type	Required
sessionMaxActions	integer	no
sessionMaxMinutes	integer	no
sessionMaxExtensions	integer	no
toolLoopDetection	boolean	no
toolLoopThreshold	integer	no
subagentMaxDepth	integer	no
subagentMaxPerSession	integer	no
subagentMaxConcurrent	integer	no

A model

The schema accepts 2 forms for a models entry.

Form 1

Key	Type	Required

Form 2

Key	Type	Required
uses	several accepted forms	yes
with	object	no
override	several accepted forms	no

What this page does not cover

A model’s provider field is validated as a free-form string: the list of values that actually work lives in the code and not in the schema. It has its own page, Model providers.

The parameters of each context provider are not described by the schema either: it accepts them without constraining them.

A model’s keys are not described here: the table of model forms is empty because the schema accepts them without naming them. The keys the rest of the site has you write (provider, model, apiBase, apiKey, roles, capabilities, requestOptions, contextLength, autocompleteOptions) work, and are taught by the guides. They will appear here the day the schema carries them.

Same for connectionTimeout (MCP servers) and quickActions (VS Code extension): the site teaches them, the schema does not describe them.