Running VS Code in LSF Environments

Note

Although this application note refers to Visual Studio Code (VS Code), the information applies equally to VS Code-based editors such as Cursor, VSCodium, Windsurf, and other compatible forks.

Background

VS Code uses a master process architecture. A master process acts as the root of the process tree, while each editor window runs as a child process.

When VS Code starts, it checks whether a compatible master process is already running:

  • If no compatible master process exists, VS Code creates one.

  • If one is already running, the new instance communicates with the existing master process, which launches the requested editor window using the appropriate working directory and environment.

The master process maintains exclusive access to the VS Code user data directory (by default ~/.config/Code), which stores shared state, settings, and extension data.

Multiple Master Processes

Normally, only a single master process should exist for a given user data directory.

A second master process is created when:

  • A different VS Code version is launched, or

  • A different user data directory is used.

If multiple master processes attempt to use the same user data directory, the second process is unable to acquire all of the required resources. VS Code continues to run without reporting a critical error, but extensions may experience subtle failures that appear as random or inconsistent behavior

../../../_images/running-vscode-in-lsf-1.png

Running VS Code in an LSF Environment

An additional limitation exists when VS Code is used in an LSF environment.

Although farm machines typically share the same home directory (for example, through NFS), LSF jobs execute on different hosts. A VS Code instance running on one machine cannot communicate with a master process running on another machine, even when both use the same VS Code version and user data directory.

As a result, each host starts its own master process, causing multiple masters to contend for the same user data directory. This deployment model is not supported by VS Code and may lead to unpredictable behavior.

../../../_images/running-vscode-in-lsf-2.png

Symptoms

One common symptom is that extension-contributed views appear empty even though no explicit error is reported.

For example, when using DVT, some views may remain empty (for example: Design Hierarchy, Verification Hierarchy, Diagrams, etc.). At first glance, this may appear to be a DVT issue. In reality, the problem originates from VS Code’s process architecture and contention in the shared user data directory. See the VS Code Empty Webviews application note for more details.

Using DVT with LSF

The DVT extension consists of two major components (see the Flow Integration application note for more details):

  • Extension Host – integrates DVT functionality into VS Code and manages communication with the language server.

  • Language Server – performs resource-intensive operations such as parsing, indexing, and analysis.

Because these components are independent, it is possible to run the language server on a farm machine without running the entire VS Code application remotely.

Option 1: Run the Language Server on the Farm

This is the recommended approach.

Keep the VS Code UI running on your local machine and configure DVT to launch only the language server on the farm machine. This avoids the multiple-master problem while still offloading resource-intensive processing to the compute farm. You can do so by prepending the bsub command to the language server launch command by updating the DVT.languageServer.launchCommand preference.

Option 2: Run a Single VS Code Instance on the Farm

If running the full IDE on a farm machine is unavoidable, ensure that only one VS Code job is active at any given time.

Additionally, launch VS Code using one of the following options:

  • -w

  • -noexit (when using dvt_code.sh)

These options cause the launching terminal to wait until VS Code exits. This prevents VS Code from detaching and being reparented to PID 1, which could allow it to escape the LSF job and later be terminated by watchdog processes that clean up orphaned applications.

Option 3: Run Multiple VS Code Instances on the Farm

If multiple VS Code instances must run simultaneously, launch each one using dvt_code.sh with the -enable_process_separation option.

This option creates a dedicated user data directory for each VS Code instance while partially symlinking shared data to reduce duplication and preserve as much state as possible.

Because some data cannot be shared safely, each isolated instance behaves as an independent VS Code installation. For example, extensions such as GitHub Copilot must be authenticated separately in every instance.