Issue Station
Sign In
Tools hereToolbox

hermes - ✅(Solved) Fix [Bug]: Theme font changes have no effect — Tailwind --font-sans not bridged to --theme-font-sans [2 pull requests, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
NousResearch/hermes-agent#20380•Fetched 2026-05-06 06:36:55
View on GitHub
Comments
0
Participants
1
Timeline
5
Reactions
0
Author
sanchomuzaxsanchomuzax
Participants
sanchomuzaxsanchomuzax
Timeline (top)
labeled ×3cross-referenced ×2

Root Cause

web/src/index.css sets the theme font on html and body:

html { font-family: var(--theme-font-sans); }
body { font-family: var(--theme-font-sans); }

However, Tailwind v4 defines its own --font-sans token independently (defaulting to ui-sans-serif, system-ui, sans-serif, …). Any element rendered with a font-sans class — which covers most of the Hermes UI — receives font-family: var(--font-sans) from Tailwind, bypassing --theme-font-sans entirely.

The bridge between the two variables is missing.

Fix Action

Fix / Workaround

Workaround (for plugin / theme authors)

PR fix notes

PR #20406: fix(web): bridge Tailwind --font-sans to --theme-font-sans

Description (problem / solution / changelog)

Summary

Bridges Tailwind v4's --font-sans and --font-mono CSS variables to Hermes's --theme-font-sans and --theme-font-mono so theme font changes actually take effect.

Root Cause

ThemeProvider.applyTheme() correctly updates --theme-font-sans and --theme-font-mono on :root. The html and body elements inherit these via font-family: var(--theme-font-sans).

However, Tailwind v4 defines its own --font-sans token independently (defaulting to ui-sans-serif, system-ui, sans-serif, …). Any element rendered with a font-sans Tailwind utility class receives font-family: var(--font-sans) — bypassing --theme-font-sans entirely.

Fix

Add --font-sans and --font-mono to the existing @theme inline block in web/src/index.css, mapping them to the theme variables:

@theme inline {
  --spacing: calc(0.25rem * var(--theme-spacing-mul, 1));
  --font-sans: var(--theme-font-sans);
  --font-mono: var(--theme-font-mono);
}

This makes Tailwind's font tokens follow the active Hermes theme, so both inherited font-family and explicit font-sans/font-mono class elements render the correct typeface.

Testing

  • TypeScript compiles clean (tsc --noEmit)
  • 1 file changed, +2 lines

Fixes #20380

Changed files

  • gateway/platforms/whatsapp.py (modified, +4/-1)
  • tests/tools/test_file_tools.py (modified, +37/-0)
  • tools/file_tools.py (modified, +6/-6)
  • web/src/index.css (modified, +2/-0)

PR #20472: fix(web): bridge Tailwind font-sans/mono tokens to theme variables

Description (problem / solution / changelog)

Fixes #20380.

Bug: When a Hermes theme sets a custom --theme-font-sans or --theme-font-mono via ThemeProvider.applyTheme(), Tailwind's font-sans / font-mono utility classes bypassed them entirely because Tailwind v4 resolves its own --font-sans / --font-mono tokens independently.

Fix: Add --font-sans and --font-mono to the existing @theme inline {} block in web/src/index.css, remapping Tailwind's tokens to follow --theme-font-sans / --theme-font-mono. Both inherited font-family (on html/body) and explicit font-sans class elements now render the correct theme typeface.

Changed files

  • web/src/index.css (modified, +6/-0)

Code Example

html { font-family: var(--theme-font-sans); }
body { font-family: var(--theme-font-sans); }

---

@theme inline {
  --font-sans: var(--theme-font-sans);
  --font-mono: var(--theme-font-mono);
}

---

:root[data-theme="my-theme"] *:not(code):not(pre):not(kbd) {
  font-family: "My Font", system-ui, sans-serif !important;
}
RAW_BUFFERClick to expand / collapse

Describe the bug

Changing the font in a dashboard theme has no visible effect on most UI elements. The --theme-font-sans CSS variable is correctly updated by ThemeProvider.applyTheme(), but the majority of Hermes UI components use Tailwind utility classes (e.g. font-sans) that resolve to Tailwind's own --font-sans variable — which is never updated when a theme is applied.

Steps to reproduce

  1. Create a user theme (or edit an existing one) and set a visually distinct font — e.g. "Playfair Display", Georgia, serif
  2. Activate the theme
  3. Observe: the UI font does not change

Setting --theme-font-sans via document.documentElement.style.setProperty() in the browser console confirms the variable is correctly written, yet most text continues to render in the default system font.

Root cause

web/src/index.css sets the theme font on html and body:

html { font-family: var(--theme-font-sans); }
body { font-family: var(--theme-font-sans); }

However, Tailwind v4 defines its own --font-sans token independently (defaulting to ui-sans-serif, system-ui, sans-serif, …). Any element rendered with a font-sans class — which covers most of the Hermes UI — receives font-family: var(--font-sans) from Tailwind, bypassing --theme-font-sans entirely.

The bridge between the two variables is missing.

Suggested fix

Add the following to web/src/index.css (or the appropriate Tailwind theme config):

@theme inline {
  --font-sans: var(--theme-font-sans);
  --font-mono: var(--theme-font-mono);
}

This makes Tailwind's own font tokens follow the active Hermes theme, so both inherited font-family (from html/body) and explicit font-sans class elements render the correct typeface.

Workaround (for plugin / theme authors)

Until this is fixed, theme authors can force the correct font via customCSS using !important:

:root[data-theme="my-theme"] *:not(code):not(pre):not(kbd) {
  font-family: "My Font", system-ui, sans-serif !important;
}

This was discovered while developing the hermes-theme-editor community plugin: https://github.com/sanchomuzax/hermes-theme-editor

(Side note — undocumented behaviour worth a docs fix: setting assets.bg to an empty string "" in a theme does not suppress the default Hermes background filler image; it leaves it visible. The only way to explicitly hide the filler is to set bg: "none". This is non-obvious and not mentioned anywhere in the theme authoring docs.)

Filed on behalf of Sancho by a Hermes Agent instance.

extent analysis

TL;DR

To fix the issue where changing the font in a dashboard theme has no visible effect on most UI elements, add a CSS rule to bridge the gap between the --theme-font-sans variable and Tailwind's own --font-sans token.

Guidance

  • Identify the CSS file where the theme font is set (e.g., web/src/index.css) and add the suggested fix to update Tailwind's font tokens.
  • Verify that the --theme-font-sans variable is correctly updated when a theme is applied by checking the browser console or inspecting the element styles.
  • As a temporary workaround, theme authors can use the customCSS approach with !important to force the correct font, but this should be replaced with the proper fix once available.
  • Be aware that this issue affects most UI elements using Tailwind utility classes, so a comprehensive solution is necessary for a consistent user experience.

Example

The suggested fix involves adding the following CSS rule:

@theme inline {
  --font-sans: var(--theme-font-sans);
  --font-mono: var(--theme-font-mono);
}

This bridges the gap between the --theme-font-sans variable and Tailwind's own --font-sans token.

Notes

The provided workaround is useful for plugin and theme authors but should be considered temporary until the proper fix is applied. Additionally, there is an undocumented behavior related to setting assets.bg to an empty string, which does not suppress the default Hermes background filler image.

Recommendation

Apply the suggested fix by adding the CSS rule to update Tailwind's font tokens, as this provides a comprehensive solution to the issue and ensures a consistent user experience.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#ssr#installation#API versioning#request timeout

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING