msb --clone: scratch clone's origin is the host checkout path, so push and fetch in the guest target the clone itself #453

What happens

acq run <agent> <path> --clone on msb creates the scratch with git clone --no-hardlinks <host-path>, so the scratch's remote.origin.url is the host checkout directory. The scratch is then mounted in the guest at that same absolute path, which means origin resolves to the mounted scratch itself: git ls-remote origin returns the clone's own refs (frozen at clone time), git fetch origin is a no-op, and git push origin <branch> cannot reach the real remote.

sbx --clone copies .git wholesale and keeps the real origin, so the two backends diverge on what origin means inside a --clone sandbox. Anything that relies on the origin URL in the guest breaks on msb only: pushing a branch, fetching refs/merge-requests/N/head or refs/pull/N/head, and kit startup steps that identify a repo by git remote get-url origin.

Repro

acq main d2f4bdc, msb 0.6.17, macOS host. Host checkout origin is [email protected]:GSA-TTS/agentic-coding-quickstart.git.

$ acq run opencode ~/Code/agentic-coding-quickstart --clone
$ acq exec opencode-agentic-coding-quickstart -- sh -c 'git config remote.origin.url; git ls-remote origin | head -2'
/Users/<me>/Code/agentic-coding-quickstart
d8f66a43d10a01ce8318194bb0c82518a69e1346	HEAD
d8f66a43d10a01ce8318194bb0c82518a69e1346	refs/heads/main

The refs are the clone-time snapshot, not the remote's. On the host, git -C ~/.local/state/acq/clones/<sandbox>/<repo> config remote.origin.url shows the same path.

Proposed fix

After git clone, set the scratch's remote.origin.url to the source checkout's effective origin URL (git -C "$ws_canon" remote get-url origin), the same propagation shape as #443 uses for the git identity. If the source has no origin, leave the clone as is. The sandbox-<name> fetch-back remote on the host is unaffected.

Workaround until then, inside the sandbox: git remote set-url origin <real url>.

AI-assisted: yes.