Fix: VSCode ESLint Extension Not Working – No Errors Shown or Not Running

ESLint Extension Silent in VSCode

I once spent half an hour re-reading a perfectly good ESLint config because the editor showed no squiggles, when the answer had been sitting in the ESLint output panel the whole time: one missing plugin, named in plain English on line one. That is the shape of almost every case of this problem. The extension depends on a chain, local ESLint install, matching config format, the right Node binary, workspace trust, and when any link breaks, the symptom is identical silence. I learned to open the output panel first and let the extension tell me which link broke, and in my experience that one habit turns a thirty-minute guessing game into a two-minute read.

You open a JavaScript or TypeScript file in VSCode and ESLint does nothing. No red squiggly lines, no warnings in the Problems panel, no output in the ESLint channel. You know the code has issues, running npx eslint . in the terminal catches them, but the editor extension stays silent.

Or you see one of these in the bottom-right corner of VSCode:

ESLint is disabled since its execution has not been approved or denied yet.

ESLint: Failed to load config "..." to extend from.

ESLint server is not running.

ESLint could not find the config file.

Sometimes the extension appears to load but only highlights errors in .js files, ignoring .ts, .tsx, .vue, or .svelte files entirely. Other times it worked yesterday and broke today after an update.

This is one of the most frustrating developer experience issues because there is no single cause. The ESLint extension depends on a chain of things all working together: a local ESLint installation, a valid configuration file, the correct VSCode settings, workspace trust, the right Node.js version, and the proper parser for your file types. A break anywhere in that chain produces the same symptom, silence.

The Chain That Has to Hold

The VSCode ESLint extension (published by Microsoft, dbaeumer.vscode-eslint) does not bundle its own copy of ESLint. It looks for a locally installed ESLint in your project’s node_modules, loads your configuration file, and runs ESLint as a language server in the background. The results are then displayed as editor diagnostics.

When the extension fails, it is almost always one of these:

• ESLint is not installed locally in the project. The extension does not use a global ESLint installation by default.
• The configuration file format does not match the ESLint version. ESLint 9 uses eslint.config.js (flat config) and ignores .eslintrc.* files. ESLint 8 and below use .eslintrc.* and do not understand eslint.config.js.
• Language probing failed silently for your file type. The extension probes a broad default set of languages (including TypeScript, Vue, and Markdown), but when validating a probed language throws an error, the extension deliberately stays silent and nothing appears. Languages outside the probe list (such as Svelte) are never checked until you add them to eslint.validate.
• Workspace trust is blocking execution. VSCode’s workspace trust feature can prevent extensions from running in untrusted folders.
• The Node.js version used by the extension does not match what ESLint or its plugins require.
• The TypeScript parser is not installed or not configured, so ESLint silently fails on .ts and .tsx files.
• Files are excluded by .eslintignore or the ignores property in flat config, so ESLint intentionally skips them.
• The extension crashed and needs a restart.

The fix depends on which link in the chain is broken. Work through the following sections in order, each one addresses a specific cause and tells you how to confirm whether it applies to your situation.

Diagnostic Timeline

Here is how the debugging session actually plays out in a real codebase. The trick is to stop guessing and read what the extension is telling you.

Minute 0, first reaction: reload window. Everyone’s first move is Developer: Reload Window or ESLint: Restart ESLint Server. If the extension was wedged on a stale config, this fixes it. If the silence comes back the moment you reopen the file, the cause is structural. Reloading more times will not help. Stop reloading.

Minute 1, second wrong suspicion: the config file. You open .eslintrc.json or eslint.config.js and start re-reading rules. This is wasted effort until you have confirmed ESLint is even being loaded. Before touching config, run the CLI from the integrated terminal:

npx eslint --print-config src/index.ts | head -50

If this prints a config with hundreds of rules, ESLint is healthy from the CLI side and the extension is the broken half. If this returns “No ESLint configuration found” or an empty config, the CLI is also broken, fix the CLI first, the extension cannot do better than the CLI.

