WebUI Markdown preview fails/hangs on large PRD markdown files while local macOS editors can open them

Bug description

Hermes WebUI appears unable to open or render a large Markdown document that is otherwise valid UTF-8 and readable by local macOS editors. The same content becomes readable in Hermes when split into smaller Markdown files, which suggests the problem is likely in WebUI/browser-side Markdown preview/rendering for large documents rather than file corruption.

Repository

NousResearch/hermes-agent

Environment

• Host OS: macOS 26.4.1
• Interface: Hermes WebUI / browser-based chat interface
• Workspace: /Users/Ravenlei/Desktop/AIZC
• Hermes profile in use: aizc
• File type: Markdown .md
• Approx file size: 228,807 bytes
• Approx line count: 3,714 lines
• Approx character count: 107,278 chars
• Document characteristics:
  • Chinese text-heavy PRD
  • Many headings: 252 headings
  • Many Markdown tables
  • Multiple fenced code blocks
  • Longest line observed: 337 chars

Steps to reproduce

1. In Hermes WebUI, create or select a workspace containing a large Markdown document.
2. Try to open/preview a Markdown file around this size/shape:
   • ~229 KB
   • ~3.7k lines
   • Chinese text
   • many headings/tables
3. Hermes WebUI fails to open/render the file or becomes unusable for that file.
4. Open the same file in a local macOS editor/Finder-associated editor: it opens normally.
5. Split the same Markdown file into smaller per-section files and open those in Hermes WebUI: the split files open normally.

Expected behavior

Hermes WebUI should be able to open or safely preview large Markdown files, or at minimum degrade gracefully, for example:

• show raw text instead of full rendered Markdown when size exceeds a threshold;
• paginate/virtualize Markdown rendering;
• display a clear warning like “file too large for rich preview; open as plain text or split into sections”;
• avoid hanging/failing silently.

Actual behavior

The full large Markdown file cannot be opened in Hermes WebUI, while:

• the same file is valid UTF-8;
• local macOS editors can open it;
• split Markdown files open in Hermes;
• short/medium Markdown files open normally.

Diagnostics already performed

The file was checked from the terminal:

exists True
size 228807
nul_count 0
utf8 OK chars 107278 lines 3714
max_line_len 337
fences 30 even True
bad_ctrl 0
headings 252
many_pipe_lines [] count 0
html_comments_open 0 close 0

Additional checks:

• UTF-8 decoding succeeds.
• No NUL bytes.
• No unusual control characters.
• Markdown fenced code blocks are balanced.
• Local open -R / Finder reveal succeeds.
• macOS local editor can open the document.
• A split version of the same document opens in Hermes WebUI.

Workaround

Split the large Markdown document into smaller files, e.g.:

hxz-prd-lite-v0.4.14.md
hxz-prd-main-v0.4.14.md
hxz-prd-appendix-functional-v0.4.14.md
hxz-prd-appendix-data-model-v0.4.14.md
hxz-prd-appendix-agent-workflow-v0.4.14.md
hxz-prd-appendix-trust-security-v0.4.14.md
hxz-prd-appendix-learning-v0.4.14.md

This strongly suggests the issue is size/rendering-related rather than data corruption.

Suggested fix ideas

1. Add a file-size / line-count threshold for rich Markdown preview.
2. If a Markdown file exceeds the threshold, default to plain-text preview or ask the user whether to render rich Markdown.
3. Use virtualized rendering for large Markdown documents.
4. Add graceful error handling if Markdown rendering fails or takes too long.
5. Consider showing a “split large document” helper or partial preview with pagination.

Impact

This affects PRD/spec/document-heavy workflows. Hermes is often used for generating long Markdown documents, and users may assume the generated file is corrupt when the issue is actually WebUI preview/rendering capacity.