"A code-built world can run TWICE on a network join and stack a second world on the first"

Your world is built in code (procedural placement of props, climb fields, ropes, etc.). On a network join you notice the joining client has roughly twice as much of some things as the host. Concretely, in one verified session: host reported rows=74 climbs=8 ropes=4 throwables=10; the joining client reported rows=96 climbs=16 ropes=8 throwables=20, exactly 2× the climb fields, ropes, and throwables, while boxes=14 and kit=38 stayed single.

A world-hash guard that compares peers then flags a mismatch, and depending on your collision setup the doubled geometry can be visible or subtly wrong.

A network-joining client can run the scene's code-built world twice: once when the local StartupScene loads, and again on the networked-session scene handoff. If the world author is not idempotent (it clears its static tracking lists at the top of each build but never destroys the GameObjects a prior build created), the second build stacks a whole second world on top of the first.

The tell for which mechanism doubled a given count:

• Counts sourced from a live scene scan (Scene.GetAllComponents<T>()) double, because there really are two sets of objects in the scene.
• Counts sourced from a per-build static list (cleared at the top of each build) stay single, because the list only reflects the most recent build.

That split is the proof it was a second build, not network replication: a non-networked component (one with no [Sync]/NetworkSpawn, which physically cannot replicate) still doubled. Replication cannot explain a doubled non-replicated component; a second OnStart-driven build can.

Two independent fixes, do both:

1. Make the code-built world author idempotent. Before rebuilding, destroy the prior world root (or skip the redundant build entirely on a joining client). A second OnStart on join is real. Design for it:

   snippet

   Copy code

   protected override void OnStart()
   {
       WorldRoot?.Destroy();          // tear down any prior build
       WorldRoot = new GameObject("World");
       BuildWorld(WorldRoot);
   }

2. Compute any determinism / MP-sync world hash from the build RECIPE, not a live scan. Hash the static placement lists (the inputs to the build), not Scene.GetAllComponents. A recipe hash cannot be perturbed by a second build or a replicated proxy, so a join-time world-hash guard compares each peer's own deterministic build apples-to-apples.

The doubling comes from state that accumulates in the scene surviving across two builds. Destroying the prior root removes that accumulation, so a second build produces one world, not two. And hashing the recipe rather than the live scene decouples the integrity check from scene population entirely. The number of GameObjects currently alive (one build, two builds, or a set of replicated proxies) no longer changes the hash, so the guard measures the thing you actually care about: whether two peers agree on what to build.