Ghostty Crash on Claude / TUI Output — fontconfig Cache Fix (Fedora)

Guide to diagnose and fix Ghostty terminal segfaulting and closing its window when a TUI app (e.g. Claude Code) prints rich output. Despite appearances, the trigger text (typing “resume”, running a command) is incidental — the crash is in Ghostty’s font-fallback path, not the app.

Environment where this was seen: Framework 16, Fedora 44, Ghostty 1.3.1-2.fc44, primary font JetBrainsMono Nerd Font, Radeon RX 7600M XT.

Symptoms

• Launching claude (or any TUI) in Ghostty, then typing/printing anything → the whole Ghostty window vanishes.
• The shell and the running app die with it (the terminal process itself crashed, not just the foreground program).
• Often appears to trigger on a specific word or command, but really fires on any output needing glyphs outside the primary font (spinners ⠋, box-drawing ─, Nerd Font icons, emoji).

Root cause

Ghostty segfaults (SIGSEGV) inside the system fontconfig while searching for a fallback font for a glyph not present in the primary font. Typical core-dump stack:

#0  FcCompare                                  ← fontconfig
#1  FcFontSetSort
#2  FcFontSort
#3  config.Config.fontSort
#4  font.discovery.Fontconfig.discoverFallback ← fallback lookup
#5  font.SharedGrid.getIndex
#6  renderer.OpenGL.rebuildRow                 ← while drawing a row

The user fontconfig cache in ~/.cache/fontconfig ends up holding multiple mismatched cache-format versions at once (e.g. cache-8, cache-9, cache-10, cache-11) with inconsistent permissions — usually after a fontconfig package update mid-session. FcCompare then reads a malformed cached pattern and crashes. A TUI app forces the fallback path, so it crashes almost immediately.

Diagnosis

1. Confirm it’s Ghostty crashing, not the app

coredumpctl list --since "-3days" | grep -i ghostty
journalctl --user -n 60 --no-pager | grep -iE "ghostty|segv|core-dump"

Look for status=11/SEGV / dumped core on /usr/bin/ghostty.

2. Inspect the backtrace

coredumpctl info /usr/bin/ghostty | sed -n '1,40p'

A stack containing FcCompare → FcFontSort → discoverFallback confirms the fontconfig-cache cause.

3. Inspect the cache for mixed versions

ls ~/.cache/fontconfig | sed -E 's/.*\.(cache-[a-z0-9-]+)$/\1/' | sort -u

More than one cache-N version (or mixed 600/644 perms via ls -la) indicates a corrupt/stale cache.

4. Verify the fonts themselves are healthy (rule out a broken font)

fc-cache -v 2>&1 | grep -iE "error|fail|corrupt"
fc-scan --error   # silent / exit 0 = fonts fine

If fonts scan clean, the cache is the culprit.

Solution

rm -rf ~/.cache/fontconfig
fc-cache -rfv

Then verify a single consistent cache version remains:

ls ~/.cache/fontconfig | sed -E 's/.*\.(cache-[a-z0-9-]+)$/\1/' | sort -u

Important: fully quit every Ghostty window and reopen — a running Ghostty keeps the old font state in memory, so a single new tab is not enough.

Confirm the fallback path now resolves

fc-match "monospace:charset=$(printf '%d' "'⠋")"   # braille spinner
fc-match "monospace:charset=$(printf '%d' "'─")"   # box-drawing

Each should print a real font (e.g. Noto Sans Mono) with no crash.

If it still crashes after a clean restart

The backtrace also passes through renderer.OpenGL, so the next suspect is the OpenGL renderer on the Radeon GPU. Try forcing a software/GL fallback, e.g.:

LIBGL_ALWAYS_SOFTWARE=1 ghostty

If that’s stable, the issue is GPU/driver-side rather than fontconfig.

Minor unrelated noise

During fc-cache -rfv you may see:

vazirmatn-vf-fonts: looped directory detected

Harmless symlink loop in that package, unrelated to the crash. Clean up with:

sudo dnf reinstall vazirmatn-vf-fonts