Image preview fails with "WebGL2 is not supported" — GPU/ANGLE context init fails on Linux despite healthy host OpenGL

Does this issue occur when all extensions are disabled?: Yes

• VS Code Version: 1.128.0 (commit fc3def6774c76082adf699d366f31a557ce5573f, build date 2026-07-07), Snap build (latest/stable, revision 249, publisher "vscode", classic confinement)


• OS Version: Ubuntu 24.04 (noble), Linux kernel 6.8.0-134-generic, x86_64 (X11 session)

Steps to Reproduce:

1. On the environment described here, open any .jpg or .png file in VS Code's built-in image viewer.


2. The viewer displays the error "WebGL2 is not supported." and the image does not render. (Confirmed still reproduces with code --disable-extensions.)

Full environment

• VS Code version: 1.128.0 (commit fc3def6774c76082adf699d366f31a557ce5573f, build date 2026-07-07)


• Install method: Snap (latest/stable, revision 249, publisher "vscode", classic confinement)


• OS: Ubuntu 24.04 (noble), Linux kernel 6.8.0-134-generic, x86_64


• Session: X11 (display :0)


• CPU: Intel Core i7-8665U


• GPU: Intel UHD Graphics 620 (Whiskey Lake GT2)


• Graphics driver: Mesa 25.2.8 (OpenGL 4.6 core/compat, OpenGL ES 3.2)

Expected behavior

The image renders in the built-in viewer, as it did prior to the recent update. The host has a healthy, hardware-accelerated OpenGL stack, so WebGL2 should be available.

Actual behavior

Image preview fails with "WebGL2 is not supported." VS Code's GPU process fails to initialize an OpenGL context (ANGLE over EGL) and exits, so all rendering falls back to software and WebGL2 is unavailable.

Timeline / regression

The problem began within roughly the two weeks prior to 2026-07-14, with no configuration changes on my end. This coincides with the 1.128.0 release (build date 2026-07-07). Image preview worked out of the box before this.

Key evidence

glxinfo -B — host OpenGL is fully functional and hardware-accelerated:

• direct rendering: Yes


• Device: Mesa Intel(R) UHD Graphics 620 (WHL GT2)


• Mesa 25.2.8, OpenGL core/compat 4.6, OpenGL ES 3.2, "Accelerated: yes"

So the driver, Mesa, and hardware are not the problem.

code --status — VS Code's own GPU process cannot create a context:

• All GPU features report disabled_software / disabled_off


• GPU0: VENDOR=0x0000, DEVICE=0x0000 (GPU not identified by VS Code)


• GPU process exits during initialization. Log excerpt:

ANGLE Display::initialize error 12289: Could not create a backing OpenGL context.

EGL Driver message (Critical) eglInitialize: Could not create a backing OpenGL context.

eglInitialize OpenGL failed with error EGL_NOT_INITIALIZED, trying next display type

eglInitialize OpenGLES failed with error EGL_NOT_INITIALIZED

Initialization of all (2) EGL display types failed.

GLDisplayEGL::Initialize failed.

Exiting GPU process due to errors during initialization

Things already investigated and tried (with results)

Step | Result
-- | --
argv.json checked for disable-hardware-acceleration | Not enabled; hardware acceleration is on
Full apt update && apt upgrade + reboot | No change (upgrade included no Mesa/GPU-driver/kernel changes)
glxinfo -B | Host hardware OpenGL fully working (see above)
/dev/dri permissions + user groups checked | User was not in render/video groups; DRI nodes carry ACLs
sudo usermod -aG render,video + reboot | No change
Launch with --ignore-gpu-blocklist | No change (not a blocklist issue)
Launch with --use-gl=desktop | No change (flag no longer honored by current Chromium)
Launch with --enable-unsafe-swiftshader | Works — images render via software (CPU) WebGL2
Launch with --in-process-gpu | VS Code fails to launch entirely (in-process GPU makes the init failure crash the app)

Known working workaround

code --enable-unsafe-swiftshader restores image viewing via software WebGL2. This is a per-launch workaround, not a fix; hardware-accelerated rendering inside VS Code remains broken while the host OpenGL stack is provably healthy.

Notes on scope

It is not yet confirmed whether the Microsoft .deb/apt build of the same version shows the same failure, or whether it is specific to the snap runtime. The underlying error ("Could not create a backing OpenGL context") has been reported by other Linux users; a prior issue (#207250) was closed as not planned.