Minute 2, third wrong suspicion: wrong Node version. Volta, nvm, fnm, and asdf all swap your Node binary based on cwd. VS Code launched from Spotlight or the Start Menu does not inherit your shell’s PATH, so the extension may run against a system Node 16 even though your terminal uses Node 20. Check the ESLint output panel for a line like Using Node.js: v16.20.0. If that mismatches your .nvmrc or .node-version, set eslint.runtime explicitly:

{ "eslint.runtime": "/Users/you/.nvm/versions/node/v20.11.0/bin/node" }

On macOS, launching VS Code via code . from a terminal (rather than the Dock) usually solves it without further config.

Minute 3, fourth wrong suspicion: workspace trust. Look at the bottom-right of VS Code. If the status bar shows “Restricted Mode”, trust the workspace and the warning goes away. If it does not, trust is not the cause. Move on.

Minute 4, actual root cause: open the ESLint Output panel. This is the single most useful step and most developers skip it for 30 minutes before remembering it exists. View > Output, change the dropdown in the top-right to ESLint, and read. Nine out of ten times the cause is sitting in plain English on the very first line:

• ESLint couldn't find the plugin "@typescript-eslint", the plugin is missing from node_modules for the workspace the extension picked up.
• Failed to load config "airbnb", eslint-config-airbnb is not installed in this workspace.
• The ESLint server crashed 5 times in the last 3 minutes. The server will not be restarted., your config file has a runtime error. Run node eslint.config.js to see the actual stack trace. (Execute the file directly rather than require()-ing it, require throws ERR_REQUIRE_ESM on ESM configs and sends you chasing the wrong error.)
• No output at all, the extension never activated. Usually a workspace trust issue or a corrupted extension install.

Minute 5, the monorepo gotcha. If you opened a monorepo root in VS Code but the file lives in packages/web/, ESLint runs from the wrong working directory. The root has no node_modules/eslint, so the extension fails silently. Add to workspace settings:

{
  "eslint.workingDirectories": [
    { "mode": "auto" }
  ]
}

{ "mode": "auto" } tells the extension to detect the nearest package.json containing ESLint and use that directory. Without this, monorepo ESLint is unreliable regardless of how correct your config is.

Minute 6, actual root cause discovery. By this point you have one of: (1) a missing plugin (install it), (2) a wrong Node binary (set eslint.runtime), (3) a working-directory mismatch (set eslint.workingDirectories), or (4) the wrong config format for your ESLint version (Fix 2 below). The output panel told you which.

Fix 1: Install ESLint Locally in Your Project

The most common cause is that ESLint is simply not installed in the project directory. The extension needs a local installation to function.

Check if ESLint is installed:

npx eslint --version

If this fails or returns “command not found,” install ESLint:

npm install --save-dev eslint

After installing, reload the VSCode window. Open the command palette (Ctrl+Shift+P / Cmd+Shift+P) and run “Developer: Reload Window”.

If you have ESLint installed globally but not locally, the extension will not find it unless you explicitly tell it to. However, the recommended approach is always a local installation. Global installations cause version mismatches across projects and make your setup non-reproducible. If a colleague clones your repository and runs npm install, they will get the correct ESLint version automatically, but only if it is in devDependencies.

This also applies to ESLint plugins and parsers. If your config references @typescript-eslint/parser or eslint-plugin-react, those must also be installed locally. A missing parser will not always produce a visible error in the editor, the extension may simply stop linting that file type. If you are seeing ESLint parsing errors in the terminal but nothing in the editor, a missing local parser is the likely cause.

Fix 2: Match Your Config File to Your ESLint Version (Flat Config vs Legacy)

ESLint 9 made the flat config format (eslint.config.js) the default (it had shipped experimentally in late v8 releases). ESLint 8 and below use the legacy format (.eslintrc.js, .eslintrc.json, .eslintrc.yml, or .eslintrc), and ESLint 10 (February 2026) removed the legacy system entirely. Using the wrong format for your ESLint version is one of the most common reasons the extension stops working after an upgrade.

Check your ESLint version:

npx eslint --version

If you are on ESLint 9+:

