›_ Claude Code Issues
Claude Code Issues / #77434

Windows: Cowork HTML preview pane ignores <style> blocks (inline style attributes work, text renders unstyled)

Open 💬 0 comments Opened Jul 14, 2026 by wataru20

Environment

  • App: Claude Desktop for Windows, Cowork file preview pane (the side panel that renders HTML files created during a Cowork session)
  • Observed: 2026-07-14, on an up-to-date install (exact build number not available — reported on behalf of a colleague's Windows machine)
  • Comparison: the exact same file renders correctly (fully styled) in the Cowork preview pane on macOS, and in any regular browser (double-clicking the file) on the same Windows machine

Summary

On Windows, the Cowork HTML preview pane renders the document text but ignores all CSS rules defined in <style> blocks. Inline style="..." attributes are applied. So the pane shows unstyled plain-looking text instead of the styled document.

Minimal reproduction

Ask Cowork (on Windows) to create the following file and display it in the side preview pane:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>Style block test</title>
  <style>
    body { background: #f4f6fb; }
    h1 { color: blue; }
    .box { border: 2px solid red; padding: 8px; }
  </style>
</head>
<body>
  <h1>Heading (should be blue)</h1>
  <div class="box">Box (should have a red border)</div>
  <p style="color: green;">Inline style (should be green)</p>
</body>
</html>

Expected

Blue heading, red-bordered box, green paragraph — as rendered by the macOS preview pane and by any browser.

Actual (Windows preview pane)

  • Heading and box render as plain unstyled text (the <style> block has no effect — verified with a single-rule <style> block as well)
  • The green paragraph is green (inline style attribute works)
  • The same file double-clicked into a browser on the same machine renders fully styled

This combination (text preserved, <style> blocks dropped, inline style attributes kept) looks like an HTML sanitization step in the Windows rendering path that strips <style> elements.

Secondary observation (possibly related to the same code path)

If the file has no <meta charset> declaration, the Windows preview pane decodes UTF-8 multibyte text as windows-1252 (e.g. Japanese text renders as テスト), even on a Japanese-locale system where browsers would typically sniff or fall back differently. With <meta charset="UTF-8"> present, text decodes correctly. This is minor on its own, but it suggests the Windows pane processes the raw HTML through a different pipeline than macOS.

Not duplicates (checked before filing)

  • #33499 — preview pane fully blank on macOS (text doesn't render either; different symptom)
  • #71604 — external stylesheet <link> not loading via file:// (my repro uses only an inline <style> block)
  • #26454 — the app's own UI losing styles after Cowork↔chat switching (this report is about user-generated HTML files in the preview pane)

View original on GitHub ↗