Workspace trust

Launching a coding agent gives a third-party program your Melious credential and lets it run as you, with your permissions, in a project. Workspace trust records your consent for that location. It isn't a sandbox: a trusted agent can do anything you can.

We'd rather ask once per project than never. Trust is stored on your machine, per project, and every melious launch checks it before the agent starts.

Trust the project you're in:

melious trust add

Trust a project

melious trust add records trust for the current directory. Name a path to trust somewhere else:

melious trust add <PROJECT_PATH>

Melious resolves the path to the project it belongs to: the top of the Git worktree, or the directory itself outside Git. Trusting src/ inside a repository records the repository root. Running the command is the authorization, so there's no further question for a normal project. A location too broad to trust asks you to confirm twice; see when Melious refuses a location. It works without an API key, and it contacts nothing.

What it prints once the grant is saved:

  ✓ Workspace trust recorded

    ~/code/shop

  Melious launches supported coding agents from a workspace with
  Melious-managed configuration and your account credential in the agent's
  environment. The agent runs as you, with your permissions — this is
  authorization, not a sandbox.

  Trust follows the location, not the contents. Pulls, branch switches, and a
  replacement checkout at this path stay trusted until you revoke it.

  Revoke with: melious trust remove <path>

Answer the prompt on first launch

If you launch in a project you haven't trusted yet, Melious asks first:

┃ Trust this workspace?
┃ ~/code/shop
┃
┃ The agent runs as you, with your permissions — this is authorization, not a
┃ sandbox. Trust follows the location, not the contents: pulls, branch switches
┃ and a replacement checkout at this path stay trusted until you revoke it with
┃ melious trust remove <path>.
┃
┃                                  Yes     No

←/→ toggle • enter submit • y Yes • n No

The answer defaults to No. Say yes and Melious records the grant, then continues the launch. Say no and nothing is recorded, the agent doesn't start, and Melious prints the two commands that would let it:

  ✗ Workspace not trusted

    ~/code/shop

  Launching here would start a coding agent with your account credential
  in its environment, reading this workspace's own configuration.

  Trust it: melious trust add
  Just this once: melious launch claude-code --trust-once

Without a terminal, a launch in an untrusted project prints the same message and exits 1.

If Melious can't write the grant, the launch doesn't go ahead. It reports that it could not record workspace trust, and a yes that didn't save authorizes nothing.

Melious only asks once the agent is installed, so you won't record trust for a launch that can't happen. The launcher in bare melious asks the same question, with Cancel preselected.

See what you've trusted

melious trust list

Each entry shows the project path, when you trusted it, and its ID: a 64-character hex string that identifies the record.

  Trusted workspaces

  ✓ ~/code/shop
    trusted 2026-10-18 22:54 UTC
    ce6ae639bedb4a41c303517588e7e7b4f3f6d686948d45dd859ea511a6328aca

  Revoke with: melious trust remove <path|id>

melious trust list --json gives the same list for scripts. Like trust add, it creates nothing and contacts nothing.

Revoke trust

Remove trust by path. A subdirectory of the project works too:

melious trust remove <PROJECT_PATH>

If the project folder was deleted, or it lives on a volume that isn't mounted right now, the path no longer resolves. Remove the record by its ID from melious trust list instead:

melious trust remove <TRUST_ID>

Launch once without recording

--trust-once authorizes one launch and writes no grant:

melious launch <TOOL> --trust-once

It's an explicit authorization, not a way around the check. Melious still resolves and validates the location, so it still refuses your home directory and the other locations Melious refuses. The next launch in that project asks again.

Launch from scripts and CI

Without a terminal, Melious can't ask the question, and the answer is no. The launch fails with a non-zero exit and prints the remedies on stderr. Two ways through:

• Record trust ahead of time. Run melious trust add <PROJECT_PATH> once, as a setup step. Later launches find the existing grant.
• Authorize each run. Pass --trust-once on the melious launch line.

--quiet doesn't suppress the question or change its answer. It controls output, and trust is a decision. There's no environment variable or --yes-style flag that answers the question for you.

When Melious refuses a location

Some locations are too broad to trust by default, with or without --trust-once:

• your home directory, and any directory that contains it
• a filesystem root, a volume root, or a network share root
• a directory widened above the one you named, on macOS and Linux (see below)

The refusal names the path and the fix. Here, melious launch claude-code --trust-once in a home directory:

Error: workspace is too broad to trust: ~ is your home directory — trust a specific project directory instead

On your machine, the message shows the full path.

Trust the specific project instead: cd into it, or name it with melious trust add <PROJECT_PATH>.

Accept the risk

If you really mean to trust such a location, melious trust add offers a double opt-in on a terminal. First, a yes/no question that describes the risk. Then you type accept the risk exactly. Only when both answers are given is the location recorded, and melious trust list marks it as accepted at its own risk. Without a terminal, trust add refuses and says that accepting the risk needs one.

The TUI has the same opt-in under Settings → Trusted folders: press a, enter the path, then answer the same two questions. melious launch doesn't offer it. A launch in a location that's too broad is refused, and the refusal points you to a specific project directory.

On macOS and Linux, one more refusal applies. You trust a subdirectory, and the .git Melious finds sits in a parent directory that other accounts can write into, or that's owned by an account other than you or root. Whoever controls that directory controls the configuration the agent reads, so Melious won't widen your grant to it.

Follow the remedy in the message: fix the directory's permissions, remove a .git you didn't expect, or run git init in the directory you meant to trust. If the parent really is your project, name it outright with melious trust add <PROJECT_PATH>. That's your call to make, and Melious accepts it. Windows doesn't apply this permission check.

Damaged trust records

A trust record Melious can't read is an error, never a bypass. A launch in that project stops with the error instead of asking or starting the agent.

melious trust list marks damaged records with a cross and says why, with the command that removes each one:

  Trusted workspaces

  ✗ ""
    unreadable: "" is not a workspace ID
    remove it with: melious trust prune
  ✗ 55aaa140a3c77116333ee281ab70bdd67282d56a5f21729cca9d6805488c2607
    unreadable: unsupported record schema version 99
    remove it with: melious trust remove <id>
  ✗ not-a-workspace-id
    unreadable: "not-a-workspace-id" is not a workspace ID
    remove it with: melious trust prune

To clean up:

melious trust prune

trust prune removes only records whose contents can't be a grant at all. It keeps and reports the rest: a record written by a newer Melious version, one it couldn't read, and one whose project folder is missing. A missing folder might be an unmounted volume, and that isn't proof you meant to revoke anything. Remove those yourself with melious trust remove <TRUST_ID>.

trust prune can exit non-zero even after it pruned something, because it also reports the records it kept. Read its output, not only the exit status.

What trust covers

• The location, not the contents. Pulls, branch switches, and a replacement checkout at the same path stay trusted until you revoke them. We chose this because trust tied to contents would ask again on every commit, and a question asked that often gets answered without reading.
• One project, no inheritance. A grant covers its project root and nothing above or below it. A nested repository with its own .git is a separate project, and so is a parent directory.
• The real path. Symlinks resolve to the directory they point at, so a link and its target share one record.
• Case on macOS. On a case-insensitive volume, two spellings of one path can end up as two records. Revoking one leaves the other, so check melious trust list after you revoke.
• Version checks. The launcher in bare melious doesn't run an agent's version check in a project until you've trusted it. Explicit tools commands, such as melious tools, melious tools check, and melious tools info, run each agent's version check in your current directory without asking. If you don't want an agent binary run in a directory you haven't trusted, run those commands from somewhere else.