# Approvals and agent access

Choose how agents ask for approval and which other agents they can contact.

## What YOLO controls

The `yolo` setting affects both CLI approvals and access to other Facade agents. Projects that share a settings file use the same YOLO value. Facade applies it when each agent starts.

| Setting | CLI approvals | Agent access |
| --- | --- | --- |
| `true` — default | Tells the CLI to skip approval prompts where supported. | All agents connected through your Facade home, including connected SSH projects. |
| `false` | Uses the CLI’s normal approval and sandbox behavior. | The agent’s family: its parent, siblings, children, and their descendants. |

Pi has no native approvals or sandbox in either mode. OpenCode follows its own permission settings, which allow tools by default.

## Change YOLO for future starts

Add or change `yolo` at the top level of facade.json (see [Agent settings](https://facadecode.com/docs/settings/)):

```json
{
  "yolo": false
}
```

Save the file and start a new agent to use this value. Running agents keep their launch settings; resumed and pinned agents use the current file when they next start.

Agents in projects using different Facade homes cannot contact one another. If agents are missing from discovery, check both the home and their access settings.

## Keep permission flags in the right place

Use `yolo` for Facade’s permission choice. Avoid adding approval, sandbox, or bypass flags to a built-in entry’s `args`; Facade manages those launch options and reports conflicts.

A custom terminal program keeps its own permissions in either mode. Facade does not inject its tools or grant folder trust to that program.

To see how agents communicate in practice, try a [collaboration pattern](https://facadecode.com/docs/collaboration/).