Workspace Trust

Two moments: opening a project from the picker, and reopening your last project at startup. Bodega asks the backend whether the path is already trusted; if it is, nothing appears and the project opens.

The check fails closed - if it errors, the path is treated as untrusted. You get the prompt rather than a silent grant.

• Trust Workspace records the folder as trusted and opens it.
• Not now declines, and the project still opens. Declining is not a refusal to work in the folder; it is a refusal to apply the folder's config.

When you decline, a dismissible Project config inactive chip appears so the state is visible rather than assumed.

The enforced effect is a single, sharp one: an untrusted folder's .bodega/config.json is not loaded. The path behaves exactly as if the file were not there.

Even with trust, a project config can only set keys on a fixed allowlist - model and token settings, the persona prompt and name, agent iteration and dual-model settings, guardrail limits, the three panel prompts, editor formatting preferences, named run configs, and routing rules. Keys that would let a committed repo change where your prompts go or widen your exposure are global-only and are excluded on purpose: cloud escalation, the mixture tools, llama.cpp custom arguments, the shell environment policy, and the deferred-tools mode. A repo you clone cannot reach any of them, trusted or not.

Routing rules are the one entry with different mechanics - they are added above your own rules rather than replacing them, and a request they route always says so in its routed-by line.

Trust is not a filesystem sandbox. The agent's file access is bounded separately, by the project-directory enforcement described under Privacy & Security, and that applies whether or not you granted trust. Do not read the prompt as "nothing can be read or written until I approve".

Trust records live in a local SQLite table keyed on a normalised path - resolved to an absolute path, forward-slashed, and lower-cased on Windows only. A folder with no row is untrusted; granting trust is an idempotent upsert that also keeps the original path spelling for display.

Revocation exists in the backend and in the API client, but there is no UI button for it today - no settings row, no context-menu entry. If you need a folder untrusted, that is currently not something you can do from the app.

One behaviour to know if revocation does reach you: it is forward-only. It marks the record untrusted so future opens do not load the config; it does not retract config already applied to a running session. Reopen the project to be sure.

A repo can also ship skills in .bodega/skills/. Those are gated independently of workspace trust and are not covered by it - trusting a workspace does not approve its skills.

Unapproved project skills are refused outright: not loaded, not listed, not invocable. When a project has any, a "N skills need approval" chip appears; clicking it takes you to Settings → Skills, where each skill has its own Approve button.

Approval is keyed to the exact file contents and the exact project path. Editing an approved skill's file invalidates its approval and it has to be approved again - which is the point: the thing you approved is the thing that runs.