Unity 6.6 LTS Asset Import Worker Hangs on First Project Import After 2026.2 Upgrade - How to Fix

Problem: After upgrading a project from Unity 2026.1 to Unity 6.6 LTS / 2026.2, the Editor reaches the Hold on... Importing Assets progress bar and never advances. Editor.log shows no progress for 5 to 20 minutes, no crash dump appears, and the Unity and UnityHelper (or UnityHelper64.exe) processes sit at low CPU. Closing and reopening the Editor reproduces the same hang.

Who is affected now: Small to mid-size teams on Unity 6.6 LTS in 2026 who upgraded an existing 2026.1 project to 2026.2 without changing Asset Import Worker settings, run on machines with 6 to 16 logical cores, and have an Accelerator Cache Server configured (locally or remotely) but cold to this project.

Fastest safe fix: Kill the UnityHelper processes, drop Asset Import Worker Count to floor(cores / 2), delete the project's Library/ folder, reopen, and verify the Cache Server connection is green before letting the import run.

Direct answer

This hang is almost always Asset Import Worker contention against a cold Accelerator Cache Server combined with Library/Bee corruption carried over from the 2026.1 install. Unity 6.6 LTS / 2026.2 turned the import worker and cache server path on by default for small projects, and the first import after upgrade is the moment that change collides with stale 2026.1 build cache. Killing helper processes, dropping the worker count, and clearing Library/ resolves it in roughly 40 minutes for a typical mid-size project. Only chase deeper IL2CPP or Burst causes after the helper-process plus cache-server tuple is healthy.

Why this issue spikes in 2026

Three practical shifts make this hang common on Unity 6.6 LTS lanes this year:

2026.2 enabled Asset Import Worker by default for small projects. Prior 2026.1 installs typically ran with the worker pool effectively off for sub-1000-asset projects; the upgrade flips this on without warning, and the default Worker Count is set to your machine's logical core count, which oversubscribes most laptops.
Accelerator Cache Server defaults also changed. The 2026.2 release set the Asset Pipeline Mode path to query the configured Cache Server on first import. When the cache server is cold to this project (no entries yet), every worker stalls on the same upstream pull, producing the characteristic low-CPU hang.
Library/Bee carries forward from 2026.1. The Bee build artifacts contain machine-readable hashes tied to the previous Editor version. On first 2026.2 open, the Bee pipeline tries to validate them, finds mismatches, and silently retries; combined with worker contention, the retry loop looks identical to a hang.

If your project was working in 2026.1 last week and the upgrade is your most recent change, treat this exact combination as the prime suspect.

Symptoms and phrases to match

Editor stuck at Hold on... Importing Assets (0/X) or Compiling C# Scripts with no counter advance.
Editor.log last lines: Refresh: detecting if any assets need to be imported or removed or Worker process X disconnected.
UnityHelper processes (Windows: UnityHelper.exe, UnityHelper64.exe; macOS: UnityHelper) listed in Task Manager / Activity Monitor at low CPU but elevated memory (each worker can hold 600 MB to 2 GB).
Library/Bee/ folder modification timestamp older than the Editor binary.
Cache Server preference panel shows Connection: Connecting... indefinitely.

Treat all of these as one class: first-import worker contention plus stale build cache.

Root causes (check in this order)

Asset Import Worker Count too high. Default in 2026.2 is your full logical core count. On a 12-core laptop, 12 workers + the main Editor process saturate I/O and stall on the cache server.
Cold Accelerator Cache Server. The server is reachable but has no entries for this project; every worker requests the same uncached artifacts, queuing on the server's worker pool.
Corrupt Library/Bee. Carried over from the 2026.1 install with mismatched hashes that the 2026.2 Bee pipeline cannot reconcile silently.
.meta orphan files left behind by the migration. Renamed or removed files from 2026.1 leave .meta files that the 2026.2 worker pool re-evaluates on every retry.
Library/Bee/PlayerScriptAssemblies carrying stale assembly references after a scripting backend change (IL2CPP to Mono or vice versa during the upgrade).
Wrong Asset Pipeline mode (v1 vs v2) selected after the upgrade migration. 2026.2 forces v2 but the project file can retain v1 if the migration prompt was dismissed.

