Blank UI text / SkFontMgr FATAL on Linux when a containerised Electron app shares ~/.cache/fontconfig — root cause + fix

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Cursor shows no text / aborts with SkFontMgr … Not implemented when another Electron app runs in a Distrobox container — root cause + fix

Setup: Fedora 44, GNOME 50.4 (Wayland), kernel 7.2.5, fontconfig 2.17.0. Cursor 3.20.21 (RPM, Chromium 148). Claude Desktop 2.110.0 installed from its Ubuntu .deb inside a Distrobox (Ubuntu 24.04, fontconfig 2.15.0) container that shares my home directory.

Symptoms

  • Cursor opens, icons/panels render, every text string is blank. Chrome, Slack, GTK apps fine.
  • Or Cursor dies within seconds (“Cursor Is Not Responding”, SIGTRAP core dump).
  • Journal shows, every time:
ERROR:third_party/blink/renderer/core/css/remote_font_face_source.cc:365] NOTREACHED hit.
FATAL:third_party/skia/src/ports/SkFontMgr_FontConfigInterface.cpp:163] Not implemented.
  • Intermittent: only happens if the containerised Electron app was launched before Cursor.

Root cause: fontconfig cache collision via the shared home

Electron apps write fontconfig caches to ~/.cache/fontconfig/, named <hash of font dir path>-le64.cache-11. The container shares $HOME, so Claude Desktop writes to the same directory — but its /usr/share/fonts is Ubuntu’s (truetype/ only), while the host’s has 47 Fedora font dirs. Same path → same hash → same filename → same tag. Whoever launched last wins. When the container app wins, Cursor’s next start trusts a cache describing fonts that don’t exist on the host → web-font fallback fails → Skia font manager aborts or draws nothing.

Host apps read cache-9 (system fontconfig 2.17) and never see the cache-11 files. Chrome also writes cache-11 but for the same Fedora fonts, so it never conflicts.

Steps to Reproduce

Requires two Electron apps sharing one home directory, one of them inside a container whose /usr/share/fonts differs from the host’s. My case: Cursor 3.20.21 on the Fedora 44 host; Claude Desktop 2.110.0 (.deb) inside a Distrobox Ubuntu 24.04 container (default Distrobox config shares $HOME).

  1. rm -rf ~/.cache/fontconfig # start from a clean shared cache
  2. Launch Cursor → renders normally. Quit Cursor.
  3. Launch the containerised Electron app (Claude Desktop). It writes ~/.cache/fontconfig/*-le64.cache-11 describing the CONTAINER’s /usr/share/fonts (Ubuntu: just truetype/).
  4. Launch Cursor → all UI text blank, or SIGTRAP within seconds. Journal shows:
    ERROR:third_party/blink/renderer/core/css/remote_font_face_source.cc:365] NOTREACHED hit.
    FATAL:third_party/skia/src/ports/SkFontMgr_FontConfigInterface.cpp:163] Not implemented.
  5. Quit the container app, rm -rf ~/.cache/fontconfig, launch Cursor → works again.

Fingerprint: ls -l ~/.cache/fontconfig shows cache-11 files whose mtime matches the container app’s launch. Reproduced 8/8 with the container app started first; 0/5 failures with it isolated to its own cache dir (fix in the description). A cold-boot sequence Slack → Chrome → Claude Desktop → Cursor passes after the fix.

Expected Behavior

Cursor should render its UI text regardless of what other applications have written to ~/.cache/fontconfig. A stale or foreign fontconfig cache should degrade to a rescan or a fallback font — not blank text, and never a FATAL abort in SkFontMgr_FontConfigInterface. At minimum the failure should be diagnosable: a visible error rather than a window with no strings.

The trigger (a container sharing the host’s fontconfig cache) is arguably a Distrobox default problem, and I’ve documented the workaround. But the lack of any defence in Cursor’s font loading is what turns it into a silent, unusable editor — and it will affect anyone running Slack/VS Code/Discord .debs or Claude Desktop in Distrobox/Toolbox alongside Cursor.

Screenshots / Screen Recordings

Screenshot From 2026-09-17 10-35-42.png
Screenshot From 2026-09-17 10-35-42.png1605×997 16.3 KB

Operating System

Linux

Version Information

IDE:
Version: 3.20.21
VSCode Version: 1.128.0
Commit: f09fca384ceca23f7bf21f9c23655b162641d740
Date: 2026-09-13T19:02:51.781Z
Electron: 42.10.0
Chromium: 148.0.7778.280
Package: cursor-3.20.21-1789329363.el8.x86_64 (official RPM; AppImage 3.20.21 reproduces identically)
OS: Fedora Linux 44 (Workstation Edition), kernel 7.2.5-200.fc44.x86_64, GNOME 50.4, Wayland

For AI issues: which model did you use?

N/A — not an AI/agent issue; startup rendering bug.

For AI issues: add Request ID with privacy disabled

N/A — no agent request involved. Console/journal errors quoted above.e

Additional Information

Not the cause (each tested with the container app running; each still failed): disable-hardware-acceleration, --disable-features=SkiaGraphite, --use-angle=swiftshader, --ozone-platform=x11, --disable-remote-fonts, the AppImage build, installing additional fonts (558 → 920 files), a DisplayLink/evdi dock, a fresh user profile, disabling all extensions.

Chrome 153 on the same host also writes cache-11 files but for the same Fedora fonts, so it never conflicts with Cursor — the container’s differing /usr/share/fonts under the identical path is the sole trigger.

Likely related unresolved report: “Cursor Editor Window Opens But UI Not Rendering on Manjaro Linux” (forum topic 150400) — same symptoms, same dead ends, VS Code fine on the same machine; that user cancelled. Worth checking whether they run an Electron app in a container.

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

5

Hey @N17z, thanks for the detailed report, and for sharing the fix.

We were able to confirm the mechanism on our side. When fontconfig cannot return any usable system font, Chromium (which Cursor is built on) draws normal UI text as blank and, once it has to lay out text with no candidate font at all, exits on purpose. Those are the two lines you saw in the journal. Icons and the logo still show because they come from fonts bundled inside the app, while regular UI text goes through fontconfig. This is upstream Chromium behaviour shared by every Electron app on the host, so it is not something Cursor can catch on its own today.

Your workaround is the right one. For anyone else landing here:

  1. Quit Cursor and the containerised app.
  2. Run rm -rf ~/.cache/fontconfig, then start Cursor again.
  3. To stop it recurring, give the container its own cache, for example by setting XDG_CACHE_HOME=$HOME/.cache/<container-name> inside the container before launching the app (fontconfig uses it for its cache directory).

If it comes back even with the caches separated, send us the output of fc-match sans-serif and ls -l ~/.cache/fontconfig from the host and we will dig further.