Remote Servers: VSCode vs JupyterLab

Step-by-step on how to launch a code editor on a remote server.

My primary preference for a code editor is Visual Studio Code. However, updates to its underlying Node.js runtime (v22.2.0 and v20.15.0, released in mid-2025) introduced a WebAssembly trap handler that reserves 10 GB of virtual memory. This change can prevent VSCode from launching or connecting to certain remote servers where that much address space is not available. As a workaround, we have two options: 1) use Jupyter Lab or 2) fix the issue in the remote server.

I hope this simple step-by-step guide helps you quickly edit and run your code smoothly.

1. Using Jupyter Lab

• Step 1: Create an SSH tunnel to access port 6006 on the remote server from your local machine

ssh -L 6006:localhost:6006 userID@remote_server.login

• Step 2: After connecting, navigate to your working directory on the remote server

cd workin_dir

• Step 3: Launch JupyterLab on the remote server, binding it to port 6006 without opening a browser

jupyter lab --no-browser --port=6006

• Step 4: Copy the URL with the token (e.g., http://localhost:6006/lab?token=...) and open it in your local browser to access JupyterLab running on the remote server

2. Fixing Visual Studio Code remote connection

If you’re like me and enjoy the practicality of VSCode, but need to use it on a remote server with limited memory allocated to your user, you may encounter the same issue I faced, described below:

/RangeError: WebAssembly.instantiate(): Out of memory: Cannot allocate Wasm memory for new instance
    at lazyllhttp (node:internal/deps/undici/undici:5829:32)

Node.js v22.15.1

This issue is caused by the WebAssembly trap handler, which replaces inline bounds checks but requires reserving 10 GB of virtual memory. The fix is to disable the trap handler by adding the following line to your .bashrc file on the remote server:

export NODE_OPTIONS="--disable-wasm-trap-handler"

From the documentation of Node.js: "By default, Node.js enables trap-handler-based WebAssembly bound checks. As a result, V8 does not need to insert inline bound checks int the code compiled from WebAssembly which may speedup WebAssembly execution significantly, but this optimization requires allocating a big virtual memory cage (currently 10GB). If the Node.js process does not have access to a large enough virtual memory address space due to system configurations or hardware limitations, users won't be able to run any WebAssembly that involves allocation in this virtual memory cage and will see an out-of-memory error."

In other words, the trap handler makes WebAssembly faster by removing inline bounds checks, but since it requires reserving a 10 GB virtual memory cage, we disable it so that Wasm can still run (with reduced performance) on remote servers and HPC systems where Node.js cannot allocate that space.

Credits

Thank you Morgan Handojo for sharing this solution with me and a special thank you to Logan Persyn for finding the solution.

This issue is now discussed on https://github.com/microsoft/vscode/issues/251777.