Issue Station
Sign In
Tools hereToolbox

hermes - ✅(Solved) Fix [Bug] Dashboard --tui: xterm.js WebGL renderer garbles Unicode box-drawing characters in Safari [1 pull requests, 3 comments, 2 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#18773•Fetched 2026-05-03 04:54:25
View on GitHub
Comments
3
Participants
2
Timeline
9
Reactions
0
Author
W0921W0921
Participants
Sanjays2402Sanjays2402W0921W0921
Timeline (top)
commented ×3labeled ×3cross-referenced ×1mentioned ×1

When using hermes dashboard --tui and opening the Chat tab in Safari (macOS), the xterm.js terminal renders Unicode box-drawing characters as garbled/broken glyphs. The ASCII art banner (HERMES AGENT logo) and box-drawing UI elements (╔╗║╚╝ etc.) appear as fragmented blocks instead of forming proper shapes.

In Chrome/Firefox, the same page renders correctly.

Root Cause

xterm.js uses WebGL renderer by default, and Safari's WebGL implementation has known compatibility issues with Unicode box-drawing glyphs and custom terminal fonts. This is a well-known problem affecting other projects using xterm.js (VS Code Server, JupyterLab, etc.).

Fix Action

Fixed

PR fix notes

PR #18788: fix(web/dashboard): skip xterm.js WebGL renderer on Safari to fix Unicode box-drawing glyphs

Description (problem / solution / changelog)

Summary

Fixes #18773. In the dashboard Chat tab, Safari's WebGL renderer mangles Unicode box-drawing characters (╔╗║╚╝, ██╗, etc.) used by the HERMES AGENT banner and TUI borders — they fragment into blocks instead of forming proper shapes. Chrome and Firefox WebGL render the same glyphs correctly.

This is a known xterm.js + Safari WebKit interaction (also affects VS Code Server, JupyterLab, etc.).

Fix

web/src/pages/ChatPage.tsx: skip the WebglAddon on Safari and let xterm.js fall back to the default DOM renderer, which renders the box-drawing glyphs faithfully on Safari.

A short isSafariBrowser() helper detects macOS/iOS Safari without false positives on Chromium derivatives:

  • Requires the Safari/ UA token.
  • Excludes Chromium fingerprints (Chrome/, Chromium/, CriOS/) — Chromium-based browsers all advertise Safari/ in their UA for legacy compat.
  • Excludes other WebKit-wrapping shells we know don't hit the bug (FxiOS/, EdgiOS/, Android UAs).

Existing WebGL gate (terminalTierWidthPx(host) >= 768) is preserved, so wide layouts on Chrome/Firefox/Edge still get the crisp WebGL rendering. Only Safari at any width goes to the DOM renderer.

Why not the issue's proposed rendererType: 'dom'?

The proposed new Terminal({ rendererType: 'dom' }) option is from xterm.js v4 and was removed in v5+. The repo is on @xterm/xterm@^6.0.0, where renderer choice is controlled via addons (WebglAddon, CanvasAddon). Skipping the WebglAddon is the modern equivalent.

Verification

  • tsc -b: clean.
  • vite build: clean (1.65s).
  • Diff scope: web/src/pages/ChatPage.tsx only, +38/-1.

What I did NOT change

  • Chrome/Firefox/Edge WebGL path (still active for wide layouts).
  • Mobile/narrow layout fallback (< 768px → DOM renderer; unchanged).
  • The Safari path uses the default DOM renderer, not the canvas addon — adding @xterm/addon-canvas would be a bigger dependency change and the DOM renderer already renders box-drawing correctly on Safari per the issue and xterm.js docs.

cc @bb @W0921

Closes #18773

Changed files

  • web/src/pages/ChatPage.tsx (modified, +38/-1)

Code Example

// web/src/pages/ChatPage.tsx or wherever Terminal is initialized
const terminal = new Terminal({
  rendererType: 'dom',  // or detect Safari
  // ... other options
});
RAW_BUFFERClick to expand / collapse

Summary

When using hermes dashboard --tui and opening the Chat tab in Safari (macOS), the xterm.js terminal renders Unicode box-drawing characters as garbled/broken glyphs. The ASCII art banner (HERMES AGENT logo) and box-drawing UI elements (╔╗║╚╝ etc.) appear as fragmented blocks instead of forming proper shapes.

In Chrome/Firefox, the same page renders correctly.

Environment

  • Hermes Agent version: v0.12.0 (2026.4.30), installed via Nix profile
  • Platform: macOS (Darwin arm64)
  • Browser: Safari (latest)
  • Command: hermes dashboard --tui

Steps to Reproduce

  1. Run hermes dashboard --tui
  2. Open the dashboard in Safari
  3. Navigate to the Chat tab
  4. Observe that the terminal banner and box-drawing characters are garbled

Expected Behavior

Unicode box-drawing characters should render correctly as they do in Chrome/Firefox.

Actual Behavior

Characters like ██╗ ║ ╔╗ ╚╝ etc. fail to form proper shapes — the ASCII art logo and UI borders look broken.

Root Cause

xterm.js uses WebGL renderer by default, and Safari's WebGL implementation has known compatibility issues with Unicode box-drawing glyphs and custom terminal fonts. This is a well-known problem affecting other projects using xterm.js (VS Code Server, JupyterLab, etc.).

Proposed Fix

Add rendererType: 'dom' option when creating the xterm.js Terminal instance, or auto-detect Safari and fall back to the DOM renderer:

// web/src/pages/ChatPage.tsx or wherever Terminal is initialized
const terminal = new Terminal({
  rendererType: 'dom',  // or detect Safari
  // ... other options
});

Alternatively, expose a renderer type toggle in the dashboard settings.

Related

extent analysis

TL;DR

Set the rendererType to 'dom' in the xterm.js Terminal instance to fix the Unicode box-drawing character rendering issue in Safari.

Guidance

  • Verify that the issue is specific to Safari by checking the rendering in other browsers like Chrome or Firefox.
  • Try setting rendererType: 'dom' when creating the xterm.js Terminal instance to see if it resolves the issue.
  • Consider auto-detecting Safari and falling back to the DOM renderer to provide a seamless experience for users.
  • Review the xterm.js documentation on renderer types to understand the implications of changing the renderer type.

Example

const terminal = new Terminal({
  rendererType: 'dom',  
  // ... other options
});

Notes

This fix may have performance implications, as the DOM renderer can be slower than the WebGL renderer. It's essential to test the application's performance after making this change.

Recommendation

Apply the workaround by setting rendererType: 'dom' to ensure proper rendering of Unicode box-drawing characters in Safari, as this is a known compatibility issue with xterm.js and Safari's WebGL implementation.

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#memory leak#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

hermes - ✅(Solved) Fix [Bug] Dashboard --tui: xterm.js WebGL renderer garbles Unicode box-drawing characters in Safari [1 pull requests, 3 comments, 2 participants]