Permissions and process safety

Distinguish boundaries

Approval applies to the reviewed operation and scope, not automatically to similar commands, other CWDs or new script contents. Secret access requires explicit approval for the relevant file, not a generic “inspect the project”.

Once, session and persistent

Depending on capability and protection gate, the permission dialog can offer one-time, session or rememberable grants. Not every operation can be permanently approved. Source, resolved executable identity, argv, CWD, paths and content binding may matter. Respect denials; do not switch tools or create wrappers merely to bypass them.

/permissions shows session grants, settings rules and persistent project capabilities with IDs/scope. Distinguish inactive legacy allows. Settings explains why editing JSON alone is not consent.

Three different rule types

Tool patterns

permissions.allow and deny accept Tool or Tool(pattern); the general matcher supports *, **, ?. Tool patterns are not allowedCommands syntax. Allow does not replace secret, dangerous, path or capability gates. Global denies apply immediately; project denies accumulate.

Bash lists

Project .lurus/settings.json:

{
  "permissions": {
    "allow": [],
    "deny": [],
    "allowedCommands": ["git status"],
    "deniedCommands": ["git push"],
    "bashAutoApprove": false
  }
}

Global counterpart: same structure in ~/.lurus/settings.json, after deliberate global consent. Expect a narrow offer for git status, not blanket Git access.

allowedCommands must match the entire command exactly. deniedCommands matches either exactly or as a prefix followed by a space. Allow wildcards are not supported. bashAutoApprove controls approval of Bash commands classified as safe, not every process. Do not rely on a universal default. An approved global true can override a project false; explicitly set the intended safe state globally.

Structured Exec

Exec runs a program using an argv array and reviewed CWD, without shell interpretation. Prefer it for ordinary builds/tests. Spaces, &, | or $() inside array elements are not automatically shell syntax; an explicitly invoked interpreter can still execute them.

A grant may bind executable identity, script/lifecycle contents and project CWD. npm run lint may run pre/post scripts; local programs and npx can require extra or nonpersistent checks. Approving a program name is not universal safety.

Workflow for an existing reviewed npm script:

1. Read package.json, including lint, prelint, postlint.
2. Explicitly request the parent agent to run that script in the project.
3. Review executable, argv and CWD in the dialog; only remember an offered narrow grant.
4. /permissions shows source and ID.
5. Changing script or CWD may require new approval.
6. Revoke that grant using its displayed ID.

Do not create helpers/wrappers to unlock a denied operation under another name. Use Bash only when actual shell composition is required.

Complete revocation reference

Use IDs from your actual /permissions output; <id> is only a placeholder.

Warning: These commands revoke approvals. revoke <id> removes a persistent project grant without another dialog; clear removes persistent project grants. Check the source and scope first.

/permissions
/permissions revoke <id>
/permissions revoke session <id>
/permissions revoke settings <id>
/permissions revoke global-settings
/permissions clear

Edit the original settings rule deliberately if it should not return after new consent. Review the scope of clear/revoke before using them.

Repair corrupt stores

Warning: Repair affects stored permissions or consent across all projects. Use it only for damaged data, not routine cleanup. Damaged data is backed up, and confirmation defaults to No.

/permissions repair
/permissions repair trust

Valid stores are not generally reset. Do not delete the files manually. Inspect the exact warning and affected source without exposing credentials.

Dangerous trust and automation

Danger: /trust on disables permission checks for the session. This can allow uncontrolled commands and file changes; it is not a replacement for narrow approval. Global "disableDangerousTrust": true blocks this feature.

/trust
/trust on
/trust off

/trust reports status. Activation requires the exact confirmation I understand the risks. /trust off immediately restores permission checks. The startup option --permission-mode dangerouslySkipAllPermissions also disables checks unless globally blocked, but without this interactive phrase dialog. Do not use it as a beginner or automation default.

Batch and single prompts make decisions without interactive input. Operations requiring special approval for secrets, dangerous actions or protected settings are rejected; other operations may receive one-time approval. This is not comprehensive read-only protection. LURUS_AUTO_CONSENT can automate consent for settings, hooks and MCP and is appropriate only for deliberately trusted inputs. Do not use dangerous permission modes or environment passthrough as defaults.

Child environments use a fixed allowlist, not automatic API key/token forwarding. LURUS_BASH_PASS_ENV, LURUS_HOOK_PASS_ENV, LURUS_MCP_PASS_ENV are comma-separated names; each added value becomes fully visible to processes.

Use settings for configuration scope and automation for noninteractive workflows.