[BUG] TerminalFont reports Cascadia Mono when Windows Terminal font comes from a JSON fragment

[csp256]

Read the FAQ first

• I have checked the FAQ but the issue is not covered.

Description

Fastfetch reports Cascadia Mono when the active Windows Terminal profile inherits its font face from a JSON fragment rather than defining it directly in settings.json.

The font loads successfully and icons render, but Fastfetch continues to report Cascadia Mono, including after restarting Windows. This is a font-reporting issue, not a request to change the actual terminal font.

Version used

fastfetch 2.67.0 (x86_64)

The same detection logic appears to remain on the current dev branch (source inspection; I have not built dev).

Bug prevalence

Always with the affected fragment-based profile.

Regression

Not sure.

Installation

Package manager: WinGet (Fastfetch-cli.Fastfetch).

Configuration / reproduction

The following is a sanitized example of the affected configuration.

Create %LOCALAPPDATA%\Microsoft\Windows Terminal\Fragments\Example\profile.json:

{
  "profiles": [
    {
      "guid": "{9d38a6f8-79ca-4dc8-bf39-4bb729fa0f12}",
      "name": "Fragment Font Test",
      "commandline": "powershell.exe",
      "font": {
        "face": "JetBrainsMono NFM",
        "size": 13
      }
    }
  ]
}

Use an installed font other than Cascadia Mono. Restart Windows Terminal and open this profile. The corresponding entry in the main settings.json has no font.face override, for example:

{
  "guid": "{9d38a6f8-79ca-4dc8-bf39-4bb729fa0f12}",
  "name": "Fragment Font Test",
  "source": "Example",
  "font": { "size": 13 }
}

profiles.defaults is empty. Run in that profile:

fastfetch -s TerminalFont

Expected:

Terminal Font: JetBrainsMono NFM (13pt)

Actual font line observed in Fastfetch's startup output:

Terminal Font: Cascadia Mono (13pt)

System information

Relevant system details only; unrelated machine identifiers, networking, and hardware details are omitted:

• Windows 11 Pro 25H2, x86_64
• Windows Terminal 1.24.11911.0 (Microsoft Store installation)
• PowerShell 7.6.5 in the affected profile
• Fastfetch 2.67.0
• Fragment configured font: JetBrainsMono NFM, 13pt
• Main profile font override: size 13 only
• Main profiles.defaults: {}

Features built-in

threads
vulkan
imagemagick7
chafa
zlib
opencl
libzfs
Embedded wcwidth
WinRT headers
Windows 8.1 Compatibility
Lua 5.5
QuickJS 0.15.1

Suspected cause / proposed direction

In src/detection/terminalfont/terminalfont_windows.c, detectFromWTImpl() reads the active profile and profiles.defaults from the main settings file, then falls back to "Cascadia Mono" if neither specifies a font face. It does not resolve settings inherited from JSON fragments.

Would you accept a PR adding filesystem-fragment support for font detection, respecting explicit user overrides and Windows Terminal's settings precedence?

This would cover fragments under the current-user and system-wide Microsoft\Windows Terminal\Fragments directories. Packaged-app fragments and other inheritance cases could be discussed as part of the scope.

Reference: Windows Terminal JSON fragment extensions

[csp256]

Created a working branch from upstream dev for this: fix/windows-terminal-fragment-font.

100% clanker branch 🤖 — AI-assisted work, explicitly disclosed. It is currently just the branch baseline; no implementation or validation to claim yet, and no PR opened. Planning to start with filesystem fragments while respecting user overrides and font-face/size inheritance; feedback on scope is welcome before proceeding.

[CarterLi]

PR is welcome.

AI-assisted work is OK, I use it too, as long as the code is properly reviewed.