Fixing VS Code IntelliSense Using the Wrong TypeScript Version and Disagreeing With the Real Build

The Problem

Running the project's actual build command — tsc, or whatever bundler wraps it — either reports a clean compile or surfaces a specific type error. Meanwhile, VS Code's own editor shows a completely different picture: red squiggles under code that the real build accepts without complaint, or a confidently clean editor over code that the actual build rejects. Restarting the editor sometimes "fixes" it temporarily, and the discrepancy can vary from one teammate's machine to another even against the exact same commit.

Why It Happens

VS Code ships its own bundled TypeScript version, entirely separate from the one installed in the project

The TypeScript language service that powers IntelliSense, inline error squiggles, and hover types inside VS Code is a specific version of TypeScript bundled with the editor itself. A project's own package.json typically declares its own TypeScript version in devDependencies, installed into node_modules, which is what the actual tsc build command on the command line uses. VS Code doesn't automatically know to prefer the project's version over its own bundled one — by default, it uses its own, and the two can simply be different TypeScript releases with different type-checking behavior.

Different TypeScript versions can genuinely disagree about whether specific code is valid

TypeScript's type checker changes behavior across versions — new releases add stricter checks, fix bugs in existing checks (which can newly flag code that previously passed), or add support for newer JavaScript and type-system features. A workspace running an older bundled version against code written assuming a newer release's behavior (or the reverse) isn't hitting an editor bug; it's two genuinely different type checkers evaluating the same source and reaching different, both internally consistent, conclusions.

The setting that controls this is per-workspace and easy to never have set at all

VS Code does support pointing its language service at the project's own installed TypeScript version, but it's a setting that has to be explicitly configured (or confirmed through a prompt) rather than inferred automatically on every project, and the setting is scoped per-workspace. A developer who configured it once on an old project, or who has simply never encountered the prompt, can have every new project silently default to the bundled version without any obvious indication that a choice is even being made.

The Fix

1. Check which TypeScript version VS Code is actually using for the current file

Open any .ts/.tsx file -> click the "TypeScript" version indicator in the status bar
(or: Command Palette -> "TypeScript: Select TypeScript Version")

The status bar indicator and the command palette action both report, and let you change, which TypeScript install the editor is currently using for that file — checking this directly replaces guessing with a concrete, visible answer to "which version is actually running."

2. Point the workspace at the project's own installed TypeScript version explicitly

// .vscode/settings.json
{
  "typescript.tsdk": "node_modules/typescript/lib",
  "typescript.enablePromptUseWorkspaceTsdk": true
}

Setting typescript.tsdk to the project's own installed copy makes VS Code's language service use the exact same TypeScript version as the actual build command, which is the single change that removes the entire category of version-disagreement bugs for everyone who opens the workspace with this setting committed.

3. Commit this setting to the repository's .vscode folder so every contributor gets it automatically

# Make sure .vscode/settings.json isn't excluded by .gitignore
git add .vscode/settings.json
git commit -m "Pin VS Code to project's own TypeScript version"

Committing the workspace setting rather than relying on each developer to configure it individually on their own machine turns a per-person configuration step into a one-time, repository-wide fix — every teammate who opens the project afterward gets the matching TypeScript version without having to know the setting exists.

4. If the mismatch persists after setting tsdk, restart the TypeScript server rather than the whole editor

Command Palette -> "TypeScript: Restart TS Server"

The TypeScript language service can cache state from before a tsdk change or a node_modules reinstall and keep reporting against the old version until it's explicitly restarted; this targeted restart applies the new setting immediately without the much heavier step of closing and reopening the entire editor window.

Why This Works

Each step narrows the gap between what the editor checks and what the real build checks. Identifying the currently active version turns a vague "the editor disagrees with the build" into a concrete comparison of two specific version numbers. Pointing typescript.tsdk at the project's own installed copy is the actual fix — it makes both checks run the identical compiler, so there's no longer a second, different type checker in the loop at all. Committing that setting extends the fix to every contributor rather than just whoever happened to configure it locally. And restarting the TypeScript server specifically clears stale state without the overhead of a full editor restart, addressing the case where the correct setting is already in place but hasn't taken effect yet.

Conclusion

An editor that disagrees with the real build about whether code type-checks almost always comes down to VS Code's bundled TypeScript language service running a different version than the one actually installed in the project and used by the real build command. Check which version the editor is currently running from the status bar, point typescript.tsdk explicitly at the project's own node_modules copy, commit that setting so the whole team inherits it, and restart the TypeScript server rather than the full editor when a change doesn't seem to take effect immediately.