ESLint 9 only reads eslint.config.js (or eslint.config.mjs / eslint.config.cjs). If your project still has a .eslintrc.json or .eslintrc.js, ESLint 9 silently ignores it. The extension will appear to load but no rules are applied because there is no configuration from ESLint’s perspective.

Migrate to flat config. On ESLint 9 specifically, you can buy time by setting the environment variable ESLINT_USE_FLAT_CONFIG=false, which forces it to read the legacy files, but treat that as a stopgap: ESLint 10 no longer honors that variable, drops the eslintrc-specific CLI flags, and ignores .eslintrc.* and .eslintignore completely. On v10 the flat config file is the only option.

If you are on ESLint 8 or below:

ESLint 8 does not read eslint.config.js unless you opt in. If someone added a flat config file to your project while the installed ESLint is still v8, ESLint will not find any configuration and will either use defaults (which lint very little) or throw an error.

To confirm which config file ESLint is actually loading, run:

npx eslint --print-config src/index.js

If this outputs a mostly empty configuration or an error about no config found, your config file is not being read.

Fix 3: Set eslint.useFlatConfig in VSCode Settings

The VSCode ESLint extension has a setting that controls whether it tells ESLint to use the flat config format. If this setting is wrong for your project, the extension will fail to load your configuration.

Open your VSCode settings (Ctrl+, / Cmd+,) and search for eslint.useFlatConfig.

• If you are using eslint.config.js with ESLint 9+, set it to true or leave it unset (it defaults to auto-detection in recent versions of the extension).
• If you are using .eslintrc.* with ESLint 8, set it to false or leave it unset.

In your settings.json, this looks like:

{
  "eslint.useFlatConfig": true
}

Or in a workspace .vscode/settings.json:

{
  "eslint.useFlatConfig": true
}

If you have the extension version 3.x or later, it should auto-detect the config format. But older versions of the extension (2.x) do not auto-detect and may need this setting explicitly. Check your extension version in the Extensions panel and update if it is outdated.

The upgrade path is where this bites hardest: teams bump ESLint from v8 to v9 in a routine dependency update without realizing the config format changed out from under them. If your linting silently stopped working right after an upgrade, look for a leftover .eslintrc.* file before anything else, ESLint 9 ignores it completely and wants eslint.config.js instead, and “config ignored” looks exactly like “extension broken.”

Fix 4: Understand eslint.probe vs eslint.validate (Svelte and Silent Failures)

A widespread piece of outdated advice says the extension “only validates JavaScript by default” and that you must list every language in eslint.validate. That has not been true for years. The modern extension probes a broad default set of languages, eslint.probe defaults to javascript, javascriptreact, typescript, typescriptreact, html, vue, markdown, json, jsonc, and a few others, so TypeScript files are checked out of the box.

The catch is how probing fails. If validating a probed language throws (missing parser, config that does not cover the file type), the extension stays silent by design. That silence is exactly the symptom you are debugging.

eslint.validate is the enforcement counterpart: languages listed there are validated unconditionally, and failures surface as visible errors instead of silence. Use it in two situations:

1. Your language is not in the probe list. Svelte is the common example:

{
  "eslint.validate": [
    "javascript",
    "javascriptreact",
    "typescript",
    "typescriptreact",
    "svelte"
  ]
}

2. As a diagnostic for silent probe failures. Temporarily add the silent language (say, "typescript") to eslint.validate and restart the ESLint server. If a visible error appears where there was silence, read it, that error is your real cause, usually a missing parser (Fix 8) or a config whose files patterns do not cover the extension.

If you have already configured ESLint with @typescript-eslint/parser and the correct rules but still see nothing in the editor, this force-and-surface trick tells you why in seconds. Related: if TypeScript itself is throwing module errors, see Fix: Cannot find module or its corresponding type declarations.

Fix 5: Check Workspace Trust Settings

VSCode’s workspace trust feature can prevent the ESLint extension from executing. When you open a folder that VSCode considers “untrusted,” extensions that execute code (including ESLint) are disabled.

