Workspaces & trust

Magic Coder is opinionated about where it can read and write. Two concepts make that explicit: workspace roots and trust.

What a workspace is

When you run coder, Magic Coder treats the current shell directory (resolved to the nearest Git/worktree root) as the primary workspace root. All file operations — reads, edits, deletes — must happen inside that root. The agent cannot escape the workspace.

To launch from a different directory, pass --cwd <path>. Either way, Magic Coder resolves the path to the surrounding repo root automatically.

Multiple workspace roots

Some tasks legitimately need access to more than one directory — say, a service repo plus a shared protocol-buffers repo. Pass --workdir (short -w) one or more times:

coder --cwd ~/code/service \
      --workdir ~/code/protos \
      --workdir ~/code/shared-utils

You can also pass a comma-separated list:

coder --cwd ~/code/service -w ~/code/protos,~/code/shared-utils

All of these directories become legal targets for file operations. None of them are required to be Git repos. The primary --cwd root is still the default location for shell commands; additional --workdir entries widen the file boundary, not the shell’s default location.

What trust is

The first time Magic Coder sees a workspace, it decides whether to trust it. Trust is a persistent decision recorded in ~/.magic/known.toml.

A workspace can be:

• Trusted — Magic Coder loads project-local skills and rules from <workspace>/.magic/, honors any remembered command-permission decisions for this workspace, can run with --automagic, and treats the workspace as a known-safe environment.
• Not trusted — project-specific permission rules are ignored. Most operations prompt for approval. Automagic refuses to start.

Untrusted is a deliberately conservative posture. It lets you run Magic Coder against a stranger’s repo (auditing a PR, exploring an unfamiliar dependency) without that repo’s project-local files automatically granting any permissions, skills, or rules.

How to grant trust

Three ways:

• At launch — coder --trust records the workspace as trusted before the session starts.
• At first run — Magic Coder prompts you the first time it sees a new workspace. Choose to trust it (or not) and the answer is remembered.
• By editing ~/.magic/known.toml — set trusted = true for the relevant entry. Magic Coder will pick it up next time.

Untrusting a workspace

Edit ~/.magic/known.toml and set trusted = false for the workspace, or delete the entry entirely. The next time Magic Coder opens that workspace, it’ll go through the trust prompt again.

What trust does not do

Trust does not widen the file boundary — only --workdir does that. A trusted workspace is still confined to its configured roots.

Trust does not auto-approve commands by itself. It just enables project-local skills, rules, and any remembered command-permission decisions. New commands still go through the approval prompt. See Command permissions.

Trust does not change anything about the model, the conversation, or your sign-in.

The known.toml file

Trust state lives in ~/.magic/known.toml. Each entry looks like:

[magic-coder-tui-3f2a9b7c]
path = "/Users/you/code/magic-coder-tui"
trusted = true

[some-other-repo-91a4d2c8]
path = "/Users/you/code/some-other-repo"
trusted = false

The key is the workspace’s last path segment (sanitized to [a-zA-Z0-9_-]) plus a 4-byte SHA-256 prefix of the absolute path — so two workspaces named frontend in different directories don’t collide. You don’t write this file by hand normally — Magic Coder maintains it through the trust prompt and --trust — but it’s plain TOML if you want to.

If you accidentally trust a workspace you didn’t mean to, find the entry, set trusted = false, and save. Or delete the entry.

Resolving —cwd

--cwd accepts any path inside a Git or worktree-rooted project; Magic Coder resolves it upward to the project root automatically. So all of these end up at the same workspace if you’re inside one repo:

coder
coder --cwd ~/code/myrepo
coder --cwd ~/code/myrepo/src/components

If --cwd doesn’t sit inside a Git/worktree project, Magic Coder uses the path as-is and treats it as the workspace root.

When to use multiple roots vs. opening from one

If two repos genuinely need to be edited in the same task — say, a frontend and a backend monorepo — pass both as workspace roots from one coder invocation. That keeps the agent’s view consistent.

If two repos are conceptually separate work, run two coder sessions. Resumable threads (--continue) make it cheap to switch between them later.