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

# CLI access policy

> What the CLI is allowed to do on each board.

The **CLI access policy** decides which **`hirotm`** commands are allowed on a board. You turn each permission on or off in the board's settings in the Web UI. Different boards can have different policies.

This page lists the permissions and shows which commands need each one.

<Warning>
  **`Read board`** is the foundation. If it is off for a board, **no other permission applies** and every CLI command on that board is blocked—reads and writes alike.
</Warning>

## Permissions at a glance

| Permission                   | What it lets the CLI do                                               |
| ---------------------------- | --------------------------------------------------------------------- |
| **Read board**               | Read the board, its lists, tasks, releases, and trash.                |
| **Create lists**             | Add new lists to the board.                                           |
| **Create tasks**             | Add new tasks to the board.                                           |
| **Manage CLI-created lists** | Update, move, delete, restore, or purge lists the CLI itself created. |
| **Manage any lists**         | The same actions on any list, no matter who created it.               |
| **Manage CLI-created tasks** | Update, move, delete, restore, or purge tasks the CLI itself created. |
| **Manage any tasks**         | The same actions on any task, no matter who created it.               |
| **Manage structure**         | Create, update, and delete releases (and set the default release).    |
| **Delete board**             | Move boards to Trash, restore them, or permanently purge them.        |

<Note>
  **CLI-created** means the item was created from `hirotm`. **Any** means the item was created in the Web UI or by anyone else. The "manage any" permissions are stronger and include the "CLI-created" ones.
</Note>

***

## Reading data

These commands only need **Read board** on the target board.

| Command             | What it does                                                          |
| ------------------- | --------------------------------------------------------------------- |
| `boards list`       | List boards the CLI can read.                                         |
| `boards describe`   | Show one board's settings, lists, and current CLI policy.             |
| `lists list`        | List the lists on a board.                                            |
| `lists show`        | Show one list.                                                        |
| `tasks list`        | List tasks on a board.                                                |
| `tasks show`        | Show one task.                                                        |
| `releases list`     | List the board's releases.                                            |
| `releases show`     | Show one release.                                                     |
| `trash list boards` | Show boards currently in Trash.                                       |
| `trash list lists`  | Show trashed lists (rows for unreadable boards are hidden).           |
| `trash list tasks`  | Show trashed tasks (rows for unreadable boards are hidden).           |
| `query search`      | Search tasks. Results only include hits from boards the CLI can read. |

## Creating lists and tasks

To add new content the CLI needs **Read board** plus the matching create permission.

| Command     | Permission needed |
| ----------- | ----------------- |
| `lists add` | **Create lists**  |
| `tasks add` | **Create tasks**  |

## Managing existing lists

For lists that already exist, the permission depends on **who created the list**.

| Command         | If the list was created by the CLI | If the list was created in the Web UI |
| --------------- | ---------------------------------- | ------------------------------------- |
| `lists update`  | **Manage CLI-created lists**       | **Manage any lists**                  |
| `lists move`    | **Manage CLI-created lists**       | **Manage any lists**                  |
| `lists delete`  | **Manage CLI-created lists**       | **Manage any lists**                  |
| `lists restore` | **Manage CLI-created lists**       | **Manage any lists**                  |
| `lists purge`   | **Manage CLI-created lists**       | **Manage any lists**                  |

<Tip>
  Granting **Manage any lists** alone is enough—it covers CLI-created lists too. You only need to enable **Manage CLI-created lists** if you want to keep the CLI scoped to its own lists.
</Tip>

## Managing existing tasks

The same pattern as lists: permission depends on **who created the task**.

| Command         | If the task was created by the CLI | If the task was created in the Web UI |
| --------------- | ---------------------------------- | ------------------------------------- |
| `tasks update`  | **Manage CLI-created tasks**       | **Manage any tasks**                  |
| `tasks move`    | **Manage CLI-created tasks**       | **Manage any tasks**                  |
| `tasks delete`  | **Manage CLI-created tasks**       | **Manage any tasks**                  |
| `tasks restore` | **Manage CLI-created tasks**       | **Manage any tasks**                  |
| `tasks purge`   | **Manage CLI-created tasks**       | **Manage any tasks**                  |

<Tip>
  Granting **Manage any tasks** alone is enough—it covers CLI-created tasks too.
</Tip>

## Managing board structure

Releases shape how tasks are grouped into milestones. Changing them needs **Manage structure**.

| Command                | Permission needed    |
| ---------------------- | -------------------- |
| `releases add`         | **Manage structure** |
| `releases update`      | **Manage structure** |
| `releases delete`      | **Manage structure** |
| `releases set-default` | **Manage structure** |

## Deleting and restoring boards

Anything that touches a board's lifecycle needs **Delete board**.

| Command          | Permission needed                                      |
| ---------------- | ------------------------------------------------------ |
| `boards delete`  | **Delete board** (moves the board to Trash)            |
| `boards restore` | **Delete board** (restores a trashed board)            |
| `boards purge`   | **Delete board** (permanently deletes a trashed board) |

<Note>
  Creating a brand-new board is controlled separately, in the **app-level settings** in the Web UI—not in any single board's policy.
</Note>

## Always available

These commands are not tied to any board, so they work regardless of policy.

| Command                            | What it does                       |
| ---------------------------------- | ---------------------------------- |
| `statuses list`                    | List the global workflow statuses. |
| `server start` / `stop` / `status` | Manage the local server process.   |

***

## Recommended permission sets

Pick the smallest set that fits your use case.

| Use case                                                                 | Permissions to enable                                                                                                |
| ------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------- |
| **Read-only agent** (reports, summaries, dashboards)                     | **Read board**                                                                                                       |
| **Capture-only agent** (only adds new tasks/lists, never edits old ones) | **Read board**, **Create lists**, **Create tasks**, **Manage CLI-created lists**, **Manage CLI-created tasks**       |
| **Full collaborator** (edits anything on the board)                      | **Read board**, **Create lists**, **Create tasks**, **Manage any lists**, **Manage any tasks**, **Manage structure** |
| **Board administrator**                                                  | All of the above plus **Delete board**                                                                               |

## Checking the current policy

To see which permissions are currently enabled on a board, run:

```bash theme={null}
hirotm boards describe <board-slug>
```

The output includes the board's current CLI policy, so you can confirm which commands will succeed before you run them.

## Related

* [Concepts](/task-manager/get-started/concepts) — boards, lists, tasks, profiles, and how access fits in
* [hirotm CLI](/task-manager/cli/cli-commands) — the full command reference
* [Boards](/task-manager/cli/boards), [Lists](/task-manager/cli/lists), [Tasks](/task-manager/cli/tasks), [Releases](/task-manager/cli/releases), [Trash](/task-manager/cli/trash)