Cursor or VS Code C# IntelliSense Dead in Unity Project - OmniSharp and SDK Fix

In Unity, C# IntelliSense in Visual Studio Code, Cursor, or any VS Code fork depends on OmniSharp loading your generated .sln / .csproj and resolving Unity assemblies and your .NET SDK. When it fails, you see no completions, every type underlined in red, or stale errors that do not match Unity’s own Console. Unity can still compile while the editor looks broken, which wastes hours on fake “syntax” fixes.

This article is a fastest-safe-path workflow: get OmniSharp onto the right solution, onto a supported SDK-style toolchain, and clear the caches that commonly wedge it after upgrades or branch switches.

Direct answer

IntelliSense dies when OmniSharp points at the wrong folder, loads an out-of-date solution, cannot find a compatible .NET SDK, or hits a corrupted OmniSharp cache. Fix it by (1) regenerating the Unity .sln and project files, (2) opening the workspace at the Unity project root that contains Assets and Packages, (3) installing the C# extension (or C# Dev Kit policy your team chose) and restarting OmniSharp, (4) pinning OmniSharp to a real SDK with omnisharp.json or settings if needed, and (5) deleting OmniSharp’s log/cache locations when errors are stuck. Confirm success when Go to Definition works for UnityEngine types and red squiggles match Unity Console.

Who this affects

Teams using VS Code or Cursor as the External Script Editor in Unity
Machines after Unity Editor upgrades, package bumps, or long-lived branches where .csproj drifted
Repos where multiple Unity projects exist and the wrong folder was opened
Developers on .NET SDK 9+ defaults while the project or OmniSharp build still expects 6/8 behavior

Root causes

Cause	What you see
Wrong workspace root opened	OmniSharp loads no solution or a nested duplicate
Stale `.sln` / `.csproj`	Missing `Packages` references; broken package cache paths
SDK not found or wrong version	OmniSharp log: “SDK not found” or MSBuild failures
Locked / antivirus-blocked `.csproj`	Intermittent load failures after save
Two C# extensions fighting	Duplicate language servers; duplicate diagnostics
Corrupted OmniSharp cache	Old errors after Unity already compiles clean

Step-by-step fix

1. Regenerate Unity project files

In Unity: Edit → Preferences → External Tools (Unity 6: Preferences).
Confirm External Script Editor points to your VS Code / Cursor binary.
Click Regenerate project files (or enable embedded packages / local registry if your team relies on those toggles).
Close the editor, delete stray duplicate .sln files in subfolders if your repo accidentally committed them—keep the root solution Unity just regenerated.

Verify: Assembly-CSharp.csproj and *.sln timestamps match your last regeneration.

2. Open the correct folder in VS Code / Cursor

File → Open Folder on the directory that contains Assets, Packages, and the .sln.
Avoid opening a parent monorepo unless you use a multi-root workspace intentionally; if you do, pin OmniSharp to the Unity child folder per your multi-root scope rules.

Verify: Explorer shows Assets at the workspace root you expect.

3. Use one C# tooling stack

Pick one primary path per machine:

C# extension (OmniSharp-powered) — common for Unity.
C# Dev Kit — different server stack; teams should align so you do not run both with conflicting settings.

Disable or uninstall the unused option, then Reload Window.

4. Align the .NET SDK with OmniSharp

In a terminal: dotnet --list-sdks and note installed versions.
If Unity / your global.json expects a specific SDK band, install it from Microsoft’s .NET download page.
Optionally add omnisharp.json next to the .sln (or use VS Code settings.json) to pin SDK style, for example:

{
  "sdk": {
    "version": "8.0.100",
    "rollForward": "latestFeature"
  }
}

Adjust the version to match what your team standardizes on; the point is to stop OmniSharp from guessing a missing SDK.

Verify: OmniSharp Output panel no longer reports SDK resolution errors.

5. Restart OmniSharp cleanly

Command Palette → OmniSharp: Restart OmniSharp.
If still broken: quit VS Code / Cursor, delete OmniSharp’s cached metadata for this project (locations vary by OS; search for .omnisharp under your user profile cache and remove the folder tied to this workspace), then reopen.

Verify: Status bar shows OmniSharp running and project loaded.

6. If types still red but Unity compiles

Check Output → OmniSharp Log for Analyzer or metadata failures.
Confirm you did not open Library or Temp as source roots.
Run Unity Assets → Open C# Project once to refresh IDE binding.

Verification checklist

[ ] UnityEngine.MonoBehaviour Go to Definition opens metadata or source.
[ ] A known script shows completions for transform and gameObject.
[ ] New compile errors from Unity appear in the Problems panel within a reasonable delay after save.
[ ] OmniSharp log ends with project finished loading without MSBuild exceptions.

Alternative fixes

JetBrains Rider or Visual Studio on Windows: use Unity’s external editor switch for teams that need heavier refactoring tools; same project file regeneration still matters.
Apple Silicon / Linux: ensure the Mono / SDK paths in OmniSharp settings match what Unity documents for that platform.
CI-only breakage: compare global.json and dotnet versions on the agent versus local OmniSharp.

Prevention tips

After Unity upgrades, run regenerate project files and commit the resulting .csproj / .sln only if your workflow requires it—otherwise document “regenerate locally” in onboarding.
Pin SDK versions in repo docs or global.json for the game assembly.
Add a one-minute IntelliSense smoke test to engine-upgrade checklists.

FAQ

Why does Unity compile but VS Code shows thousands of errors?

OmniSharp is using a different project snapshot or failed to load packages. Regenerate projects and restart OmniSharp; most “red sea” issues are stale MSBuild state, not your C# syntax.

Is the C# Dev Kit required for Unity?

No. Many Unity teams use the C# extension with OmniSharp. What matters is one consistent stack per machine.

Does this replace fixing actual compile errors?

No. When Unity Console shows real errors, fix those first—OmniSharp will align after MSBuild can model the project.