Fastest safe fix path (under 40 minutes)

Step 1 - Kill the helper processes

Close the Unity Editor if it is still responsive. Then in your operating system process manager:

Windows: Open Task Manager (Ctrl+Shift+Esc), end any UnityHelper.exe, UnityHelper64.exe, and Unity.exe processes still listed under your project.
macOS: Open Activity Monitor, force-quit any UnityHelper and Unity processes for your project.
Linux: pkill -9 UnityHelper; pkill -9 Unity.

Helper processes that survive the parent Editor shutdown hold file locks on Library/ and will block the next steps.

Step 2 - Drop the Asset Import Worker Count

Open the project once (it will start hanging again — that is fine). Within the first 30 seconds before the hang fully sets in, navigate to:

Edit > Preferences > Asset Pipeline > Asset Import Worker Count

Set the value to floor(cores / 2):

8-core machine → set to 4
12-core machine → set to 6
16-core machine → set to 8
24-core workstation → set to 12 (do not exceed 12; diminishing returns after that point)

If the Editor will not let you change preferences before the hang locks the UI, set the value directly in Preferences.asset under the Unity install user preferences directory (Windows: %APPDATA%\Unity\Editor\Preferences.asset; macOS: ~/Library/Application Support/Unity/Editor/Preferences.asset).

Close the Editor again and kill any helper processes that respawned.

Step 3 - Clear `Library/` and reopen

In the project folder:

Delete the entire Library/ folder (do not delete Assets/, Packages/, or ProjectSettings/).
Optionally also delete Temp/ and Logs/.
Reopen the project.

This is destructive only to the build cache; Unity rebuilds it on next open. Plan for 5 to 25 minutes of re-import depending on project size and whether the Cache Server warms.

Step 4 - Verify Cache Server connection

While the re-import runs (the Editor will respond to UI even during import after Library/ is cleared), go to:

Edit > Preferences > Cache Server (Project)

Confirm:

Cache Server Mode is set to Asset Pipeline v2 (not v1).
Connection indicator turns green (Connected) within 30 seconds.
If the indicator stays yellow or red, your cache server URL is stale or the server itself is down. Either fix the URL or set Cache Server Mode to Disabled temporarily so workers do not stall on the server.

Step 5 - Clean up `.meta` orphans

After the re-import completes, check for orphan .meta files in your Assets/ tree:

Windows PowerShell:

Get-ChildItem -Path "Assets" -Recurse -Filter "*.meta" |
  Where-Object { -not (Test-Path ($_.FullName -replace '\.meta$','')) } |
  Select-Object FullName

macOS / Linux:

find Assets -name "*.meta" -type f | while read meta; do
  target="${meta%.meta}"
  [ ! -e "$target" ] && echo "ORPHAN: $meta"
done

Delete each orphan listed (or commit a one-time cleanup commit if you use version control). Orphans force re-evaluation on every refresh.

Verification

You have fixed the hang when all of the following are true:

Editor.log shows Reloading assemblies... within 2 minutes of Editor re-open.
Progress bar at Hold on... Importing Assets advances visibly (counter increments within 30 seconds).
UnityHelper processes show active CPU (above 20% sustained), not idle.
Cache Server indicator is green in Preferences (if you kept the cache server enabled).
The next domain reload after a small script change completes in under 30 seconds on a project of your size.

If any of these are still failing after Step 5, drop to the alternative branches below.

Alternative fixes for edge cases

Branch 1 - Cache Server is the bottleneck, not workers

