The permissions model

Your assistant can read workspace files, run commands in a sandbox, search the web, and, with your confirmation, reach the host machine. The permissions model decides which of those happen automatically and which wait for you.

Every permission check is deterministic software, not a model judgment. The Allow / Deny buttons are hard-coded. Prompt injection cannot talk its way past that boundary.

This is not a promise of unrestricted hands on a shared server. A local hatch on your Linux desktop can ask to run host_bash on that machine, and you confirm or deny. It does not become remote root on a house box you did not hatch it onto.

How it works

Every tool call is classified with a risk level:

Low: read-only (workspace reads, web search, loading skills, recalling memory). These can auto-run at the default threshold.
Medium: state changes (writes, API calls, shell that modifies things). Whether they prompt depends on your threshold.
High: destructive or sensitive (deletes, sudo-class commands). These prompt unless you have raised the threshold all the way.

Classification runs in the gateway, a separate process outside the model sandbox. Shell is parsed; other tools use registry metadata. If the gateway is unreachable, the assistant fails closed (treats the threshold as strict).

When a tool needs approval, you see a plain-language description, a risk badge, why it was classified that way, and the full tool input.

Risk tolerance

Your risk tolerance is the auto-approve ceiling. Configure it in Settings → Permissions & Privacy.

Setting	Auto-approves	Prompts
Strict	Nothing	Everything
Default	Low-risk	Medium and high (writes, commands, API calls)
Relaxed	Low and medium	High only
Full access	Classified tools within policy	Still not a bypass of the sandbox / host split below

Default is Default: read-only low-risk auto-runs, everything else asks. Full access does not mean “the assistant may administer any machine on the network.” Host tools still have to be requested and still run only on the computer where this hatch lives.

Per-context thresholds

When chatting (interactive): default Default
Scheduled / background: often looser, because no one is sitting at the prompt. Non-interactive turns cannot wait forever; uncovered prompts deny rather than hang.
Headless / API: default Strict

The permission prompt

Allow: run this action. Similar future actions may auto-approve if a matching trust rule is created.
Deny: block it. The assistant does not retry on its own.

Channel approvals (Telegram, Slack) are one-time grants. They expire quickly and do not mint standing host access. To change lasting rules, use the desktop client.

The sandbox boundary

Treat the workspace as a contained environment on your computer. On Linux the sandbox is bubblewrap. Path traversal (../) and symlink escapes are blocked.

Inside the workspace (hatch instance under ~/.local/share/cadence/assistants/, with a legacy fallback at ~/.cadence/workspace/):

Reading and writing workspace files
Sandboxed bash (not the host shell)
Skills, memory, web search, as classified

On the host machine (your actual Linux user session):

host_file_read: read a file outside the workspace. Prompted.
host_file_write / host_file_edit: write or edit outside the workspace. Confirm-gated.
host_bash: run a command on the host with /bin/bash. Confirm-gated.

The model does not execute host commands itself. It asks a separate desktop process to do the work and report back. You see that request and allow or deny it. That is the whole host story for 0.1.

How shell is classified

Sandbox bash is parsed. Read-only programs (ls, cat, grep, git status, git log, git diff) classify lower. State-changing programs (sed, chmod, curl, git push) classify medium. Dangerous ones (sudo, rm, dd, reboot) classify high.

Approving git push is not approving git reset --hard. Patterns are specific.

Trust rules

Trust rules are persistent allow / deny decisions for a tool plus a glob pattern, scoped to a directory or everywhere. Deny wins over allow at equal priority. View them with cadence trust list and in Settings → Permissions & Privacy.

Third-party (non-bundled) skill tools prompt by default. Rules for those skills are bound to the skill’s content hash: if the skill files change, you are asked again.

Cross-channel approvals

If someone messages the assistant on Telegram or Slack and a tool needs permission, the request routes to you (the guardian). Grants are one-time, short-lived, and scoped to that tool input. They never become “always allow host_bash on this server.”

Untrusted actors cannot run host tools in-band. They cannot read guardian memory. See Channels.

When you say no

The action is blocked immediately
The assistant acknowledges the denial
It does not retry automatically
It may ask if there is another approach

A deny rule for a pattern blocks matching future attempts without asking again.