Free commands and the "don't ask again" approval

By default, no command is free: every command the agent proposes is presented to you, and you validate or refuse it. Two decisions by the project administrator reduce the number of prompts (security white paper V3, section 5.1):

• the administrator lists free commands, which run without validation;
• the administrator allows you to skip revalidating a command you have already validated, or forbids this exemption.

This page describes these two decisions, how to give the “don’t ask again” approval on a command, and what remains subject to your validation in all cases.

What the administrator can exempt

The project administrator can exempt from validation (security white paper V3, section 5.1):

• the usual build, unit test, formatting and analysis commands;
• reading files from the open repository;
• any command they list.

This list is written in the policy, from the administration console, and the gateway evaluates it before each execution. It is not set from the workstation: neither a terminal flag nor a file on the workstation frees a command the policy does not list.

In the policy document, free commands are the allow rules of the permissions field, written as tool patterns:

{
  "permissions": {
    "allow": ["Bash(npm test)", "Bash(make *)"]
  }
}

Writing the policy is described in Set the workstation policy from the console.

The revalidation exemption is set in the same place, on the Remembered approvals (“don’t ask again”) line of the Session rules section. On Forbidden, the policy writes allowRememberedGrants as false: the “don’t ask again” approval is neither offered nor honored.

Giving approval on a command

When the agent calls the Bash tool, the terminal displays the exact command and three choices:

Validate
Validate + don't ask again
No, and tell Lemniscate what to do differently

The Tab (validate), Shift+Tab (validate and don’t ask again) and Esc (refuse) keys lead to the same answers as the arrows and Entrée. The y and n keys validate or refuse the current call.

1. Choose Validate + don’t ask again. No approval is recorded at this stage: a second screen, titled Don't ask again — what will be recorded, opens.
2. On this second screen, the Scope: line reads This exact command, selected by default. The line below shows the command verbatim, in the form command = "git status" (verbatim).
3. The Project: and Until: lines state where and until when the approval applies. The sentence at the bottom summarizes it: not another command, not another project, not another session.
4. Entrée or y records the approval. Any other key returns to the list of three choices without recording anything; the current call still has to be validated or refused.

The approval takes effect on the next call, without restarting the terminal.

What the approval covers

The approval applies to the command you have just validated, and to that command only. It holds within three bounds, which are not configurable:

Bound	Value
Project	the working directory in which lemni was started
Session	the session that gave the approval
Duration	one hour after recording

Outside these bounds, the approval produces no rule: in another directory, in the next session or one hour later, the same command prompts again.

The command is compared by equality, after trimming whitespace at both ends. git status does not open git status --short, nor git remote set-url, nor a command for which git status is a prefix. A * in the approved command is a character like any other, not a pattern.

The approval covers no other tool, and it does not exempt writes from validation: each retained write is presented to you as a diff (security white paper V3, section 5.4).

Where the approval is recorded

The approval is written to permissions.yaml, in the product configuration directory: ~/.lemniscate by default, or the directory designated by LEMNISCATE_GLOBAL_DIR. This directory is outside the repository working copy: the agent cannot modify this file.

Approvals live under the accords key. Each entry carries the tool, the command, the project, the session and the expiry:

accords:
  - tool: Bash
    arguments:
      command: git status
    project: /home/vous/projets/exemple
    session: 5f0c2b1e-7d4a-4c1b-9e2f-3a8b6c4d0e11
    expiresAt: 2026-09-25T15:04:05.000Z

Each recording rewrites the file and removes, in passing, approvals whose expiry has passed. An unreadable file is not overwritten: the recording is refused, and the current call remains validated.

When the policy forbids the exemption, the first screen says so and does not offer Validate + don’t ask again. Approvals already written stay in the file and are not honored for as long as the prohibition lasts.

Removing an approval

An approval expires on its own at the end of the session that gave it, or one hour after it was recorded, whichever comes first. To end it sooner:

1. Open permissions.yaml in the product configuration directory.
2. Delete the entry under accords.
3. Save the file. It is reread on the next call.

What remains subject to validation

Four families of actions are always submitted to you, whatever the administrator’s list and your approvals (security white paper V3, sections 5.1, 5.3 and 5.4):

• any command absent from the administrator’s list, as long as you have not validated it;
• any retained write, presented as a diff;
• any tool the policy marks as sensitive. In the console, these are the tools in the Tools that ask every time section;
• any modification to a file executed by a third party: continuous integration configuration, build script, version control hook, dependency manifest or lock file. It is forbidden by default or subject to a dedicated validation, distinct from ordinary validation and flagged as such.

The terminal adds a check specific to shell commands. The first screen announces it below the command: Dangerous commands will be blocked regardless of your preference. The command analyzer (@lemniscate/terminal-security) reads each command at call time and can tighten an approval, never loosen it:

• a command it classifies as “to confirm” prompts on every call, even after a This exact command approval. This applies to network clients (curl, wget, ssh), package installation (npm install, pip install), interpreters that receive a script (python, node, sh, bash), git writes (add, commit, checkout), rm, and commands it does not know;
• a command it classifies as “critical” is refused without a prompt: sudo, su, doas, rm -rf on a system path, mkfs, dd to a device, chmod 777 or +s, chown root, eval and exec, kernel module loading and iptables.

Validated or not, a network command reaches nothing: the sandbox has no network interface. git fetch and git push do not succeed either: the agent has neither network nor identity on the forge (security white paper V3, sections 4.1 and 4.3).