---
url: https://docs.mochiexec.io/guides/workspace-trust.md
description: >-
  Decide which workspaces Mochi runs tasks from without asking, refine it per
  task with rules, and control what agents connected over MCP may run.
---

# Workspace Trust

A workspace's tasks are code someone wrote: yours, a teammate's, or whoever published the
repository you just cloned. Workspace trust records which of those authors you trust, so
Mochi asks before it runs anything from a workspace you haven't vouched for.

Trust is kept on this machine, in Mochi's config directory. It is never read from the
workspace itself, so a repository can't declare itself trusted.

## Trust states

| State | Meaning |
|---|---|
| **unknown** | You haven't been asked about this workspace yet |
| **trusted** | Its tasks run without asking |
| **restricted** | You said no. Each run needs your confirmation |

When you add a workspace in the desktop app, **Trust this workspace** is offered alongside
discovery. It starts checked for a folder you picked and unchecked for a Git repository.
Settings → Security & access lists every workspace's trust and its rules, and a workspace
you haven't trusted says so under its title.

From a terminal:

```sh
mochi trust list
mochi trust set api trusted
mochi trust set scratch restricted
mochi trust reset api    # forget the answer and ask again
```

## Where trust applies

| Who starts the run | Trusted | Unknown or restricted |
|---|---|---|
| You, in the desktop app | Runs | Asks first: **Trust and run**, **Run once**, or **Cancel** |
| You, typing `mochi <verb>` in a terminal | Runs | Runs. Typing the command is the confirmation |
| An agent connected to `mochi mcp` | Runs | Refused, with a message saying how to trust the workspace |

An agent can't answer a confirmation prompt, so a run that would need one is refused
rather than paused. The refusal names the command that trusts the workspace, and the agent
passes that on to you.

Ad-hoc commands an agent runs with `run_command`, `run_python`, or an inline
`run_executable` spec aren't covered by workspace trust. That code comes from the agent,
not the workspace's authors, so your MCP client's own tool approval governs it.

flow docs: [AI tools & MCP](https://flowexec.io/guides/ai-tools)

Every tool an agent gets from `mochi mcp`, including the ad-hoc ones above, and how to connect a client.

## Chat

Mochi's own chat agent follows the same trust.
When it wants to run a task from a workspace you haven't trusted, its approval card offers
**Trust and run** rather than Approve.

Settings → AI & Integrations → Confirmation mode has one mode built on trust:

* **Trusted tasks** runs tasks from trusted workspaces without asking, and asks before any
  other command or file write.
* **Autonomous** approves everything without asking, except tasks from workspaces you
  haven't trusted. Ad-hoc commands the agent writes itself still run without asking, even
  inside a workspace you haven't trusted, so it can run that workspace's scripts directly.

## Rules

Rules refine a workspace's trust for specific tasks. The first rule that matches wins;
without a match, the workspace's state decides.

* **allow** runs matching tasks without asking, in a workspace you haven't trusted.
* **ask** requires confirmation for matching tasks, in a workspace you have trusted.

```sh
mochi trust rule add scratch allow 'build *'
mochi trust rule add api ask 'deploy *'
mochi trust rule add api ask '*:prod-*'
mochi trust rule remove api 'deploy *'
```

A pattern is `[verb ]name`, matched against the task's `name` or `namespace:name`. `*`
matches any run of characters, including across nested namespaces. A verb also matches its
aliases, so `run *` covers `exec` and `execute` tasks too.

To see what would happen for one task:

```sh
mochi trust check deploy api:prod-db
```