Vibrancy Continued: acrylic and mica windows for VS Code, and the checksum warning

How an extension changes a window it does not own

The mechanism is unusual enough to be the first thing to understand. Vibrancy Continued works by editing VS Code's checksum-verified HTML files, which means a warning prompt appears after you install and enable it, telling you that your VS Code installation appears to be corrupt. The README says the warning is safe to disregard and that all changes can be reverted, and you can click the cogwheel and select Don't Show Again to hide it. If you do not have the option to hide the alert, or you want to clear an Unsupported warning in the VS Code title bar, the README points to a separate extension, Fix VSCode Checksums Next. So the extension is not hooking a supported window API, it is rewriting the resources the editor loads, and the checksum verification is the safety net that fires when it does.

The three-step setup and the update treadmill

Getting started is short. Install the extension from the Visual Studio Code Marketplace. Press F1 and activate the command Reload Vibrancy. Restart VS Code when prompted. Then there is the part that decides whether you keep it. Each time VS Code is updated, you have to re-enable Vibrancy using the same steps, because the update replaces the files the extension edited. The README points to the FAQ for issues. The extension is published on both the Visual Studio Code Marketplace and the Open VSX Registry, and there is a workflow in the repository that tests against the nightly VS Code Insiders build on a schedule, which is a reasonable proxy for how often the upstream editor changes under you.

Which editors it will touch

The supported list is longer than the name suggests. Visual Studio Code is supported at version 1.95 and newer, and so are VSCodium, Code - OSS, Cursor, Antigravity, Devin and Kiro. Other editors built on VS Code may work too, but the README explains the condition: Vibrancy changes their window only when it can tell exactly where the change goes, and it warns that the result is untested. If it cannot tell, it refuses with the message that your code editor is not supported. That refusal is a design decision rather than a bug, because an editor that renders its window differently would get a broken result with no way for the extension to know. The package manifest encodes the floor as an engines entry requiring VS Code ^1.95.0, and the extension declares itself as a UI extension kind and activates on startup finished.

Windows: the borderless versus snapping trade-off

On Windows the extension works out of the box with no extra setup, and by default the window is borderless and opaque, so Aero Snap, maximize and resize all keep working. The trade-off comes from a platform fact: a transparent window on Windows is a layered window, and the OS excludes layered windows from Aero Snap and maximize. The default mode, auto, gives an opaque window where snapping works but Windows 10 draws a thin one pixel border around it, which disappears while you drag and which Windows 11 does not show at all. The alternative, frameless-transparent, gives a fully transparent window with no border at all, the cleanest possible look, but Aero Snap and maximize stop working. The README notes that on older VS Code builds, where opaque vibrancy rendered incorrectly, auto instead uses a transparent window, which matches frameless-transparent. If you want both, the tip is to set the transparent mode and use a third-party snapping utility such as FancyZones from PowerToys.

Windows 11 materials and the configuration surface

On Windows 11 the backdrop material is chosen through the vscode_vibrancy.type setting, with acrylic as the default and described as a real-time transparent material, and mica as the alternative. The configuration in the package manifest is broader than that one setting, because the type property is an enum of auto, acrylic, mica, tabbed, transparent, under-window and fullscreen-ui, defaulting to auto, and the window mode is a separate setting with values including auto and frameless-transparent.

"vscode_vibrancy.type": {
  "description": "%configuration.type.description%",
  "type": "string",
  "default": "auto",
  "enum": [
    "auto",
    "acrylic",
    "mica",
    "tabbed",
    "transparent",
    "under-window",
    "fullscreen-ui"

The fact that the same setting offers seven values, and that the same extension produces a materially different window depending on which one is chosen, is which is why the README lists the supported operating systems and their caveats rather than a single recommended configuration.

macOS, Linux and NixOS

macOS is supported on both Intel and Apple Silicon, with no separate notes in the README, which is unusual for a project of this kind and suggests the macOS path is the least troublesome. Linux is supported but with a restriction stated in the same line: transparency only, and blur requires a compositor such as KWin, Hyprland or Picom. There is a dedicated section in the README about Linux, why the background is transparent but not blurred, which is the expected symptom on a compositor that does not implement the blur protocol. NixOS gets its own note, and it is supported via an automatic writable copy, which is what a Nix user needs because the editor installation is read-only in the store. The README also links a page on restoring an editor that will not start, which is the failure mode that follows from editing files inside an installation.

What is in the repository

The repository is a Visual Studio Code extension with a native component, and the layout shows it. There is an extension directory holding the extension entry point, which the package manifest points at as the main file, a native directory for the native code, and a binding.gyp.dist file, which is the template for a node-gyp binding. There are theme directories, an images directory for the logo and the screenshots the README uses, a docs directory holding the known errors page, and scripts for the build. Localisation is handled through nls-schema.json and the package.nls files, with Japanese and Simplified Chinese translations alongside the base file. The tests use Vitest with a vitest.config.mjs and a __mocks__ directory, and there is an AGENTS.md, a CHANGELOG.md and a .vscodeignore file. The licence field says MIT, with a LICENSE.txt at the root, and the recent releases are v1.4.0 from 2026-10-05, v1.3.1 and v1.3.0 both from 2026-10-02.

Where Vibrancy Continued is the wrong choice

Four limits apply. It is an editor modification rather than a theme, so every VS Code update undoes it and you have to re-apply it, which is the kind of friction that ends a preference within a month for some people. It produces a corruption warning from the editor itself, and while the README says it is safe to disregard, a warning about your installation is not something you can unsee every launch without dismissing it. On Linux, without a compositor that blurs, you get a transparent window and no effect, which is a confusing result for a project whose whole point is the effect. And the extension refuses to run on editors it does not recognise, which is safe but means the answer on a fork or a new build is usually no. The value is genuinely there on macOS and Windows 11, where the effect is real and the setup is one command, but it is a cosmetic dependency on the editor's internals, and that is the trade you are making.

Editorial conclusion

Use Vibrancy Continued if you want a translucent editor window on macOS or Windows and you are willing to re-apply the effect after each VS Code update, since that is exactly what the extension does and the workflow is documented in three steps. Do not expect it to work everywhere, because Linux is transparency only without a blurring compositor, and any editor build other than the listed ones is refused rather than guessed at. Verify first that your editor is on the supported list and that it is VS Code 1.95 or newer, that you understand the checksum warning is expected and how to hide it, and that you know how to restore an editor that will not start, since the extension edits files inside the installation.

Frequently asked questions

Official sources

1. illixion/vscode-vibrancy-continued on GitHub
2. Issues
3. License: MIT
4. README
5. Releases