MGS1010: affected set could not be computed

magus could not ask the VCS which files changed, so it selected every project rather than risk running nothing.

[MGS1010] affected: could not compute a changed-file set, so EVERY project was
selected. This runs a full build, not an incremental one. Reason: affected:
cannot compute affected set: git merge-base: exit status 128

The run is correct. It is just not the run you asked for.

Why

magus affected <target> exists to run a target only for the projects a VCS diff touched, plus their dependents. When the diff cannot be computed, magus has two choices, and only one of them is safe: select everything, or select nothing. Selecting nothing would let a gate exit 0 having checked no code, which is the most expensive failure a pipeline can have - so magus over-builds instead. That decision is deliberate and it is not going to change.

What the fallback costs is time and truth. You are paying full build cost while believing you have an incremental one, and on CI that difference can be the whole budget. Worse, it is stable: a misconfigured base ref does not fail loudly once, it silently degrades every run forever.

A shallow clone used to be the commonest cause on its own. It no longer is: when the merge base is missing and the repository is shallow, magus fetches progressively more history until the common ancestor appears, and only reports MGS1010 if that recovery cannot run. So a shallow checkout reaching this diagnostic means the deepening itself failed:

• The runner has no network, or the remote is unreachable.
• The base ref names a branch the remote does not have (origin/master against a repository whose default branch is main).
• The base is not a remote-tracking name at all, so there is nothing to deepen from - a bare SHA the clone does not contain, or a local-only branch.

Independently of depth:

• The configured base ref does not exist in this clone (a branch that was never fetched, or a typo in vcs.base_ref / MAGUS_VCS_BASE_REF).
• The workspace is not a repository at all - a source tarball, or a container build that copied files in without .git.
• The VCS binary is missing from the image.

Fix

Give CI a base branch it can reach. For GitHub Actions:

- uses: actions/checkout@v5
  with:
    fetch-depth: 0
    filter: blob:none # commit graph only; history's file contents stay on the server

filter: blob:none is the important half. affected reads tree identities, never a historical file's contents, so the blobs a full clone downloads are pure cost - 96% of the payload in magus's own repository, and a share that grows with age. A bounded fetch-depth works too, since magus deepens past it when a branch outruns it. See CI checkout for the per-provider recipes and the measurements behind this.

Verify the base ref resolves. magus doctor probes it directly and reports a vcs base ref failure when it does not. magus affected --explain <project> shows what magus believed changed and why a project was selected.

Check the ref name. Configure it explicitly rather than relying on the default when your default branch is not the one magus assumes.

Where you see it

On a terminal, magus affected already reveals this in its scope line, which carries the reason:

projects: . (affected: cannot compute affected set
git merge-base: exit status 128)

The diagnostic exists for the callers that have no scope line - notably the MCP run_affected tool, where an agent would otherwise be told only that the run passed, with no way to know it had just built the entire workspace instead of the affected set.

Not a bug when

You are running affected in a workspace with no VCS on purpose. There is nothing to diff, so the fallback is the only correct behavior. If that is your steady state, run the target directly with magus run and skip the pretense of an incremental selection.