Unity Visual Scripting Graph Not Saving Changes - Autosave and Version Control Fix

Unity Visual Scripting (formerly Bolt) stores logic in Script Graph and State Graph assets. When those graphs do not persist after you close the Graph window, restart the editor, or pull from Git, the problem is rarely “Unity forgot Visual Scripting” — it is usually save targeting, Play Mode versus Edit Mode state, prefab instance versus asset edits, or a bad merge on the underlying .asset / .prefab text.

Why this spikes now: Teams on Unity 6.x and recent Visual Scripting package lines iterate faster with Enter Play Mode Options (sometimes Reload Domain off), collaborate through Git on YAML graphs, and often keep projects in cloud-synced folders where delayed sync can make it look like saves never landed. Those three patterns together produce a lot of “my graph reverted” reports that are actually workflow and merge issues.

Fastest path: confirm you are editing the asset (or the prefab root) you think you are, press Save / Save Project after graph edits, exit Play Mode before trusting on-disk state, and diff the correct .asset in Git — not only the Script Machine host object. Success looks like: the graph file’s timestamp and hash change when you edit, Play Mode behavior matches Edit Mode after a domain reload, and teammates stop seeing empty or duplicated graph blocks after merges.

Direct answer

Graph changes vanish when Unity never writes them to the serialized graph asset, when you edited a prefab instance that discards overrides, when Play Mode or domain-reload-off left you looking at in-memory behavior that does not match disk, or when version control merged YAML incorrectly. Fix it by saving all (Ctrl+S / File → Save plus Save Project when needed), applying prefab edits to the right object, re-opening the graph from Project to confirm, and teaching Git to treat graph assets as binary or using locked checkout for shared graphs.

Who this affects

Projects using Unity Visual Scripting with Script Machine / State Machine on GameObjects or prefabs
Teams where designers edit graphs but programmers merge branches without Unity open
Anyone using Enter Play Mode Options without Reload Domain, where stale singleton-style listeners can make “saved” behavior look inconsistent
Repositories in sync clients (OneDrive, Dropbox, iCloud Drive) that delay writes to .asset files

Root causes

Cause	What you see
Graph edits on a prefab instance only	Overrides lost on Apply mismatch or Revert
Subgraph / Super Unit reference broken after move	Graph compiles but missing nodes or reverts after reimport
Play Mode edits mistaken for Edit Mode saves	“It worked in Play” but asset on disk unchanged
No explicit save before editor close	Batch save did not include the Graph inspector focus
Git merge on YAML graph	Duplicate node IDs, empty graph, or corrupt Ludiq data
Two Unity instances on same project	Locked files; last writer wins
Cloud sync conflict copies	Older `.asset` replaces newer locally

Step-by-step fix

1. Save the graph asset, not just the scene

With the Graph window open, make a trivial edit (add a comment node and remove it) to force dirty state.
Click into the Project window and select the Script Graph / State Graph asset referenced by your Script Machine (follow the Graph field on the component).
Use File → Save (or Ctrl+S) and then File → Save Project once.
In your file system or Git, confirm the .asset file for that graph updated its modified time.

Verify: Close the Graph tab, reopen the asset from Project — edits remain.

2. Prefabs — edit the asset or apply overrides deliberately

If the Script Machine lives on a prefab instance in a scene, open the Prefab in Prefab Mode when changing the default graph for all instances.
If you intend per-instance logic, keep overrides but use Apply All / Apply only after reviewing the Graph override in the Inspector.
Avoid mixing instance edits with multi-object Inspector batches; Unity can drop non-default references on batch apply.

Verify: In Prefab Mode, edit graph → Save → exit Prefab Mode → re-enter — changes still present.

3. Play Mode and Enter Play Mode Options

Remember: Play Mode changes to serialized assets are often not what you want; Unity may revert when exiting Play unless you use explicit workflows for Play Mode editing (generally avoid for graph assets).
If you use Enter Play Mode Options with Reload Domain disabled, pair graph testing with occasional full reload tests so you do not ship static-state assumptions that only appear after a fresh domain. See Unity 6.5 Enter Play Mode Freezes on Domain Reload Off.
After testing, exit Play and re-open the graph from disk to confirm behavior matches.

Verify: Edit → Project Settings → Editor → Enter Play Mode Options documented in your runbook; QA smoke test with Reload Domain enabled before release candidates.

4. Version control: avoid blind YAML merges on graphs

Treat large or critical Visual Scripting assets as merge-sensitive. Prefer exclusive lock (Perforce style) or Git LFS with a binary merge rule for *.asset that contain graphs, if your team sees repeated corruption.
On Git, if a merge introduces weird node duplication, abort the merge hunk and re-apply edits inside Unity instead of hand-merging YAML.
Always open the project in Unity once after a merge and reimport the graph asset if inspectors show missing types (package version mismatch).

Verify: git diff shows intentional changes only; Unity Console has no Visual Scripting serialization errors after pull.

5. Package and type consistency

In Window → Package Manager, note Visual Scripting version; align Package Manager lock / manifest.json across the team.
If graphs reference custom nodes, ensure the assembly with [UnitTitle] / [UnitCategory] attributes is compiled before graph load (assembly definition order).
Run Tools (menu) for Visual Scripting Node generation / regeneration if your version exposes it after upgrading Unity or the package.

Verify: Project window — no yellow Script warnings on the Script Machine; graph opens without missing types.

6. Cloud sync and duplicate editors

Pause sync or move the repo to a non-synced path if .asset timestamps “jump backward.”
Ensure only one Unity Editor holds the project.

Verify: Save graph → immediate dir listing shows new mtime; no .tmp conflict files from sync clients.

Alternative fixes

Embed vs linked graph: For small machines, embedding can reduce stray asset references; for reuse, prefer linked assets but centralize them under a single folder with clear ownership.
Subgraphs: If a Subgraph was moved on disk, reassign the reference in the parent graph once to clear a hidden broken path.
Backup: Duplicate the .asset before risky merges; Unity’s Version Control integration or a simple branch is cheaper than rebuilding a large graph.

Verification checklist

[ ] Script Graph .asset mtime updates on save
[ ] Reopen Unity — graph intact
[ ] Prefab variant overrides intentional
[ ] CI or teammate pull — no serialization errors
[ ] Play Mode exit — no unexpected rollback in Edit Mode

Prevention tips

Put Visual Scripting assets in a dedicated project folder with CODEOWNERS or team convention for merges.
Add a pre-merge habit: open Unity, open each touched graph, save, exit.
Document Enter Play Mode Options for your team and when to re-enable full domain reload before builds.
Keep Package Manager versions pinned in Packages/manifest.json with short changelog notes when Visual Scripting bumps.

FAQ

Does Unity autosave Visual Scripting graphs?
Unity autosaves some editor state, but you should not rely on it for critical graph work. Use explicit Save and watch the asset on disk.

Why did my graph empty after Git merge?
A YAML conflict often produces invalid Ludiq serialization. Revert the file to one side and re-apply edits in Unity.

Can Play Mode edits to graphs stick?
Assume no unless your workflow explicitly supports editing serialized assets in Play. Default expectation: exit Play and edit in Edit Mode.

Does Visual Scripting work with DOTS / ECS?
This article targets GameObject-hosted Script Machine workflows; ECS projects should validate official compatibility for their Unity version before relying on the same save patterns.