Configuring VS Code and Cursor¶

This documentation is only useful if you plan to use VS Code to edit files stored in the cluster file system remotely. You should also check the docs in Remote Editing and specially the specific section related to how to configure the VS Code SSH plugin

If you have already used VS Code before in the cluster, it’s recommended that you follow these steps before continuing with this documentation:

• Close VS Code on your computer
• Terminate all your running vscode processes on vscode.scicore.unibas.ch with

pkill -u $USER -9 -f .vscode-server
pkill -u $USER -9 -f .cursor-server

• Delete your current config from the cluster filesystem executing rm -fr ~/.vscode-server/ and rm -fr ~/.cursor-server/ in any login node

Why VS Code is a problem in the cluster¶

VS Code’s remote development model is designed for a machine with a local/fast disk, not for a shared login node with a network home directory. Three things go wrong:

Multiply that by every concurrent VS Code user and the result is the slow ls, slow cd and slow logins that you have probably already noticed.

Step 1 — Move the VS Code server off NFS¶

This is the single most important change on this page. By default VS Code installs its server into ~/.vscode-server, which is on NFS. We want it on the login node’s local disk instead.

On your own machine (not the cluster), open the VS Code Settings JSON:

• Press f1 (or ctrl+shift+p (Windows) / cmd+shift+p (Mac))
• Run Preferences: Open User Settings (JSON)

Add the following, replacing USERNAME with your cluster username:

{
    "remote.SSH.serverInstallPath": {
        "vscode.scicore.unibas.ch": "/scratch/vscode/USERNAME"
    },
    "remote.SSH.connectTimeout": 120
}

Then, once, SSH to the vscode login node from your terminal and create the following directory on the scratch folder:

# Local machine terminal
ssh USERNAME0000@vscode.scicore.unibas.ch
# VS Code login node
mkdir -p /scratch/vscode/$USER
chmod 700 /scratch/vscode/$USER
ln -s /scratch/vscode/$USER/.vscode-server ~/.vscode-server
ln -s /scratch/vscode/$USER/.cursor-server ~/.cursor-server

Step 2 — Tame the file watcher and the indexers¶

Still on your local machine, in the same settings.json, add:

{
    "files.watcherExclude": {
        "**/.git/objects/**": true,
        "**/.git/subtree-cache/**": true,
        "**/node_modules/**": true,
        "**/.conda/**": true,
        "**/conda/**": true,
        "**/miniconda3/**": true,
        "**/venv/**": true,
        "**/.venv/**": true,
        "**/site-packages/**": true,
        "**/__pycache__/**": true,
        "**/.mypy_cache/**": true,
        "**/.pytest_cache/**": true,
        "**/data/**": true,
        "**/results/**": true
    },
    "search.followSymlinks": false,
    "search.exclude": {
        "**/node_modules": true,
        "**/site-packages": true,
        "**/data": true,
        "**/results": true
    },
    "python.analysis.indexing": false,
    "python.analysis.userFileIndexingLimit": 0,
    "python.analysis.autoSearchPaths": false,
    "git.autofetch": false,
    "git.autorefresh": false,
    "telemetry.telemetryLevel": "off",
    "extensions.autoUpdate": "off",
    "extensions.autoCheckUpdates": false
}

What each group does:

• files.watcherExclude — stops VS Code polling directories that never change in ways you care about. Add your own large data directories.
• search.followSymlinks: false — prevents a full-text search from wandering out of your project and across the whole filesystem via a symlink.
• python.analysis.* — stops Pylance from walking every Python environment on the system. You keep syntax checking and completion for files you actually open; you lose “go to definition” into third-party libraries you have not opened.
• git.autofetch / git.autorefresh — stops a git status (and possibly a network fetch) firing every few seconds against a repository on NFS.
• extensions.autoUpdate — stops extensions being silently re-downloaded and re-unpacked into your home directory in the background.

Step 3 — Keep your workspace small¶

Other habits that help a lot:

• Close the remote window when you stop working. A forgotten VS Code window keeps polling all night. Use File → Close Remote Connection, don’t just close your laptop lid.
• Don’t open more remote windows than you need. Each one starts its own set of extension host processes.
• Keep large datasets out of the workspace tree, or add them to files.watcherExclude as shown above.

I don’t want these settings on my local projects¶

The configuration in Step 2 is written into your User Settings, so it applies to every VS Code window you open — local ones included. If you also use VS Code for work that is unrelated to the cluster, you may not want git.autofetch disabled or Pylance indexing turned off everywhere.

Two supported ways to scope the settings to your cluster work only. Both work; pick whichever fits your habits.

Option A — A dedicated “scicore” profile¶

A profile is a named bundle of settings, extensions and UI state. Settings put in a profile only apply to windows using that profile.

