hermes - 💡(How to fix) Fix Web dashboard: Arabic text in chat pane renders LTR with disconnected letters (no BiDi / no shaping)

Summary

When typing Arabic text in the Hermes Web Dashboard chat pane (the Xterm.js-style terminal at localhost:9119), the text is rendered left-to-right and letters are disconnected — i.e., no Unicode BiDi algorithm and no Arabic letter-joining/shaping is applied.

This makes Hermes Web unusable for Arabic-speaking operators (right-to-left scripts: Arabic, Persian, Urdu, Hebrew, etc.).

Versions / environment

• Hermes Agent: 0.14.0 (Python 3.12.13, macOS 14 Sequoia)
• Browser: Comet (Chromium-based, latest)
• Web dashboard: localhost:9119
• Gateway provider: claude-proxy → http://localhost:3456/v1 (Anthropic Claude)
• Locale: ar-SA / ar-EG (tested both); also reproduced with browser locale set to en-US.

Reproduction

1. Open http://localhost:9119 in any modern browser.
2. Focus the chat input pane.
3. Type or paste: حبيت فعلا
4. Submit (or even just look at the input box).

Expected

The Arabic phrase renders right-to-left with joined glyphs, like a normal Arabic text editor:

حبيت فعلا

Actual

The phrase renders left-to-right with each letter disconnected (no Arabic shaping/joining applied):

ا ل ع ف   ت ي ب ح

Mixed Arabic + English + digits (e.g. المشروع SFG-V2 يحتوي 28000 إيميل) shows the same problem — the Latin tokens float in LTR order in the middle of an LTR-rendered Arabic string instead of being embedded inside a BiDi paragraph.

Root cause (likely)

The chat pane appears to use Xterm.js as the renderer. Xterm.js historically does not ship a Unicode BiDi algorithm or Arabic letter-joining/shaping tables. There is an open xtermjs/xterm.js#1408 / #2208 family of issues tracking this.

So the dashboard inherits Xterm.js' Latin-only assumptions.

Impact

• Arabic operators cannot use the Hermes Web Dashboard chat as a working interface at all.
• Workaround we are using downstream: bypass the web chat and call POST localhost:8642/v1/chat/completions (OpenAI-compatible) directly from a native HTML <textarea dir="auto" lang="ar" style="font-family: 'Cairo', 'Noto Naskh Arabic'; unicode-bidi: plaintext"> — that works correctly because the browser's CSS pipeline handles BiDi + shaping out of the box.

Suggested fixes (any of these helps)

1. Replace Xterm.js with a BiDi-capable web terminal for the chat pane (xterm.js does not currently expose a BiDi shim — alternative renderers like CodeMirror 6 or Monaco have BiDi support, or a simple contenteditable div with unicode-bidi: plaintext would just work).
2. Or ship a Unicode BiDi addon for xterm.js (there is community work toward this — see xtermjs/xterm.js BiDi RFCs).
3. Or document the limitation prominently in the README and offer an --http-only mode that hides the web chat in favor of pointing users at the HTTP API.

Repro artifacts

I have a side-by-side screenshot (1100×1300 @2x) showing the broken Xterm.js rendering next to a native <textarea dir="auto"> rendering the same Arabic correctly — happy to share if helpful. Just say the word and I'll attach.

Acknowledgement

Hermes Agent has been excellent for our Arabic + English logistics workflows on the HTTP API path (:8642) — the only blocker was that operators have to use a native client instead of the bundled web UI. Thanks for considering.

Filed by a Hermes user downstream (Saudi NIT logistics) — happy to test a fix in a feature branch if useful.