If the Cache Server connection is green but workers still stall (visible as low CPU on every worker but the server's bandwidth fully consumed), the server is the bottleneck:

Temporarily disable the cache server (Edit > Preferences > Cache Server > Mode = Disabled) for the first import.
After the first import completes locally, re-enable the cache server. Subsequent team members will pull from the warm cache.

This is the right move for the first developer who upgrades a project; later teammates inherit the warm cache and do not hit the cold-pull race.

Branch 2 - Library/Bee corruption survives Library/ deletion

In rare cases, Library/Bee/ corruption persists because it was created by a non-Unity tool (custom build script or asset processor) outside Unity's reach:

rm -rf Library/Bee Library/PackageCache Library/ScriptAssemblies Library/StateCache

Then reopen. This is more surgical than blowing away all of Library/ and avoids re-importing assets that did not need to.

Branch 3 - Scripting backend changed during upgrade

If the upgrade also flipped scripting backend (Mono ↔ IL2CPP):

File > Build Settings > Player Settings > Other Settings > Scripting Backend — explicitly set the backend back to the one your project was using.
Delete Library/PlayerScriptAssemblies/ and Library/Bee/PlayerScriptAssemblies/.
Reopen.

Stale player script assemblies from a different backend produce identical-looking import hangs because the worker pool tries to validate them against the new backend's rules.

Branch 4 - Worker process disconnects in Editor.log

If Editor.log shows repeated Worker process X disconnected entries, the worker pool is out of memory:

Drop Asset Import Worker Count further (to floor(cores / 4)).
Close Chrome, Slack, and other memory-heavy applications during the import.
Increase OS pagefile / swap size if your machine has less than 16 GB RAM.

Worker crashes appear identical to hangs because the main Editor process waits for the failed worker to complete before timing out.

Prevention

Pin the Asset Import Worker Count in ProjectSettings/EditorSettings.asset (commit the value to your repo) so every team member gets the same tuned value on first open. The key is m_AssetImportWorkerCount under m_AssetImportSettings.
Document the Cache Server URL in your repo README with explicit setup steps for fresh clones.
Stage upgrades on a branch with a single developer running the first import; their warm cache propagates via the Cache Server to the rest of the team.
Add Library/ to .gitignore (default for newer Unity templates but worth confirming explicitly).
Schedule major version upgrades for Friday afternoons or weekends so the cold-cache import does not block daily work.
Run Editor.log tail in a separate terminal during the first post-upgrade import so progress is visible even when the Editor UI looks frozen.

Frequently asked questions

Q: How long should the first import after a 2026.1 → 2026.2 upgrade actually take?

A: For a small project (under 5000 assets) on a warm cache server: 3 to 8 minutes. For a mid-size project (5000 to 50000 assets) with a warm cache: 10 to 25 minutes. For the same project with a cold cache: expect 30 to 90 minutes for the first developer and roughly half that for subsequent team members once the cache warms. If you hit 2 hours without progress and Editor.log is silent, treat it as a hang.

Q: Is it safe to delete Library/ while the Editor is closed but a build is in progress on CI?

A: Only if you stop the CI build first. Concurrent writes to Library/ from a CI runner and a developer's machine corrupt the build cache in ways that surface as exactly this hang on the next open. Pause CI, clean Library/, then resume.

Q: My Cache Server is on a remote VPN. Does that make the cold-pull race worse?

A: Yes. Remote cache servers over high-latency VPN typically produce 2-5x slower cold-pull behaviour than local cache servers. For the first import after a major upgrade, set Cache Server Mode to Disabled, let the local build complete, then re-enable. Subsequent imports use the warm local artifacts.

Q: Will pinning m_AssetImportWorkerCount affect Cloud Build?

A: Unity Cloud Build respects the project's pinned value on 2026.2 and newer. If you are mixing Cloud Build with local builds on heterogeneous hardware, pin the value to a conservative number (4 to 6) and let local power users override in their personal Preferences. See the related Unity Cloud Build 2026.2 scripting define-symbol parity help article for the broader Cloud Build migration story.