"Headless dotnet build skips sandbox whitelist enforcement"

Code builds with zero errors in a headless dotnet build (a scratch .csproj referencing the engine's prebuilt base library DLL). The same code then fails the editor compile with:

SB1000 '<member>' is not allowed when whitelist is enabled

The headless build gave a false green, and the real failure only surfaced in the editor.

The s&box sandbox enforces an access-control whitelist via a custom Roslyn analyzer that ships with the editor's compile pipeline. A headless dotnet build against the prebuilt assemblies uses the standard Roslyn toolchain, which does not load or run the sandbox analyzer. The whitelist bans surprising corners of System.Private.CoreLib at the member level (e.g. Array.Clone() is blocked), and these member-level bans cannot be detected by a plain Roslyn build.

This is the false-PASS counterpart to the shared-obj CS0579 false-FAILURE trap: headless builds can both false-fail (from double-globbed intermediates) and false-pass (from missing whitelist enforcement). The editor does neither.

Treat the in-editor compile_status as the only authoritative pre-merge compile gate. The headless build proves syntax and type correctness only — it is useful for fast iteration but must never be the final gate.

When a headless build passes, always verify with an editor compile before merging or publishing. If the editor raises SB1000, replace the banned member with a whitelisted alternative (e.g. ToArray() instead of Array.Clone()).

The editor's compile pipeline includes the sandbox analyzer that enforces the whitelist at the Roslyn analysis phase. No external build configuration can replicate this — the analyzer is distributed with the editor, not as a standalone NuGet package. The editor compile is the single source of truth for sandbox compliance.