MGS8004: output ref was produced on a different machine

magus x <ref> reproduces the invocation a reference recorded. Before running, it computes this workspace's cache key for that invocation and compares it with the key stored in the ref. When the two differ, the recorded artifact cannot replay and the target runs instead.

That much is not an error. This diagnostic exists because "it will run instead of replaying" is the half you already know; the useful half is why.

MGS8004: ref out13f5a539577d was produced on a different machine, so this runs the target rather than replaying it
  platform    recorded linux/amd64             here darwin/arm64
  vcs         recorded jj                      here git
  sources hash identically across platforms, so the artifact would be refused on import

Only fields that actually differ appear, so every row is part of the diagnosis.

What each row means

platform - GOOS/GOARCH. The strongest cause: readManifest and importArtifact refuse a cross-platform artifact regardless of any setting, so replay is impossible rather than unlikely. Source content hashes are identical across platforms - the same commit digests the same everywhere - which is precisely why the cache key cannot see this and the manifest guard has to.

key version - the KeyVersion that produced each key. Keys computed by different versions are not comparable at all, so this can never resolve into a replay no matter how identical the sources are. It changes only when magus changes which fields are hashed.

magus - the binary that recorded the ref. Informational: a different version often still reproduces, and is listed so a surprising result has a candidate cause.

vcs - the provider the revision came from (git, hg, jj). A git SHA and a Mercurial node id are both 40 hex characters, so magus compares revisions only when the providers agree; when they differ, the revision row is omitted rather than rendering a confident comparison of two unrelated identifiers.

revision - the commit each side's inputs were read at, shown only when the providers match.

What magus does about it

Nothing automatic, deliberately. It reports and then runs the target.

It never checks out the recorded revision: moving your working tree would discard uncommitted work to satisfy a diagnostic. The commit is named so you can decide.

A ref recorded from a dirty working tree carries a separate warning, because a revision alone cannot reproduce a tree that had uncommitted edits - Revision is necessary but not sufficient there.

Fixing it

• platform: reproduce on the same OS and architecture, or accept the rebuild. There is no way to replay another platform's artifact, by design.
• key version: use a magus whose KeyVersion matches the one that recorded the ref, or accept the rebuild. The key version changes rarely and always invalidates.
• revision: check out the named commit yourself, then re-run magus x <ref>.
• vcs: the workspace resolved a different provider than the recording machine. Autodetection probes markers most-specific-first, so a colocated jj repository - which contains both .jj and .git, because git is jj's storage backend - resolves as jj on both machines. A difference here means the two really are under different version control; set vcs.name to pin it.

See also

• MGS8001 - the ref names no stored output
• MGS8003 - the argument is not a reference id
• Output refs