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
- Open
http://localhost:9119 in any modern browser.
- Focus the chat input pane.
- Type or paste:
حبيت فعلا
- 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)
- 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).
- Or ship a Unicode BiDi addon for xterm.js (there is community work toward this — see xtermjs/xterm.js BiDi RFCs).
- 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.
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
localhost:9119claude-proxy → http://localhost:3456/v1(Anthropic Claude)ar-SA/ar-EG(tested both); also reproduced with browser locale set toen-US.Reproduction
http://localhost:9119in any modern browser.حبيت فعلا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
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)
contenteditablediv withunicode-bidi: plaintextwould just work).--http-onlymode 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.