> ## Documentation Index
> Fetch the complete documentation index at: https://docs.luminy.tech/llms.txt
> Use this file to discover all available pages before exploring further.

# Agent Permission Controls and Approval Settings in Luminy

> Luminy's permission system lets you approve or deny sensitive agent actions before they run, giving you full control over what the agent does.

When Luminy's agent is running, it can read files, write code, execute shell commands, and make network requests on your behalf. The permission system puts you in control of those sensitive operations: when enabled, the agent pauses before each potentially destructive action and waits for your approval before proceeding. This gives you a full audit trail of what the agent is about to do — and the ability to stop anything you didn't intend.

## How It Works

With permission mode enabled, every sensitive tool call triggers a **Permission Request** modal before the action executes. The agent is paused until you respond. The modal shows you:

* **Action type** — what kind of operation is being requested (e.g., `Run Command`, `Write File`)
* **Target** — the exact file path, shell command, or URL involved
* **Description** — a plain-language explanation of what the agent is trying to do

You then choose one of three responses.

## Permission Modal Options

<CardGroup cols={3}>
  <Card title="Allow Once" icon="check">
    Grants permission for **this specific action only**. The next time the agent tries the same type of action — even on the same file — it will ask again.
  </Card>

  <Card title="Always Allow" icon="shield-check">
    Permanently grants permission for this action type and target for the **rest of the current session**. A green **Granted** badge appears in the chat so you can see which permissions are active at a glance.
  </Card>

  <Card title="Deny" icon="ban">
    Blocks the action. The agent receives a denial response and may attempt a different approach to complete your request.
  </Card>
</CardGroup>

<Note>
  Clicking the backdrop or the **✕** button on the modal is equivalent to **Deny**. The agent will not proceed.
</Note>

## Enabling Permission Mode

Permission mode is off by default to keep the experience fast for trusted workflows. Turn it on whenever you want explicit control over agent actions.

<Steps>
  <Step title="Open Settings">
    Click the **Settings** icon in the sidebar.
  </Step>

  <Step title="Navigate to General or Permissions">
    Go to **Settings → General** or **Settings → Permissions**.
  </Step>

  <Step title="Toggle Enable Permissions">
    Switch the **Enable Permissions** toggle to on. The setting takes effect immediately for the current session.
  </Step>
</Steps>

## What Triggers a Permission Prompt

Not every tool call requires approval — only sensitive ones. The following action types trigger a permission prompt when permission mode is enabled:

| Action            | Triggered by                                                   |
| ----------------- | -------------------------------------------------------------- |
| `Run Command`     | The agent executing a shell command on your system             |
| `Write File`      | The agent creating or modifying a file                         |
| `Read File`       | The agent reading a file (can be enabled for stricter control) |
| `Read Web Page`   | The agent fetching a URL                                       |
| `Network Request` | The agent sending outbound network data                        |

<Tip>
  Even in **Build** mode (which has full tool access), the agent is configured to ask before filesystem mutations like `edit_file`, `write_file`, `delete_file`, `rename_file`, and `run_command`. Enabling permission mode adds the modal on top of that built-in caution layer.
</Tip>

## Viewing Active Grants

When you choose **Always Allow** for an action, a green **Granted** badge appears inline in the chat at the point where the permission was granted. Scroll through your chat history to see exactly which permissions are active and when they were approved.

You can also review and revoke individual grants from **Settings → Permissions**, where all active `Always Allow` grants for the current session are listed.

## Session Scope and Reset

<Warning>
  All granted permissions — including **Always Allow** grants — are stored **per session** and **reset every time the app restarts**. When you quit and reopen Luminy, the permission slate is wiped clean and you start fresh.
</Warning>

This is intentional. It means a permission granted during a late-night debugging session does not silently carry over to a different project the next morning.

## Recommendations

<CardGroup cols={2}>
  <Card title="Enable for unfamiliar codebases" icon="folder-open">
    When working on a project you haven't explored before, enabling permissions lets you review every file write and command before it executes.
  </Card>

  <Card title="Enable for destructive operations" icon="triangle-exclamation">
    Any task involving deletions, renames, database migrations, or deployment scripts benefits from a manual approval step for each action.
  </Card>

  <Card title="Disable for trusted workflows" icon="bolt">
    If you're iterating quickly on your own project and trust the model you're using, disabling permissions removes the approval step and lets the agent move at full speed.
  </Card>

  <Card title="Use Always Allow sparingly" icon="shield">
    Reserve **Always Allow** for low-risk, repetitive reads (e.g., reading config files). Keep **Allow Once** active for shell commands and writes.
  </Card>
</CardGroup>

<Note>
  MCP server tools may also trigger permission prompts depending on the action they perform. If you've connected an MCP server that runs shell commands or writes files, those actions flow through the same permission system.
</Note>