the symptom, in your words

"Editor stuck running stale assembly with green compile — only a restart clears it"

✓ verified on engine 26.07.08elane: Tooling & environmentposted

▸ SYMPTOM

The editor runs stale game code even though compile_status shows Success with zero errors and NeedsBuild=false. None of the standard recoveries work:

  • touch / mtime bump on the source file — no effect
  • Dirty/clean syntax-error cycle (inject error → green again) — code still stale
  • play_stop + play_start — same old behaviour
  • In-play console-triggered rebuild — uses old code

A unique Log.Info("MARKER") added at the top of a method never prints, while the method's old log lines keep appearing. Changed static defaults stay at their pre-edit values.

▸ CAUSE

The editor's live assembly domain is stuck on a previously-loaded snapshot. The compiler accepts and successfully compiles edits (proving it with a syntax error cycle), but the runtime domain never swaps to the new assembly. A strong correlate is multiple editor instances of the same project open simultaneously — the assembly file lock / hotswap contention between instances appears to freeze the live domain's code-load path while each instance's compiler independently reports green.

This is distinct from:

Here, the play session is healthy — convars work, the world builds, everything runs — it just runs old code.

▸ FIX

A full editor process restart is the only recovery. Close the editor completely, verify no duplicate instances are running, and relaunch.

Verification gate for any automated workflow: a green compile_status is NOT proof the runtime runs your latest code. Confirm with a unique runtime marker (a Log.Info with a fresh token) before trusting any in-editor behaviour result.

Prevention: avoid running multiple editor instances of the same project simultaneously.

▸ WHY IT WORKS

Restarting the editor process forces a cold assembly load from the freshly-compiled DLL, bypassing whatever lock or cache prevented the hot-swap. The compiler is a separate concern from the runtime domain's assembly loader — green compile only proves the build artifact exists, not that the runtime has loaded it.

Verified on engine 26.07.08e — seen in a real project.
s&box moves fast; an undated fix is a liability. Spot a stale detail?

Want to know when new guides or fixes drop? Join the community to help build this out — report gotchas, flag outdated fixes, or just lurk.

Join the Discord