Web/PWA: bold and heading text render at the same font weight/size as regular text (markdown parsed, no visual emphasis)

[temporaryna]

What version of HAPI is running?

0.29.0

What platform is your computer?

Darwin 24.6.0 arm64 arm

What issue are you seeing?

In the web/PWA chat view, markdown bold in agent replies is parsed — the asterisks are stripped — but the text renders at the same font weight as regular text. There is no visual emphasis at all; a bold word is indistinguishable from the surrounding text. Markdown headings (###) are affected too: they render at the same size/weight as body text instead of being larger/bolder. Reproduced in the PWA on Android Chrome and in a desktop browser against a self-hosted hub.

What steps can reproduce the bug?

1. Start a hapi-wrapped Claude Code session (hapi), open the same session in the web UI / PWA.
2. Send this prompt:

Reply with exactly one message following the template below, no intro, no explanations:

A plain baseline line.

A line with a **bold word** inside.

A line with an *italic word* inside.

A line with `inline code` inside.

**An entire fully bold line.**

Mixed: plain **bold** plain *italic* plain `code` plain.

- list: **bold item**
- plain item

### Mini heading

> A quote with a **bold** word.

3. Compare the reply in the terminal vs the web/PWA chat view.

Terminal (bold is visibly bold):

Web/PWA (bold looks identical to plain text; asterisks are gone):

What is the expected behavior?

Bold renders with a heavier font weight, as it does in the terminal UI. Markdown parsing already works (asterisks are stripped), so only the visual styling for strong/bold appears to be missing.

Additional information

The asterisks being stripped suggests the markdown parser runs — the issue looks purely presentational. Headings are confirmed flat as well (see screenshots: ### Mini heading renders like a plain line), so the problem seems to be that message typography in general has no visual hierarchy; bold is just the most obvious case.

[github-actions]

Thanks for the detailed reproduction. I checked the v0.29.0 source: assistant Markdown is parsed through custom components, and bold is explicitly intended to render with font-semibold; italic uses italic, while headings use their own size plus font-semibold. Those components are registered in the component map used by assistant replies.

So this is not explained by a missing strong/em/heading mapping in the v0.29.0 source. The exact cause was not found from repository inspection alone; browser computed styles and font resolution are needed to identify where the intended styling is being lost.

Relevant code:

• web/src/components/assistant-ui/markdown-text.tsx:807 - heading components apply explicit sizes and font-semibold.
• web/src/components/assistant-ui/markdown-text.tsx:831 - the strong component applies font-semibold; the adjacent em component applies italic.
• web/src/components/assistant-ui/markdown-text.tsx:851 - registers those elements in the Markdown component map used by assistant messages.
• web/src/components/assistant-ui/markdown-text.tsx:883 - assistant reply Markdown uses that component map.
• web/src/index.css:451 - sets chat Markdown color, font size, and line height, without an obvious rule resetting weight or style.

Need more info:

• Please attach the actual terminal and web/PWA screenshots; the issue currently contains placeholders.
• In desktop DevTools, please copy the bold element’s HTML plus its computed font-weight and font-family, and the same two computed values from adjacent plain text.
• Do other font-semibold UI elements, such as page/session headings, also look the same as normal text?
• What exact desktop browser/version and Android Chrome version reproduce this?

---

HAPI Bot

[temporaryna]

Thanks for the deep dive. Answers:

1. Screenshots — they are attached in the issue body (terminal + Android PWA); added shortly after creation, so the earlier comment may have been based on a previous revision. Two more phone screenshots (dark OLED theme, Chrome + Vivaldi) will be attached to this comment.

2. Computed styles — probed the same self-hosted hub with headless Chromium (Playwright 1.61, macOS) on a session whose assistant reply contains **bold**, ### heading and mixed formatting:

element	font-weight	font-size
<strong> ("bold word")	600	15px
parent <p> (plain text)	400	15px
<h3> ("Mini heading")	600	15.2px

On desktop Chromium the font-semibold styling is applied (600 vs 400). The flat rendering reproduces on Android — confirmed identical in both Chrome and Vivaldi on the same device (Vivaldi with an OLED dark theme, Chrome with its default theme — same result), so it is neither browser- nor theme-specific.

Vivaldi (Android, OLED dark — bold is flat):

Chrome (Android, same device, default theme — identical):

Correction to the original report: the desktop-browser repro was not visually confirmed by a human — the desktop numbers above are from headless Chromium 141 via Playwright; the visually confirmed repro is Android (Chrome + Vivaldi).

3. On Android the failure is specifically a font-weight one. On a dark OLED theme the only line that stands out at all is the blockquote, and only because of color — the bold fragment renders slightly whiter than the greyer surrounding text (blockquote color styling, not weight). In plain paragraphs everything is pixel-identical. So font-weight: 600 appears visually indistinguishable from 400 on this device — most likely the resolved system font has no 600 face and the engine doesn't synthesize one.

4. Guess: would switching assistant strong/heading styles to 700 / font-weight: bold make this robust across system fonts? Probably worth a quick check on a couple of Android devices — if 600 is unreliable there, it affects every mobile user reading bold agent replies.

[temporaryna]

Following up with a design suggestion that mirrors how the CLI renders this: in the terminal, regular text is slightly muted (grey) while bold is both brighter/whiter and heavier — that combination is what makes emphasis instantly readable.

Applying the same idea to chat markdown would also make emphasis robust on devices where font weight can't render (like the Android above — color still works when 600 doesn't):

/* chat markdown: terminal-like emphasis */
.chat-markdown { color: <muted-foreground>; }                    /* regular text slightly grey */
.chat-markdown strong { color: <foreground>; font-weight: 700; } /* bold: brighter + heavier */

So the full proposal: 700 for weight plus a muted-body/bright-strong color pair — 1:1 with the terminal look this report compares against, and immune to missing font faces on mobile.