[Bug][Kimi Desktop] Windows 3.0.7 generated PDF preview downloads viewer.html because the PDF.js wrapper is served with Content-Disposition: attachment

Routing note

I am reporting this here because I could not find an active public MoonshotAI issue tracker specifically for Kimi Desktop / Kimi Web. I understand this repository is primarily for Kimi Code CLI. If this is not the right tracker, please route this to the Kimi Desktop, Kimi Web, or CDN/static-assets team.

Summary

Kimi Desktop for Windows 3.0.7 cannot preview generated PDFs inline.

When opening a generated PDF preview, the desktop app navigates to the Kimi PDF.js wrapper:

https://statics.moonshot.cn/kimi-web-seo/pdf/v5/pdfjs-viewer/viewer.html

However, that wrapper HTML is currently served with:

content-type: text/html
content-disposition: attachment

Because of Content-Disposition: attachment, Chromium/Electron opens a Save dialog for viewer.html instead of rendering the PDF.js viewer inline.

Impact

• Generated PDF preview is effectively broken in Kimi Desktop on Windows.
• The failure is visible to end users as an unexpected Save dialog for viewer.html.
• The bug affects the preview flow itself, not one specific generated PDF file.
• It creates a poor UX because users cannot inspect generated reports/documents in the expected inline preview panel.

Environment

• Product: Kimi Desktop for Windows
• Version: 3.0.7
• Verified executable metadata: FileVersion=3.0.7, ProductVersion=3.0.7.0
• OS: Windows 11
• Preview target: generated PDF from Kimi
• Browsers tested during troubleshooting: Microsoft Edge and Google Chrome
• WebBridge tested: installed, running, and connected
• Observed WebBridge status during troubleshooting: running=true, extension_connected=true
• Local app package: not patched
• Repro date: 2026-05-01

Reproduction steps

1. Install or update Kimi Desktop for Windows to 3.0.7.
2. Open Kimi Desktop.
3. Generate or open a Kimi-produced PDF file.
4. Click the file preview action inside Kimi Desktop.
5. Kimi Desktop attempts to open a URL matching:

https://statics.moonshot.cn/kimi-web-seo/pdf/v5/pdfjs-viewer/viewer.html?file=...

6. Instead of showing the PDF preview inline, Windows shows a Save dialog for viewer.html.

Expected behavior

Kimi Desktop should render the generated PDF inside the inline preview panel using PDF.js or an internal sandboxed preview flow.

The PDF.js wrapper HTML should be served inline, for example:

Content-Disposition: inline

or without a Content-Disposition header.

Actual behavior

The app downloads viewer.html instead of rendering the preview.

This prevents generated PDFs from being previewed inside Kimi Desktop.

Evidence

The failing viewer route is independently reproducible with a header check. This does not require the original private generated PDF URL to demonstrate the misconfigured wrapper asset.

A direct HEAD request to the wrapper returns:

HTTP/2 200
content-type: text/html
content-disposition: attachment

Full observed header sample:

server: Byte-nginx
content-type: text/html
content-length: 44753
content-disposition: attachment
last-modified: Thu, 30 Apr 2026 09:35:17 GMT
cache-control: max-age=2592000
access-control-allow-origin: *

The key issue is that the PDF.js viewer HTML itself is marked as an attachment.

Root-cause hypothesis

This appears to be a static asset/CDN metadata issue rather than a client-side Desktop or browser issue.

• The viewer URL is a Kimi/Moonshot static asset under statics.moonshot.cn/kimi-web-seo/pdf/v5/pdfjs-viewer/viewer.html.
• The asset is served by CDN/object-storage infrastructure with Content-Disposition: attachment.
• Embedded Chromium/Electron follows the server-provided disposition and starts a download instead of rendering the HTML viewer.
• Changing Edge, Chrome, WebBridge, local PDF associations, or local cache does not change the server response header.

Most likely implementation-level causes:

