[BUG] Files downloaded via Claude Desktop are always tagged with Mark-of-the-Web (Zone.Identifier), requiring manual "Unblock" in every case

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Every file downloaded through Claude Desktop on Windows 11 is saved with the NTFS Zone.Identifier alternate data stream (Mark-of-the-Web), causing Windows to flag the file as "blocked." This requires manually opening File Properties and ticking "Unblock" for every single downloaded file, regardless of save location. This occurs across multiple different save locations on the same NTFS-formatted primary internal SSD, so it isn't specific to one folder or drive.

I previously resolved this by setting the registry value SaveZoneInformation to 1 (disable zone info saving) under:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Attachments

The fix stopped working after some period of time (exact trigger unknown — possibly a Claude Desktop update, given Claude Desktop bundles its own Electron/Chromium runtime independent of Windows/IE-based download handling that this registry policy was designed for). I have confirmed the registry value is still correctly set to 0x00000001 (1) at the correct path, so the recurrence is not due to the registry setting being reverted.

What Should Happen?

Files downloaded via Claude Desktop should either:

• Not be tagged with Zone.Identifier when saved to a local, trusted directory chosen by the user, or
• Respect the standard Windows SaveZoneInformation attachment policy the way other Windows-integrated download paths do, so users who've explicitly disabled zone tagging via registry/policy have that respected consistently across Claude Desktop versions.

Error Messages/Logs

None — no error dialogue is shown. The only visible symptom is the "This file came from another computer and might be blocked to help protect this computer" notice in File Properties, with the "Unblock" checkbox present.
Claude diagnostics file uploaded to the *Additional Information* section.

Steps to Reproduce

1. On Windows 11 Home (build 26200), open Claude Desktop.
2. Have Claude generate/create a file and download it (or use the in-app download/export feature) to any local folder on the primary NTFS SSD.
3. Right-click the downloaded file → Properties → General tab.
4. Observe the "Unblock" checkbox is present, and the file is flagged as blocked, even though HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Attachments\SaveZoneInformation is set to 1.

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Claude for Windows version 1.24012.9 (03c61d) 2026-07-24T04:59:17.000Z

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Non-interactive/CI environment

Additional Information

• This is likely related to Claude Desktop's bundled Electron/Chromium download handling writing the Zone.Identifier ADS stream directly, rather than going through the legacy Windows Attachment Manager path that SaveZoneInformation governs — meaning this registry policy may never reliably control Claude Desktop's download behavior.
• A related but distinct issue (#67839) reports the opposite symptom — a downloaded .mcpb extension bundle missing its Zone.Identifier stream entirely on Claude Desktop 1.12603.1, with downgrading to 1.11847.5 resolving it. This suggests Claude Desktop's MOTW-tagging behavior has been inconsistent across recent versions, which may be relevant context for whoever investigates this.
• Happy to provide Process Monitor traces of the download/write operation if that would help diagnose which component is writing the stream.
• Windows: 11 Home, build 10.0.26200.26200
• Claude diagostic file uploaded.

claude-diagnostic-3153f9c0-20260730-2315.zip