---
title: "MGS8004: output ref was produced on a different machine"
description: Fires when magus x <ref> resolves a reference but this workspace cannot reproduce it exactly, naming each differing field - platform, key version, magus version, VCS provider or revision - with both values, so the cause is stated rather than inferred.
tags: [output-ref, reproduce, cache-key, platform, diagnostics]
---

# 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**.

```text
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](MGS8001.md) - the ref names no stored output
- [MGS8003](MGS8003.md) - the argument is not a reference id
- [Output refs](../../../concepts/cache/output-refs.md)