``` This broke the `.replace()` substitution that injects the actual JS code at export time, since the placeholder no longer matched the expected pattern. ## Fix - Collapsed the template placeholders back to single-line format: `` - Added `` comments to prevent the formatter from breaking them again - Added a test to verify placeholders remain on single lines Fixes #68062 ## Changed files - `src/auto-reply/reply/export-html/template.html` (modified, +7/-22) - `src/auto-reply/reply/export-html/template.security.test.ts` (modified, +11/-0) ## Fixed - Fixed by PR: fix: prevent formatter from breaking HTML export template placeholders (#68062) (https://github.com/openclaw/openclaw/pull/68069) ### Bug type Behavior bug (incorrect output/state without crash) ### Beta release blocker No ### Summary ### Summary `/export` can produce an HTML file that clearly contains the exported session data, but when the file is opened in a browser, the conversation area renders empty (or appears blank), even though the embedded payload is present. This looks like an export viewer / template rendering bug rather than an export-data-loss bug. ### Environment - Version: v2026.4.14 - Exported file path example: `~/.openclaw/workspace/openclaw-session-26d2ebb0-2026-04-17T08-29-23.html` ### Reproduction 1. Run a normal conversation in OpenClaw 2. Use `/export` 3. Open the generated HTML file in a browser 4. In some cases, the page shell loads, but the conversation content is empty ### Expected behavior The exported HTML should render the conversation content that was exported. ### Actual behavior The generated HTML file is non-empty and contains embedded session data, but the viewer renders no visible conversation content. ### What I checked The exported HTML file is not empty: - file size was ~111 KB - HTML/CSS/template content is present - the file contains a `` payload Decoding the embedded payload shows valid exported session data, for example: - `header.version = 3` - `entries = 9` - includes multiple `message` entries So this does **not** appear to be a failure to export the session data itself. The data is present in the HTML; the issue seems to be in the export viewer's rendering logic. ### Likely cause From inspecting `dist/export-html/template.js`, there appear to be at least two likely compatibility issues: 1. **`leafId` is trusted without validation** - the viewer uses `urlLeafId || defaultLeafId` - if that leaf id is present but no longer valid / not present in `entries`, navigation can resolve to an empty path - this can produce an apparently blank conversation area instead of falling back to a real leaf node 2. **`custom` entries may not be rendered** - exported data can contain `entry.type === \"custom\"` - `renderEntry()` handles `custom_message` but not `custom` - this may not fully explain a completely blank page, but it looks like another format-compatibility gap in the export viewer ### Suggested fix - Validate `leafId` before using it - If the requested/default leaf is missing, fall back to a real reachable leaf node from `entries` - Add rendering support for `entry.type === \"custom\"` (or otherwise handle it gracefully) ### Notes This seems separate from other session-export / transcript-collection issues, because the session payload is already embedded in the generated HTML and can be decoded successfully. ### Steps to reproduce 1. Run a normal conversation in OpenClaw (v2026.4.14) 2. Use `/export` 3. Open the generated HTML file in a browser 4. In some cases, the page shell loads, but the conversation content is empty ### Expected behavior The exported page should present the conversation content. ### Actual behavior The exported page is empty. ### OpenClaw version 2026.4.14 ### Operating system Ubuntu 24.04 ### Install method _No resp","inLanguage":"en-US","datePublished":"2026-04-17T09:47:36Z","dateModified":"2026-04-17T09:47:36Z","mainEntityOfPage":{"@type":"WebPage","@id":"https://www.stepcodex.com/en/issue/bug-export-sometimes-generates-html-that"},"author":{"@type":"Person","name":"wzhgba","url":"https://github.com/wzhgba","image":"https://github.com/wzhgba"},"publisher":{"@type":"Organization","name":"StepCodex","url":"https://www.stepcodex.com"},"articleSection":"openclaw","about":[{"@type":"Thing","name":"openclaw","url":"https://www.stepcodex.com/en/category/openclaw"}],"keywords":"[Bug]: /export sometimes generates HTML that contains session data but renders an empty conversation view, openclaw, how to fix, fix, troubleshooting, root cause, solution, StepCodex","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/LikeAction","userInteractionCount":4}},{"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://www.stepcodex.com/en/issue"},{"@type":"ListItem","position":2,"name":"openclaw","item":"https://www.stepcodex.com/en/category/openclaw"},{"@type":"ListItem","position":3,"name":"[Bug]: /export sometimes generates HTML that contains session data but renders an empty conversation view","item":"https://www.stepcodex.com/en/issue/bug-export-sometimes-generates-html-that"}]},{"@context":"https://schema.org","@type":"FAQPage","mainEntity":[{"@type":"Question","name":"Expected behavior","acceptedAnswer":{"@type":"Answer","text":"The exported page should present the conversation content."}}]}]

