magus v0.4.3 is out. See what's new
¶ View markdown source · ✎ Suggest an edit
1 min read

sibling-checkout

A deny rule by default: it refuses a magus command relocated into another checkout, judging a tree nobody ships, and names what to run instead.

What it catches

A magus command relocated into another checkout, judging a tree nobody ships.

Why

A binary links the spell sources of the tree it was built from, so a verdict it reaches about a DIFFERENT checkout describes a tree that exists nowhere, and anything it regenerates lands there unmarked. Run magus from the workspace it belongs to and name the project as an argument; a different workspace is --root <path>.

Default and override

By default this rule takes the decision deny. A workspace sets it by name, in its root magusfile, to deny, advise or off:

magus\guard.builtins({"sibling-checkout": "advise"})

A loosening takes effect once it is committed; a tightening applies at once.

Seeing it

A verdict names its rule in brackets, which is how you got here:

deny [sibling-checkout]: ...

A workspace that sets this rule to advise sees advise [sibling-checkout]: ... instead.

magus describe rule sibling-checkout prints the same entry at a terminal, and magus describe rules lists every rule this workspace enforces.

See also

ReferencePages in this section. raw-tool: a toolchain command a spell already wraps, run outside the cacheA deny rule by default: it refuses a toolchain command a spell already wraps, run outside the cache, and names what to run instead. worker-check-only: a bound worker running other than its check or a writer of its write paths, or writing past themA deny rule by default: it refuses a bound worker running other than its check or a writer of its write paths, or writing past them, and names what to run instead. magus stdlibReference for every magus stdlib module - fs, os, http, json, yaml, crypto, and the rest of the magusfile API.
guardrulessibling-checkoutdeny
Last updated (c6a327d5)
Earlier changes on this page (3)

Full history ↗ · Blame source ↗

Glossary

Workspace

The magus root directory that owns a set of projects and shared config; the unit magus operates over. Workspace in full.

Project

A directory magus recognizes as a unit of work (it has a magusfile); the unit of caching, scheduling, and dependency tracking. Project in full.

Magusfile

The magusfile.buzz that declares a project's targets (as export funs) and binds its spells. Magusfile in full.

Spell

A language/runtime adapter (e.g. go, md) that maps generic targets onto a toolchain's real commands. Spell in full.

Buzz

The language magusfiles are written in (the .buzz engine). Buzz in full.

CI

An ordinary target you compose yourself with ctx.needs; magus does not hardcode its stages. It is the anchor magus affected ci keys off, and ci strips the rw charm. CI in full.

Agent

A model working through an agent host such as Claude Code, Codex, Cursor or OpenCode. magus treats an agent as one more caller of its CLI, MCP tools and console, held to the same checks as a person. Agent in full.

Run

One target executing under one magus invocation, such as magus run test web or magus affected ci. A run keeps its captured output behind an output reference. Every magus run is a run whether or not any job asked for it; see Job for how the two relate. Run in full.

Conventions

Placeholders

Angle brackets mark a value you replace with your own; never type the brackets:

magus run <target>
magus completion <shell>    # e.g. bash, zsh, fish

<target>, <path>, <shell>, <name> and the like are stand-ins, not literal text.