Look at the bottom of the VSCode window. If you see a banner saying the workspace is not trusted, click “Trust” or “Manage Workspace Trust” in the banner.

You can also manage trust through the command palette: run “Workspaces: Manage Workspace Trust”.

If you always want to trust a particular folder (for example, your development directory), you can add it to the trusted folders list in VSCode settings. Be cautious about trusting folders you downloaded from unknown sources, workspace trust exists to prevent malicious code in ESLint configs and plugins from running automatically when you open a project.

If the extension was blocked by workspace trust, you will see a message in the ESLint output channel. Which brings us to the next fix.

Fix 6: Check the ESLint Output Panel for Errors

The ESLint extension logs detailed information to its output channel. This is the single most useful diagnostic tool when the extension is not working.

1. Open the Output panel: View > Output (or Ctrl+Shift+U / Cmd+Shift+U).
2. In the dropdown at the top-right of the Output panel, select ESLint.
3. Read the messages.

Common messages and what they mean:

• “Cannot find module ‘eslint’”, ESLint is not installed locally. Go back to Fix 1.
• “ESLint configuration is invalid”, Your config file has a syntax error or references a plugin/config that is not installed.
• “No ESLint configuration found”, ESLint cannot find a config file. Check that your config file is in the project root and matches the expected format for your ESLint version.
• “Failed to load parser ‘@typescript-eslint/parser’”, The TypeScript parser package is not installed. Run npm install --save-dev @typescript-eslint/parser.
• “Unexpected token” during config loading, Your eslint.config.js might use export default syntax but your project does not have "type": "module" in package.json. Rename the file to eslint.config.mjs or add "type": "module".

If the Output panel for ESLint is completely empty, the extension is not running at all. This usually means workspace trust is blocking it or the extension itself failed to activate. Try reloading the window.

Fix 7: Fix Node.js Version Mismatches

The ESLint extension uses Node.js to run ESLint. If the Node.js version it finds is too old for your ESLint installation or plugins, the extension will fail silently or with cryptic errors.

Modern versions of @typescript-eslint/parser (v7+) require Node.js 18 or later, and ESLint 9 requires Node.js 18.18.0 or later. ESLint 10 raises the floor again: Node 20.19.0+ (or 22.13+/24), with Node 18 support dropped entirely. If the Node binary the extension picked up is older than what your ESLint version demands, the extension will not work, and an ESLint 10 upgrade on a machine still running Node 18 produces exactly the silent failure this article is about.

Check which Node.js the extension is using by looking at the ESLint output channel (Fix 6). It often logs the Node.js path and version at startup.

If you use a version manager like nvm, fnm, or Volta, VSCode may not pick up the correct Node.js version because it does not always inherit your shell’s environment. You can explicitly tell the extension which Node.js to use:

{
  "eslint.runtime": "/home/user/.nvm/versions/node/v20.11.0/bin/node"
}

Or set the eslint.nodePath setting to point to the node_modules directory that contains ESLint:

{
  "eslint.nodePath": "./node_modules"
}

If you are unsure which Node.js version is available, run node --version in the VSCode integrated terminal. If that shows v20 but the ESLint extension is failing, the extension might be using a different Node.js binary. Check if the terminal and the extension are using the same one.

When your project depends on a specific Node.js version and things are not resolving correctly, you may also run into Cannot find module errors in Node.js itself, the root cause is often the same: a version mismatch between what you expect and what is actually running.

Fix 8: Install and Configure the TypeScript Parser

If ESLint works for .js files but not .ts or .tsx files, the TypeScript parser is either missing or misconfigured. The default ESLint parser (Espree) does not understand TypeScript syntax. When it encounters a type annotation, it fails, and the extension may swallow that failure instead of showing it.

Install the parser and plugin:

npm install --save-dev @typescript-eslint/parser @typescript-eslint/eslint-plugin

For flat config (eslint.config.js):

import tseslint from 'typescript-eslint';

