Fix VS Code Live Server opening folders instead of HTML in Windows

by

Summary

A developer reported a failure in the integrated launch sequence of VS Code on Windows. Instead of triggering the system’s default web browser to render an HTML file, the IDE was triggering the Windows Shell to open the file’s parent directory (File Explorer). Despite installing the Live Server extension and adjusting internal settings, the environment continued to execute a file-system open command rather than a URL-protocol request, indicating a disconnect between the IDE’s shell execution and the OS’s file association registry.

Root Cause

The root cause is a corrupted or missing Default App Association in the Windows Registry for the .html extension.

  • When VS Code or Live Server calls the OS to “open” a file, it sends a request to the Windows Shell.
  • If the .html association is pointed to a generic “folder” handler or if the registry key for the browser is corrupted, Windows defaults to the safest action: opening the directory containing the file.
  • Because the user can manually open the file in Chrome, the browser itself is functional, but the system-level mapping used by external API calls from VS Code is broken.

Why This Happens in Real Systems

In production environments and developer workstations, this occurs due to Registry Drift.

  • Software Updates: A browser update may fail to correctly rewrite the HKEY_CLASSES_ROOT registry keys.
  • Conflicting Handlers: Installing multiple IDEs or browsers can create competing claims for the same file extension.
  • Shell Execution Ambiguity: Some extensions use shellExecute (which relies on OS defaults), while others use a direct path to a binary. When the former is used, any OS-level misconfiguration results in unexpected behavior.

Real-World Impact

  • Developer Velocity: Critical loss of productivity due to broken feedback loops during the “Code $\rightarrow$ Refresh $\rightarrow$ Verify” cycle.
  • Onboarding Friction: New engineers spend hours debugging their local environment instead of writing code.
  • Tooling Distrust: Users mistakenly blame the IDE (VS Code) or extensions (Live Server) when the failure is actually occurring at the Operating System layer.

Example or Code

# Command to reset HTML file association to Chrome via PowerShell (Admin)
assoc .html=ChromeHTML
ftype ChromeHTML="C:\Program Files\Google\Chrome\Application\chrome.exe" "%1"

How Senior Engineers Fix It

Senior engineers isolate the failure by decoupling the application from the environment.

  1. Isolate the Trigger: They verify if the issue persists outside the IDE. If right-clicking the file in File Explorer also triggers a weird behavior, they know it is a Windows Registry issue, not a VS Code bug.
  2. Verify System Defaults: Instead of tweaking IDE settings, they navigate to Windows Settings $\rightarrow$ Apps $\rightarrow$ Default Apps and explicitly set the browser for .html and HTTP/HTTPS protocols.
  3. Registry Audit: If the UI fails, they use regedit or PowerShell to force the association of the .html extension to the specific browser binary.
  4. Path Validation: They ensure the path to the browser executable is correctly mapped in the system Environment Variables.

Why Juniors Miss It

  • Tunnel Vision: Junior developers often assume the problem exists within the last tool they touched (the IDE or the extension) rather than the underlying OS.
  • Surface-Level Troubleshooting: They attempt to fix the symptom (changing extension settings) rather than the root cause (the OS registry).
  • Lack of System Layer Awareness: They treat the IDE as a closed ecosystem, forgetting that VS Code is essentially a wrapper that makes calls to the OS Shell.

Leave a Comment