Policies

You decide what Chalie can do

Policies are Chalie’s permission system. Every action Chalie takes — sending an email, controlling a smart-home device, storing a memory — is governed by a policy rule that you control. You decide what happens automatically, what needs your approval, and what is blocked entirely.

Quick examples:

• Allow Chalie to search your email without asking, but require approval before sending.
• Block background tasks from ever deleting memories.
• Let external integrations read your calendar but nothing else.

The three states

Every policy rule has one of three states:

• Allow — Chalie performs the action immediately, no confirmation needed. Best for read-only actions and things you trust completely.
• Ask — Chalie pauses and shows you a permission card describing what it wants to do. You approve or deny each time. This is the default for most sensitive actions.
• Deny — the action is blocked outright. Chalie won’t attempt it and won’t ask. The blocked action is logged so you can review it later.

The three contexts

Chalie runs in different contexts depending on who or what triggered the action. Each context has its own set of policy rules, so you can be permissive when you’re actively chatting but restrictive when Chalie is running in the background.

Chat

The default context when you’re talking to Chalie directly. Most read actions (searching email, checking weather, browsing the web) are set to Allow by default. Actions that have real-world consequences — sending emails, controlling devices, modifying calendar events — default to Ask.

Background

Background tasks run without you present — things like scheduled briefings, pattern detection, and memory consolidation. Since there’s no one to click “approve”, any action set to Ask in this context is automatically denied. Most actions default to Deny here. Only safe, non-destructive operations like storing a memory are allowed by default.

External agent

When an external application communicates with Chalie through its API, actions run under the external agent context. This is the most restrictive by default — nearly everything is denied. You explicitly allow only the actions you want external integrations to perform.

Configuring policies

Open the Brain dashboard (the 🧠 brain icon in the top-right corner) and click Policies in the Brain sidebar. You’ll see the three contexts listed as sub-items — Chat, Background, and External agent — click one to view and edit its rules.

Actions are grouped into categories. Each category expands to the individual actions it covers:

• Bash — execute commands, compound commands, installation, modify file, read, remote execution, web fetch
• Calendar — get event, list events, update event
• Code Eval — run sandboxed code
• Contacts — get contact, list contacts
• Documents — create, delete, list, restore, search, upload, view documents
• Email — draft, forward, manage, read, reply, search, send email
• File Permissions — change file permissions
• File Write — write files
• Home — control devices, get device state, list devices, list automations, trigger automation, subscribe events
• Lists — add, check, clear, create, delete, list all, remove, rename, view
• News — news lookup
• Places — save, get, list, delete saved places
• Programming Docs Search — search programming documentation
• Schedule — create, cancel, list, search schedules
• Search Files — glob, grep
• Skill Builder — create, edit, delete, list custom skills
• Ubiquiti — list devices, list clients, get info, control client, control device, manage WLAN, manage port forwarding, manage traffic rules, authorize guest
• Weather — weather lookup
• Web Browse — browse and read web pages
• Web Search — search the web

The exact categories you see depend on which Skills are active in your instance. Set each action to Allow, Ask, or Deny. Changes take effect immediately — no restart required.

Permission requests

When an action’s policy is set to Ask and Chalie wants to perform it, a permission card slides up at the bottom of the interface. The card shows:

• The action name (e.g. “Send Email”)
• A one-line description of what Chalie intends to do
• Allow and Deny buttons

Chalie waits for your response before proceeding. There is no auto-timeout — it will wait as long as needed. If you deny, the action is logged and Chalie is told the action was denied so it can adjust.

Common setups

Hands-free assistant

If you trust Chalie to act autonomously during chat, set all email, calendar, and home actions to Allow in the Chat context. You’ll still have Background and External agent locked down by default.

Cautious mode

Set everything to Ask in the Chat context. Chalie will always check with you before taking any action. This is useful if you’re sharing your Chalie instance or want full visibility into what it does.

Background-safe

If you want scheduled tasks to send emails or control devices without manual approval, selectively change those specific actions to Allow in the Background context. Keep everything else denied.

System and internal tools

Some of Chalie’s internal tools — like find_tools, find_skills, memory, and reading its own documentation — are marked as system tools. These bypass the policy system entirely because they’re part of Chalie’s core reasoning loop. You won’t see them in the Policies page and they cannot be blocked. This is why there’s no separate Memory category: recalling and storing memories is part of how Chalie thinks, not a gated action.