Another Instance Of VSCode Is Running But Not Responding | Fix

That warning often loops after a crash or a stuck shutdown. A VS Code process may still be running, or a lock file may be left behind.

This walkthrough starts with safe checks, then moves into cleanup if you still see another instance of vscode is running but not responding.

Why This Message Shows Up In VS Code

VS Code uses a small set of “single instance” checks so you don’t end up with two copies fighting over the same profile. When it thinks a copy is already running, it blocks a second launch to protect your open windows, extensions, and user data.

The catch is that the check can stay “true” after a crash or a frozen shutdown. That’s when you get the warning while you can’t see an open window. The most common triggers fall into three buckets.

If you see the warning right after waking a laptop, a window may be off-screen. Switch apps with Alt+Tab or Cmd+Tab and move the VS Code window back onto your main display quickly.

Also check for a second copy launched by file watchers. If a helper app starts VS Code on boot, disable that startup entry and retry, so you can confirm the warning is not coming from auto-launch.

• Background Code process stayed alive — A window closed, but Code or its helper process is still running.
• Stale lock or socket file — A small file used for coordination didn’t get removed during shutdown.
• Startup hang — VS Code launches, then freezes on an extension, a Git scan, a large workspace, or a remote session.

Another Instance Of VSCode Is Running But Not Responding On Windows, Mac, And Linux

Start here first. Confirm whether VS Code is still running, then close it cleanly before you force anything.

Check For Hidden VS Code Processes

First, check the process list. VS Code may be running with no visible window, especially after sleep mode, a display change, or a crash.

• Open Task Manager — Press Ctrl + Shift + Esc, then look for Code.exe or “Visual Studio Code.”
• Open Activity Monitor — Search for “Code” or “Visual Studio Code,” then sort by name to spot leftovers.
• Use A Terminal List — Run ps aux | grep -i code on Linux or macOS to see lingering processes.

If you find VS Code in the list, try to end it normally first. Forced exits can leave the same lock behind that caused the loop.

Use A Gentle Close Before A Force Kill

• Close All VS Code windows — Use the app menu and close every window, not just the active one.
• Wait A Full Minute — Give it time to finish saving state, stopping watchers, and writing shutdown data.
• Retry The Launch — Open VS Code again and see if the warning is gone.

If you still get blocked, a force kill is fine. Just do it once, then move straight to lock cleanup so you don’t repeat the same crash-loop.

What You Notice	Likely Cause	First Move
Warning appears, no window visible	Background process still alive	End the VS Code process
Warning returns after crash	Lock file didn’t clear	Delete stale lock files
Window opens, then freezes	Extension or workspace hang	Start with extensions disabled

End The Stuck VS Code Process The Clean Way

If VS Code is hung, end the main process. Helper processes usually exit with it.

Windows Steps

• Find Code.exe — In Task Manager, use the “Details” tab if you have many items running.
• End The Main Process — Select Code.exe and choose End task.
• Try A Terminal Kill — Run taskkill /F /IM Code.exe if Task Manager won’t cooperate.

macOS Steps

• Force Quit VS Code — Press Cmd + Option + Esc, select VS Code, then Force Quit.
• End In Activity Monitor — Select the VS Code process and choose Quit, then Force Quit only if Quit fails.
• Use Terminal As A Last Step — Run pkill -f "Visual Studio Code" if it refuses to close.

Linux Steps

• Close From Your Desktop — Quit the app from your launcher or window manager first.
• Kill The Process — Run pkill -f code or find the PID with ps and use kill.
• Retry Launch From Terminal — Start with code . so you can see any output errors.

After the process is gone, try opening VS Code once. If it launches cleanly, you’re done. If the warning persists, it’s time to clear stale coordination files in the user data folder.

Clear Lock Files And Workspace State Without Nuking Your Profile

Lock files are safe to remove only after VS Code is fully closed. If they stick around after a crash, the next launch can get blocked.

Find Your VS Code User Data Folder

Lock files live in your VS Code “user data” folder. The cleanest way to locate it on any system is to ask VS Code for the exact path.

• Check The Path With A Command — In a terminal, run code --status and read the userDataDir line.
• Open The Windows Folder — If you prefer browsing, paste %APPDATA%\\Code\\ into your file manager’s address bar.
• Confirm You’re In The Right Place — The folder usually contains User and CachedData subfolders.

If you use the Insiders build, the directory name often includes “Insiders.” If you launch with --user-data-dir, use that location instead.

