Workspace trust

A repository can carry its own Orrery configuration: .orrery/config.toml, extensions, agents, skills, MCP servers. Those can run code. So a workspace nobody has vouched for does not load any of it.

Until you answer, every command says the workspace is not trusted, and only the managed, organisation and user layers apply.

#Decide

orrery trust grant              # the current workspace (or the one --workspace names)
orrery trust grant ~/code/app
orrery trust revoke ~/code/app  # forget the answer: untrusted again
orrery trust list               # every stored answer, and this workspace's

Answers are stored in ~/.orrery/trust.toml, never inside a workspace, so a project cannot vote itself trusted.

#How the answer is reached

In order, the first that applies:

1. A managed trust.mode = "never": untrusted, and nothing closer can change it.
2. Your stored answer for this path.
3. trust.auto = true or trust.mode = "always" in the managed, organisation or user layer.
4. Otherwise: untrusted.

The trust decision is made from the managed, organisation and user layers alone, before anything in the workspace is read. An extension cannot influence the decision that governs whether it loads.

#What still works untrusted

Everything from your user layer: your providers, your extensions in ~/.orrery/extensions, your skills and agents. That is why setup guides put providers in ~/.orrery/config.toml.

Running orrery from your home folder, or above it, has no workspace layer at all: its .orrery would be your user folder.

#Secrets in a workspace file

A workspace file is committed, so it may only name a secret's variable (apiKey = "$GEMINI_API_KEY"). A literal secret there is refused, with the fix in the message.