"An output-path override can poison the engine's base addon and stop it booting"

• The engine refuses to start with "Failed to bootstrap engine".
• The errors report duplicate System.Reflection.Assembly*Attribute definitions, and they point straight into addons\base\Code\.build.
• The trap is intermittent. Several ordinary builds pass, then one rebuild trips it.

An s&box game csproj project-references the engine's Base Library csproj inside the Steam install. A repo's own Directory.Build.targets cannot protect that referenced project. MSBuild imports each project's own directory ancestry, and the engine tree carries no Directory.Build.* of its own. So generated intermediates, such as AssemblyInfo.cs and other attribute files, land inside the engine tree even when the caller passes an absolute -p:OutputPath.

The trigger is the first build of that graph, or any -t:Rebuild. A plain incremental build afterward leaves the engine tree untouched, which is why the trap does not show up on every run. Once the generated attribute files exist under the base addon's own Code\.build, the engine's bootstrap compiler finds duplicate attribute definitions and refuses to start.

-p:BaseIntermediateOutputPath is not the fix. It is a second trap. It is also a global property, so every project in the graph is forced to share one intermediate directory, and non-project-named generated files such as project.assets.json then collide across projects that were never meant to share a folder. A relative override is worse still. Each project resolves the relative path against its own directory, so a custom-named build folder gets sprayed under every referenced project's folder, including steamapps\common\sbox\addons\base\Code\, not just the top-level project's.

One related trap appeared in the same incident. A build running under a propagated broken path can report success while reporting a near-zero warning count, because the referenced projects are misresolving rather than actually compiling clean. A warning count far below the known baseline is a propagation symptom, not a win. Treat it as a broken build.

1. Close the editor.
2. Delete addons\base\Code\obj\ under the engine install.
3. Delete addons\base\Code\.build\ under the engine install. Both folders regenerate.
4. Relaunch.

To prevent it: never override BaseIntermediateOutputPath for a verification or measurement build. Do not assume an absolute -p:OutputPath alone is safe either. The project reference to Base Library still pulls generated intermediates into the engine tree on a first build or a full rebuild, whatever the output path is set to.

The duplicate attribute files under the base addon are the whole cause of the boot failure, and both folders regenerate, so deleting them removes the bad state without losing anything. Keeping a global intermediate override off the build stops MSBuild from forcing projects to share one folder. Leaving the output path at its default for the base addon keeps generated files out of the engine tree, so the next boot finds one set of attributes instead of two.