export default [
  ...tseslint.configs.recommended,
  {
    files: ['**/*.ts', '**/*.tsx'],
    languageOptions: {
      parser: tseslint.parser,
      parserOptions: {
        ecmaVersion: 'latest',
        sourceType: 'module',
      },
    },
  },
];

For legacy config (.eslintrc.json):

{
  "parser": "@typescript-eslint/parser",
  "plugins": ["@typescript-eslint"],
  "extends": [
    "eslint:recommended",
    "plugin:@typescript-eslint/recommended"
  ],
  "parserOptions": {
    "ecmaVersion": "latest",
    "sourceType": "module"
  }
}

After adding the parser, restart the ESLint server: open the command palette and run “ESLint: Restart ESLint Server”. Then check the Output panel for errors.

If you have the parser installed and configured but TypeScript files still are not linted, go back to Fix 4 and use the eslint.validate force-and-surface trick, adding "typescript" there turns the probe’s silent failure into a readable error.

Fix 9: Check .eslintignore and ignores for Blocked Files

If ESLint works on some files but not others, the ignored files might be excluded by your ignore configuration.

Legacy config: Check .eslintignore in the project root. Also check ignorePatterns in your .eslintrc.* file:

{
  "ignorePatterns": ["dist/", "build/", "*.config.js"]
}

That last pattern (*.config.js) would cause ESLint to ignore any file ending in .config.js, including files you might want linted. Review your ignore patterns carefully.

Flat config: Check the ignores property in eslint.config.js:

export default [
  {
    ignores: ['dist/**', 'build/**', 'coverage/**'],
  },
  // ... rest of config
];

In flat config, an ignores array in a standalone object (without files, rules, or other keys) acts as a global ignore. But ignores inside a config object that also has rules or plugins only applies to that specific config block. This subtlety causes files to be unexpectedly ignored.

To check whether a specific file is being ignored, run:

npx eslint --debug src/components/Button.tsx 2>&1 | grep -i "ignore"

If you see a message about the file being ignored, your ignore configuration is the problem.

Also note that ESLint ignores node_modules by default. If you are working on a file inside a symlinked directory or a monorepo where the resolved path passes through node_modules, ESLint will skip it.

If you take one habit from this article, make it this: before touching a single config file, open the ESLint output panel (View > Output, then pick “ESLint” from the dropdown). Nine times out of ten the exact error is already printed there, and reading it beats guessing across ten possible causes every single time. I keep relearning this lesson and it keeps being true.

Fix 10: Restart the ESLint Server and Reload VSCode

The ESLint extension caches configuration and sometimes gets stuck in a bad state. After making any changes to your ESLint config, installed packages, or VSCode settings, you should restart the ESLint server.

Steps in order of aggressiveness:

1. Restart ESLint Server: Open the command palette (Ctrl+Shift+P / Cmd+Shift+P) and run “ESLint: Restart ESLint Server”. This reloads the configuration without restarting the entire editor.

2. Reload Window: If restarting the server does not help, run “Developer: Reload Window” from the command palette. This restarts all extensions.

3. Clear ESLint cache: Delete any cached ESLint data:

rm -f .eslintcache
rm -rf node_modules/.cache/eslint

4. Reinstall the extension: If nothing else works, uninstall the ESLint extension from the Extensions panel, reload VSCode, and reinstall it. This resets any corrupted extension state.

After restarting, always check the ESLint output channel (Fix 6) to see whether the extension loaded successfully this time.

When the Editor Stays Silent

Verify ESLint Runs in the Terminal

Before debugging the extension further, confirm that ESLint itself works:

npx eslint src/index.ts

If this command also fails, the problem is not the VSCode extension, it is your ESLint configuration. Fix the CLI first. Common issues include missing dependencies, invalid config syntax, and version mismatches between ESLint and its plugins. If you are seeing dependency resolution errors, check Fix: npm ERR! ERESOLVE unable to resolve dependency tree.

Check for Conflicting Extensions

Other VSCode extensions can interfere with ESLint. Known conflicts include:

