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, writing a file — 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:

• Let Chalie handle your email, calendar, and contacts on its own — one permission covers all three.
• Block background tasks from ever deleting documents.
• Decide whether external integrations can touch your personal information at all.

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 (checking weather, browsing the web, searching documents) are set to Allow by default. Actions that have real-world consequences — anything touching your email, calendar, or contacts, or controlling devices — default to Ask.

Background

Background tasks run without you present — things like scheduled briefings, pattern detection, and proactive summaries. Since there’s no one to click “approve”, any action set to Ask in this context is automatically denied. Read-only and non-destructive operations are allowed by default (searching files, looking up weather). Actions that write, send, or delete things — controlling devices, deleting documents — default to Deny, and your personal information (email, calendar, contacts) is blocked entirely unless you open it up.

External agent

When an external application communicates with Chalie through its API, actions run under the external agent context. Write and control actions are denied by default, and so is all access to your personal information (email, calendar, contacts). Read-only actions — browsing documents, checking the weather — are allowed. You can tighten or loosen individual actions to match exactly what you want external integrations to be able to do.

Configuring policies

Open the Brain dashboard (the 🧠 brain icon in the top-right corner) and click Policies in the sidebar. Policies open on the Chat context by default. Each context — Chat, Background, and External agent — has its own set of rules; to jump to another, open the search bar at the top (or press ⌘K) and choose Policies · Background or Policies · External agent.

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
• Coding Agent — delegate a coding task to the coding agent
• Documents — create, delete, list, restore, search, upload, view documents
• Email, Calendar & Contacts — a single permission covering all personal-information work: reading, searching, drafting, and sending email, managing calendar events, and looking up contacts
• 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
• 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, device status, site health, list Wi-Fi networks, list port forwards, list traffic rules, block/unblock/disconnect client, authorize guest, restart device, locate device, power-cycle port, update Wi-Fi, manage port forwards, manage traffic rules
• 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. “Access Email, Calendar & Contacts”)
• 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 the email/calendar/contacts permission and the 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 handle email or control devices without manual approval, selectively change those specific permissions 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, reading its own documentation, and reading, writing, creating, deleting, and moving files — are marked as system tools. These bypass the policy system entirely: some are part of Chalie’s core reasoning loop, others carry their own built-in guardrails instead (writing to an existing file reads it first; a move or rename refuses to overwrite a destination that already exists). You won’t see them in the Policies page and they cannot be blocked. This is why there’s no separate Memory category, and why file actions no longer have their own categories either — recalling memories and touching files are both things Chalie just does, not gated actions on their own. The coding agent itself is still gated as a whole: handing it a task is an Ask-by-default action in Chat, even though the file operations it performs afterward don’t prompt separately.