• The object metadata for viewer.html was uploaded with Content-Disposition: attachment.
• The CDN rule for this path or bucket applies attachment disposition too broadly.
• A static publishing/deployment script may be setting download disposition for generated/static artifacts without excluding trusted viewer HTML assets.

Troubleshooting already performed

The issue persists after:

• Updating/reinstalling Kimi Desktop to 3.0.7.
• Restarting Kimi Desktop.
• Restarting browsers.
• Testing with Microsoft Edge.
• Testing with Google Chrome.
• Installing and validating Kimi WebBridge.
• Confirming WebBridge is running and connected.
• Checking local browser/default PDF handling.
• Checking local cache/session behavior.
• Testing across restarts and multiple sessions.
• Attempting a browser-extension redirect workaround.

No app.asar patch or unsafe local modification was applied.

Why this appears to be server-side

The problematic header is returned by Moonshot/Kimi static infrastructure for the PDF.js wrapper URL itself.

A client-side browser setting, Edge/Chrome profile, WebBridge extension, Windows PDF association, or local cache does not normally override a server-sent Content-Disposition: attachment header during embedded Chromium/Electron navigation.

Requested fix

Please update the CDN/static asset configuration for:

/kimi-web-seo/pdf/v5/pdfjs-viewer/viewer.html

so the HTML viewer is not served with:

Content-Disposition: attachment

Preferred fix:

Content-Disposition: inline

or omit the header entirely.

Alternative fix:

Route generated PDFs through an internal sandboxed Kimi Desktop preview flow that does not depend on a CDN-served wrapper marked as an attachment.

Suggested implementation options

1. CDN/object metadata fix: remove Content-Disposition: attachment for the trusted PDF.js viewer HTML route and serve it as inline HTML.
2. Static publishing fix: update the asset upload/deploy pipeline so PDF.js viewer assets preserve Content-Type: text/html without download disposition.
3. Desktop preview architecture fix: bundle or route the PDF.js viewer through an internal Kimi Desktop preview panel, then pass the generated PDF URL into that sandboxed viewer.
4. Regression guard: add an automated check that /kimi-web-seo/pdf/v5/pdfjs-viewer/viewer.html does not return Content-Disposition: attachment.

Security note

The requested fix is not to inline arbitrary user-generated HTML. The safer scope is to serve only the trusted PDF.js viewer wrapper inline, while continuing to sandbox generated documents and untrusted content appropriately.

Acceptance criteria

• HEAD /kimi-web-seo/pdf/v5/pdfjs-viewer/viewer.html no longer returns Content-Disposition: attachment.
• Kimi Desktop Windows opens generated PDF previews inside the intended inline preview panel.
• No Save dialog for viewer.html appears when using the generated PDF preview action.
• Generated PDF preview works after restarting Kimi Desktop and across a fresh session.
• WebBridge/browser extension state is not required for the PDF preview to render correctly unless intentionally part of the product design.

Suggested regression tests

• CDN/header test: assert the viewer HTML route is served inline.
• Desktop integration test: click a generated PDF preview and assert no download event for viewer.html is emitted.
• PDF.js smoke test: assert the preview panel renders the first page or at least initializes the PDF.js viewer shell.
• Security regression test: verify untrusted generated HTML is still sandboxed and not blindly rendered with elevated Desktop privileges.

Questions

1. Is this a known Kimi Desktop Windows 3.0.7 issue?
2. Is the Content-Disposition: attachment header intentional for this PDF.js viewer route?
3. Is there a newer Desktop build, beta build, feature flag, or server-side rollout that fixes this?
4. Where should Desktop/Web preview bugs be reported publicly in the future?

Start by checking the reported HEAD response for https://statics.moonshot.cn/kimi-web-seo/pdf/v5/pdfjs-viewer/viewer.html and confirm whether Content-Disposition is still attachment. No repository file, test, or entry point is identified; the issue is done when the trusted viewer route is served inline and Kimi Desktop no longer downloads viewer.html during PDF preview.