• Prettier - Code formatter: If both Prettier and ESLint try to format/lint the same files, they can conflict. Use eslint-config-prettier to disable ESLint rules that conflict with Prettier, or use eslint-plugin-prettier to run Prettier as an ESLint rule.
• Other linting extensions: Extensions like TSLint (deprecated), JSHint, or StandardJS may override or conflict with ESLint diagnostics. Disable them if you are using ESLint.

Try disabling all other extensions temporarily to see if ESLint starts working. If it does, re-enable extensions one by one to find the conflict.

Multi-Root Workspaces

If you use a VSCode multi-root workspace (multiple folders in one window), the ESLint extension resolves configuration per folder. Each folder needs its own node_modules with ESLint installed and its own config file. The extension does not share ESLint installations across workspace folders.

Check the ESLint output channel for messages about which workspace folder it is loading. If one folder works and another does not, the broken folder is likely missing a local ESLint installation or config file.

Environment Variables Not Loaded

If your ESLint config depends on environment variables (for example, conditional rules based on NODE_ENV), those variables may not be set when VSCode launches. The integrated terminal inherits your shell environment, but extensions do not always get the same environment. Hardcode the values in your ESLint config, use dotenv at the top of eslint.config.js, or move the conditional logic into a JavaScript export so the runtime value is read at evaluation time rather than load time.

The Extension Shows “ESLint is disabled”

The “execution has not been approved or denied yet” message comes from older versions of the extension (2.1.x and earlier), which shipped their own approval dialog. On those versions, run “ESLint: Manage Library Execution” from the command palette to reopen the dialog and re-approve, this is the fix if you once clicked “deny” and the extension went permanently quiet.

Modern versions removed that custom dialog entirely in favor of VS Code’s workspace trust model. If a current version shows ESLint as blocked in the status bar, click the status bar item and trust the workspace (see Fix 5); there is no separate ESLint approval anymore.

Also confirm ESLint has not been switched off in settings:

{
  "eslint.enable": true
}

Check eslint.options in Settings

If your VSCode settings include eslint.options, those options are passed directly to the ESLint API. An incorrect option can cause the extension to fail:

{
  "eslint.options": {
    "overrideConfigFile": ".eslintrc.custom.json"
  }
}

If overrideConfigFile points to a file that does not exist, the extension fails silently. Remove or correct any eslint.options you have set and restart the ESLint server.

Yarn PnP Projects Need eslint.nodePath Configured

Yarn 2+ with Plug’n’Play does not produce a normal node_modules directory. The ESLint extension looks for ESLint in node_modules by default and gives up when the directory is empty. Tell the extension to use the PnP loader:

{
  "eslint.nodePath": ".yarn/sdks",
  "eslint.runtime": "node"
}

Run yarn dlx @yarnpkg/sdks vscode once to generate the SDK files VS Code needs. Without this step ESLint silently fails on every PnP project.

Devcontainers and Remote SSH Hide the Real ESLint Install

When using Dev Containers or VS Code Remote-SSH, the ESLint extension runs inside the remote environment, not your local machine. The node_modules and ESLint binary it uses are the remote ones. If linting works locally but not over Remote-SSH, you almost always need to npm install inside the remote container, your local node_modules is not visible. Check the ESLint output panel; it shows the remote Node path it is using.

Files Opened Outside the Workspace Folder

If you open an individual file (code path/to/single.ts) instead of a folder, VS Code has no workspace and the ESLint extension has nowhere to look for node_modules or a config file. You will see no errors and no output. Always open the project folder (code path/to/project) so the extension can locate the ESLint installation and config relative to a workspace root.

Last Resort: Debug Logging

Enable verbose logging to get the full picture of what the extension is doing:

{
  "eslint.trace.server": "verbose"
}

Restart the ESLint server, open the ESLint output channel, and reproduce the issue. The verbose log will show every request and response between VSCode and the ESLint language server, including the exact error that caused it to stop linting.

Related: Fix: ESLint Parsing error: Unexpected token | Fix: Cannot find module in Node.js | Fix: npm ERR! ERESOLVE unable to resolve dependency tree | Fix: Cannot find module or its corresponding type declarations