[Regression] VS Code UI renders with a monospace font

[viniciosrab]

Describe the bug

After a recent update, the entire Visual Studio Code workbench UI renders with a monospace font on Aurora KDE Wayland. This affects menus, tabs, Explorer, Settings, and other workbench text. Other applications visible alongside VS Code render proportional UI text normally.

The VS Code editor and integrated terminal intentionally have their own font settings, but those settings should not affect the workbench UI. No extension that injects or customizes VS Code CSS is installed, and the installed VS Code files have no RPM digest mismatch.

The host reports Noto Sans as both the KDE general font and the system-ui/sans-serif fontconfig match. A separate monospace font is configured only as the KDE fixed-width font and for the VS Code terminal. The renderer appears to be selecting a monospace/fixed-width path for system-ui, but that mechanism is only a hypothesis; the directly observed regression is that VS Code alone renders its workbench UI monospaced.

Steps to reproduce:

1. Boot Aurora 44.20260804.1 with Plasma 6.7.3 on Wayland.
2. Configure KDE General font as Noto Sans 10 and Fixed Width font as a monospace font.
3. Launch the official VS Code RPM build, version 1.131.0.
4. Open Explorer or Settings.
5. Observe that menus, tabs, Explorer entries, and Settings text are monospaced.
6. Compare with another graphical application: its normal UI text remains proportional.

This started recently; the previous Aurora deployment is 44.20260728.1. VS Code 1.131.0 was installed on August 3, so this may be an Aurora/Plasma/Electron integration regression or an upstream VS Code/Electron regression that needs routing.

What did you expect to happen?

VS Code workbench UI should use the KDE general/system UI font (Noto Sans), while only the editor and integrated terminal use their explicitly configured monospace fonts.

Output of rpm-ostree status

State: idle
AutomaticUpdates: stage; rpm-ostreed-automatic.timer: inactive
Deployments:
● ostree-image-signed:docker://ghcr.io/ublue-os/aurora-dx-nvidia-open:stable
                   Digest: sha256:5869c4b595d11b64042655ba55920ed0f68974ea28d6d80ff633a097888c22e6
                  Version: 44.20260804.1 (2026-08-04T01:43:36Z)

  ostree-image-signed:docker://ghcr.io/ublue-os/aurora-dx-nvidia-open:stable
                   Digest: sha256:bcdca19ec195adc9b30001c951defc0b344f7cb02be416f1853ed2245b541562
                  Version: 44.20260728.1 (2026-07-28T01:44:58Z)

Output of groups

<user> wheel libvirt incus-admin docker

Extra information or context

Aurora: 44.20260804.1 (Kinoite)
Image: aurora-dx-nvidia-open
Kernel: 7.0.12-201.fc44.x86_64
Session: KDE / Wayland
Plasma: 6.7.3
KWin: 6.7.3
VS Code: 1.131.0 (commit e4c7e7b1d6d060162f4aa7f8225271b67ce1df75)
VS Code RPM: code-1.131.0-1785237908.el8.x86_64

Font diagnostics:

$ kreadconfig6 --file kdeglobals --group General --key font
Noto Sans,10,-1,5,50,0,0,0,0,0

$ kreadconfig6 --file kdeglobals --group General --key fixed
MesloLGL Nerd Font Mono,10.3,-1,5,400,0,0,0,0,0,0,0,0,0,0,1,,0,0

$ fc-match system-ui
NotoSans-Regular.ttf: "Noto Sans" "Regular"

$ fc-match sans-serif
NotoSans-Regular.ttf: "Noto Sans" "Regular"

$ fc-match monospace
NotoSansMono-Regular.ttf: "Noto Sans Mono" "Regular"

The shipped VS Code Linux workbench CSS uses:

.monaco-workbench.linux {
  font-family: system-ui, Ubuntu, Droid Sans, sans-serif;
}

Changing editor.fontFamily or terminal.integrated.fontFamily does not provide an official way to control the workbench UI font.

[inffy]

Seems i am not able to reproduce this issue on two different machines (aurora-dx:testing). UI and settings etc look fine to me

[viniciosrab]

Thanks for checking. I reproduced the same monospace workbench UI with a completely clean VS Code profile and all extensions disabled:

code --disable-extensions --user-data-dir /tmp/vscode-font-test

The fresh window has the same issue, so this rules out installed extensions and existing VS Code user data. The affected system is aurora-dx-nvidia-open:stable 44.20260804.1, while the reported non-reproducing systems use aurora-dx:testing.

[viniciosrab]

I narrowed this down further on the affected aurora-dx-nvidia-open:stable host. Using the Chrome DevTools Protocol against an isolated VS Code renderer, the workbench computed CSS is correct:

system-ui, Ubuntu, "Droid Sans", sans-serif

However, CSS.getPlatformFontsForNode reports that the menu text is actually rendered with CaskaydiaMono NF. I also injected temporary test elements requesting system-ui, sans-serif, Ubuntu, Droid Sans, and Noto Sans individually. Electron rendered every one of them as CaskaydiaMono NF, while fc-match system-ui, fc-match sans-serif, and fc-match 'Noto Sans' outside Electron all resolve to Noto Sans correctly.

As a control, I launched another isolated VS Code instance with a temporary fontconfig file that rejects only Caskaydia. Electron then rendered system-ui as another monospace font, IosevkaTerm NF, rather than Noto Sans. This rules out a malformed Caskaydia alias and points to the Electron/Chromium font-matching path selecting monospace fonts broadly. The VS Code 1.131.0 renderer (Electron 42.7.0) is launched with --disable-blink-features=FontMatchingCTMigration,StandardizedBrowserZoom,; explicitly passing --enable-blink-features=FontMatchingCTMigration still leaves the VS Code-added disable switch present and does not change the result.

Relevant package versions on this Aurora DX installation are fontconfig-2.17.0-4.fc44, freetype-2.14.3-1.fc44, and harfbuzz-14.1.0-2.fc44. This appears to be below the VS Code CSS/settings layer and reproducible in a clean profile.