Two relayfile-mount builds share one name and reject each other's flags, with no --version to tell them apart

[khaliqgant]

What happens

There are two relayfile-mount binaries in circulation with different, incompatible flag sets, and nothing tells you which one you have until a mount fails.

The copy vendored inside agent-relay@11.8.3 (@relayfile/mount-<platform>-<arch>/bin/relayfile-mount) accepts --local-layout and --state-dir. The copy installed at ~/.agent-relay/bin/relayfile-mount on a machine that has been running the CLI for a while rejects both:

$ ~/.agent-relay/bin/relayfile-mount --local-layout exact --state-dir <dir> ...
flag provided but not defined: -local-layout
Usage of /Users/<user>/.agent-relay/bin/relayfile-mount:
  -base-url string
  -fuse
  -interval duration
  -interval-jitter float
  -local-dir string
  -mode string
  -once
  -provider string
  -remote-path string
  ...

Note what is missing from that usage list: no -local-layout, no -state-dir.

Why it matters

Go's flag package exits non-zero on an unknown flag, so this is not a warning that degrades gracefully — the daemon never starts. And because both binaries are named relayfile-mount and both are installed by Agent Relay tooling, a script that works on a sandbox fails on a laptop with an error that reads like a typo rather than a version skew.

This bites anything expected to run on both sides of a sync. It bit me directly: buildRelayfileMountStartShell in @agent-relay/sandbox emits --local-layout and --state-dir unconditionally, so the exact command that started a healthy daemon inside a sandbox died instantly on the host when I tried to mount the same scope to verify a round trip.

Observed

	build	--local-layout	--state-dir
Agent37 sandbox	vendored in agent-relay@11.8.3	accepted	accepted
Daytona sandbox	/usr/local/bin/relayfile-mount, image …relayfile-v0.10.49…	accepted	accepted
macOS laptop	~/.agent-relay/bin/relayfile-mount	rejected	rejected

Measured 2026-08-25. relayfile@0.10.49 was the version installed from npm on the sandboxes.

What would help, in rough order of value

1. A --version flag. relayfile-mount --version currently fails with flag provided but not defined: -version, so there is no way to ask a binary what it is. Right now the only way to identify a build is to inspect which flags it rejects.
2. Whatever installs ~/.agent-relay/bin/relayfile-mount should refresh it, or the path should be retired in favour of resolving the vendored copy — a stale binary at a well-known path with no version affordance is the actual trap.
3. Failing an unknown flag with a message that names the binary's own version, rather than only its usage.

Found while measuring sandbox provider deployability (AgentWorkforce/sandbox#42). Not a sandbox fault, filed here separately at chief's request. Filing rather than fixing — I do not own this code, and I do not know which of the two builds is intended to be canonical.