openclaw - ✅(Solved) Fix [Bug]: /export sometimes generates HTML that contains session data but renders an empty conversation view [1 pull requests, 1 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
openclaw/openclaw#68062Fetched 2026-04-18 05:54:10
View on GitHub
Comments
0
Participants
1
Timeline
5
Reactions
0
Author
Participants
Timeline (top)
labeled ×2closed ×1cross-referenced ×1referenced ×1

/export can produce an HTML file that clearly contains the exported session data, but when the file is opened in a browser, the conversation area renders empty (or appears blank), even though the embedded payload is present.

This looks like an export viewer / template rendering bug rather than an export-data-loss bug.

Root Cause

This seems separate from other session-export / transcript-collection issues, because the session payload is already embedded in the generated HTML and can be decoded successfully.

Fix Action

Fixed

PR fix notes

PR #68069: fix: prevent formatter from breaking HTML export template placeholders (#68062)

Description (problem / solution / changelog)

Problem

The /export command generates HTML that contains session data in the embedded payload, but when opened in a browser the conversation area renders blank.

Root Cause

The code formatter (oxfmt) was reformatting the template placeholders like {{MARKED_JS}} into multi-line blocks:

<script>
  {
    {
      MARKED_JS;
    }
  }
</script>

This broke the .replace() substitution that injects the actual JS code at export time, since the placeholder no longer matched the expected pattern.

Fix

  • Collapsed the template placeholders back to single-line format: <script>{{MARKED_JS}}</script>
  • Added <!-- oxfmt-ignore --> comments to prevent the formatter from breaking them again
  • Added a test to verify placeholders remain on single lines

Fixes #68062

Changed files

  • src/auto-reply/reply/export-html/template.html (modified, +7/-22)
  • src/auto-reply/reply/export-html/template.security.test.ts (modified, +11/-0)
RAW_BUFFERClick to expand / collapse

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

Summary

/export can produce an HTML file that clearly contains the exported session data, but when the file is opened in a browser, the conversation area renders empty (or appears blank), even though the embedded payload is present.

This looks like an export viewer / template rendering bug rather than an export-data-loss bug.

Environment

  • Version: v2026.4.14
  • Exported file path example: ~/.openclaw/workspace/openclaw-session-26d2ebb0-2026-04-17T08-29-23.html

Reproduction

  1. Run a normal conversation in OpenClaw
  2. Use /export
  3. Open the generated HTML file in a browser
  4. In some cases, the page shell loads, but the conversation content is empty

Expected behavior

The exported HTML should render the conversation content that was exported.

Actual behavior

The generated HTML file is non-empty and contains embedded session data, but the viewer renders no visible conversation content.

What I checked

The exported HTML file is not empty:

  • file size was ~111 KB
  • HTML/CSS/template content is present
  • the file contains a <script type="application/json">...</script> payload

Decoding the embedded payload shows valid exported session data, for example:

  • header.version = 3
  • entries = 9
  • includes multiple message entries

So this does not appear to be a failure to export the session data itself. The data is present in the HTML; the issue seems to be in the export viewer's rendering logic.

Likely cause

From inspecting dist/export-html/template.js, there appear to be at least two likely compatibility issues:

  1. leafId is trusted without validation

    • the viewer uses urlLeafId || defaultLeafId
    • if that leaf id is present but no longer valid / not present in entries, navigation can resolve to an empty path
    • this can produce an apparently blank conversation area instead of falling back to a real leaf node
  2. custom entries may not be rendered

    • exported data can contain entry.type === "custom"
    • renderEntry() handles custom_message but not custom
    • this may not fully explain a completely blank page, but it looks like another format-compatibility gap in the export viewer

Suggested fix

  • Validate leafId before using it
  • If the requested/default leaf is missing, fall back to a real reachable leaf node from entries
  • Add rendering support for entry.type === "custom" (or otherwise handle it gracefully)

Notes

This seems separate from other session-export / transcript-collection issues, because the session payload is already embedded in the generated HTML and can be decoded successfully.

Steps to reproduce

  1. Run a normal conversation in OpenClaw (v2026.4.14)
  2. Use /export
  3. Open the generated HTML file in a browser
  4. In some cases, the page shell loads, but the conversation content is empty

Expected behavior

The exported page should present the conversation content.

Actual behavior

The exported page is empty.

OpenClaw version

2026.4.14

Operating system

Ubuntu 24.04

Install method

No response

Model

minimax-m2,7

Provider / routing chain

openclaw -> openrouter -> minimax-m2.7

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

No response

extent analysis

TL;DR

Validate leafId and add rendering support for entry.type === "custom" to fix the export viewer rendering bug.

Guidance

  • Validate leafId before using it to prevent navigation from resolving to an empty path.
  • If the requested/default leaf is missing, fall back to a real reachable leaf node from entries.
  • Add rendering support for entry.type === "custom" to handle custom entries correctly.
  • Review the renderEntry() function to ensure it handles all possible entry types, including custom.

Example

No code snippet is provided as the issue does not contain enough information to create a specific example.

Notes

The issue seems to be related to the export viewer's rendering logic, and the suggested fix should resolve the problem. However, without more information about the codebase, it's difficult to provide a more detailed solution.

Recommendation

Apply the suggested fix by validating leafId and adding rendering support for entry.type === "custom", as this should resolve the export viewer rendering bug.

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…

FAQ

Expected behavior

The exported page should present the conversation content.

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - ✅(Solved) Fix [Bug]: /export sometimes generates HTML that contains session data but renders an empty conversation view [1 pull requests, 1 participants]