1. File → Preferences → Profiles → Create Profile…
2. Name it scicore. Choose Empty Profile, or copy from your current one.
3. With the scicore profile active, run Preferences: Open User Settings (JSON) and paste the Step 2 block there.
4. Connect to vscode.scicore.unibas.ch. In that remote window, select the profile via File → Preferences → Profiles → scicore.

VS Code remembers the profile per folder/workspace, so the next time you open that same remote folder it comes back with the scicore profile already applied. Your other projects keep your normal settings.

Option B — Put the settings on the server¶

Settings can also live on the cluster side, next to the code they apply to.

Per project — create .vscode/settings.json inside the project directory on the cluster. This is the best place for the excludes that are really properties of the project (**/data/**, **/results/**):

{
    "files.watcherExclude": {
        "**/.git/objects/**": true,
        "**/node_modules/**": true,
        "**/.conda/**": true,
        "**/venv/**": true,
        "**/.venv/**": true,
        "**/site-packages/**": true,
        "**/__pycache__/**": true,
        "**/.mypy_cache/**": true,
        "**/.pytest_cache/**": true,
        "**/data/**": true,
        "**/results/**": true
    },
    "search.followSymlinks": false,
    "search.exclude": {
        "**/site-packages": true,
        "**/data": true,
        "**/results": true
    },
    "python.analysis.indexing": false,
    "python.analysis.userFileIndexingLimit": 0,
    "python.analysis.autoSearchPaths": false,
    "git.autofetch": false,
    "git.autorefresh": false
}

You have to repeat this in every project — but you can commit it to the repository, which means your collaborators get it for free.

For every project on the cluster at once — use the machine settings file, which applies to all windows connected to that host. From a VS Code terminal on the login node, run Preferences: Open Remote Settings (SSH: vscode.scicore.unibas.ch), or write the file directly:

mkdir -p /scratch/vscode/$USER/data/Machine
$EDITOR /scratch/vscode/$USER/data/Machine/settings.json

Paste the same JSON block as above.

ssh vscode.scicore.unibas.ch \
    'mkdir -p /scratch/vscode/$USER/data/Machine && cat > /scratch/vscode/$USER/data/Machine/settings.json' \
    < scicore-machine-settings.json

What happens if I ignore this¶

We monitor per-user I/O and CPU on the login nodes. Sessions that generate sustained, excessive load will be throttled automatically, and repeat offenders will have their processes terminated without warning. This is not a punishment — a single misconfigured VS Code session can measurably degrade the login node for dozens of other people.

If you get throttled, work through this page and reconnect.

Complete reference configuration¶

For convenience, here is everything from steps 1 and 2 in a single block. Merge it into your local User Settings (JSON) and change USERNAME and the host name. If you would rather not have these settings apply to your local projects, see I don’t want these settings on my local projects.

{
    "remote.SSH.serverInstallPath": {
        "vscode.scicore.unibas.ch": "/scratch/vscode/USERNAME"
    },
    "remote.SSH.connectTimeout": 120,
    "files.watcherExclude": {
        "**/.git/objects/**": true,
        "**/.git/subtree-cache/**": true,
        "**/node_modules/**": true,
        "**/.conda/**": true,
        "**/conda/**": true,
        "**/miniconda3/**": true,
        "**/venv/**": true,
        "**/.venv/**": true,
        "**/site-packages/**": true,
        "**/__pycache__/**": true,
        "**/.mypy_cache/**": true,
        "**/.pytest_cache/**": true,
        "**/data/**": true,
        "**/results/**": true
    },
    "search.followSymlinks": false,
    "search.exclude": {
        "**/node_modules": true,
        "**/site-packages": true,
        "**/data": true,
        "**/results": true
    },
    "python.analysis.indexing": false,
    "python.analysis.userFileIndexingLimit": 0,
    "python.analysis.autoSearchPaths": false,
    "git.autofetch": false,
    "git.autorefresh": false,
    "telemetry.telemetryLevel": "off",
    "extensions.autoUpdate": false,
    "extensions.autoCheckUpdates": false
}

Troubleshooting¶

[ "$(readlink ~/.vscode-server)" = "/scratch/vscode/$USER/.vscode-server" ] && echo ok || echo wrong - this should be a symlink
ls -d /scratch/vscode/$USER/.vscode-server && echo "OK - on local disk"

[ "$(readlink ~/.cursor-server)" = "/scratch/vscode/$USER/.cursor-server" ] && echo ok || echo wrong - this should be a symlink
ls -d /scratch/vscode/$USER/.cursor-server && echo "OK - on local disk"

rm -rf ~/.vscode-server
rm -rf ~/.cursor-server
ln -s /scratch/vscode/$USER/.vscode-server ~/.vscode-server
ln -s /scratch/vscode/$USER/.cursor-server ~/.cursor-server

rm -rf ~/.vscode-server

rm -rf /scratch/vscode/$USER/.vscode-server

{ "python.analysis.indexing": true }