Remove The Usual Stale Files

Inside the user data folder, look for files that start with “Singleton” or end in “.lock.” Not every install shows the same names, but the pattern is consistent.

• Delete SingletonLock — Remove it only after confirming VS Code is closed.
• Delete SingletonSocket — On some systems, it’s a socket file that can get stuck.
• Delete Any *.lock files — If you see lock files in the root of the Code folder, remove them.

Now reopen VS Code. If the warning is gone, you’re finished. If the warning returns, the app may be launching into a hang that prevents a clean shutdown, leaving new locks behind each time.

Reset Only The Window State When Startup Loops

If VS Code opens into a half-dead state, it can help to reset only the stored window layout and recently opened workspaces. This keeps your settings and extensions in place.

• Start With A Fresh Window — Run code --new-window from a terminal.
• Open Without Restoring — Hold Shift while launching in some desktop setups to skip restore.
• Try A Clean User Data Dir — Run code --user-data-dir /tmp/vscode-clean to confirm your profile is the trigger.

If a clean user data directory launches fine, your VS Code install is okay. The hang is inside your profile: an extension, a workspace setting, a cached state file, or a remote session.

Isolate Extensions, Git, And Remote Sessions That Freeze Startup

A lot of “other instance” reports are really “startup got stuck.” VS Code started, wrote a lock, then froze. When you try again, the lock is still there, so it blocks the next run.

Start With Extensions Disabled

• Launch With No Extensions — Run code --disable-extensions and wait for it to fully load.
• Re-enable In Batches — Turn extensions back on a few at a time to find the one that hangs.
• Clear Extension Host Cache — Disable the suspect extension, restart, then re-enable after an update.

If it loads fine with extensions off, you’ve got a clear direction. Update the problem extension, or remove it and install it again. If you can’t open the UI, remove it from the extensions folder after backing up your list.

Test A Heavy Workspace Without The Extras

Large repos, giant node_modules folders, and noisy file watchers can slow startup until it looks frozen. Try opening VS Code with a clean window, then open the folder after the app is already running.

• Open An Empty Window — Start VS Code with code --new-window.
• Open The Folder After Launch — Use File → Open Folder once the window is responsive.
• Trim Watch Targets — Add big generated folders to your exclude settings so watchers don’t churn.

If the hang happens only on one folder, you can often fix it by reducing watcher load, cleaning up a broken Git index, or removing a corrupted workspace file in the project’s .vscode folder.

Remote: WSL, SSH, And Containers

Remote setups add a server process on the target machine. If it’s stuck, the local app can hang during connect.

• Close Remote Windows — Quit the remote window first, then close the app.
• Restart The Remote Host — Reboot WSL, your SSH host, or the container to clear stale server processes.
• Remove Remote Server Folder — Delete the remote .vscode-server directory if it’s corrupted, then reconnect so it reinstalls.

After each change, launch VS Code once and let it sit for a minute. You want a clean open and a clean close. That’s what clears the loop for good.

Stop The Error From Coming Back

Once you’ve cleared the warning, a small habit shift can keep it from returning. The pattern is simple: reduce forced exits, keep your install tidy, and treat “hangs on start” as the root cause.

Close VS Code In A Way That Lets It Finish Writing

• Save Work First — Let file saves complete before you exit the window.
• Wait After Heavy Actions — Git operations, refactors, and large searches can keep background tasks busy.
• Quit Once, Not Repeatedly — Rapid open/close cycles raise the odds of stuck locks.

Keep Extensions And VS Code Updated

• Update VS Code — New builds often fix crash bugs that leave background processes running.
• Update Heavy Extensions — Language servers and linters can be the main freeze source.
• Remove Unused Add-ons — Fewer active extensions means fewer startup hooks.

When Reinstall Is Worth Doing

If you still see another instance of vscode is running but not responding after process kills, lock cleanup, and an extensions-off test, a reinstall can help. This is most useful when the app itself is corrupted, or when you’ve migrated across major OS updates and the install has odd leftovers.

• Sync Settings First — If you use Settings Sync, sign in and confirm it’s up to date.
• Remove The App Only — Uninstall VS Code, then install the latest build again.
• Keep Your Profile Until Needed — Only delete the user data folder if a clean profile test proved it’s the trigger.

When the warning is gone and VS Code opens and closes normally, you’re back in a safe state. If it returns next week, jump straight to the process check and the stale lock cleanup. That combo clears most repeats in minutes.