# MSIX vs Zipped Version of Claude Desktop on Windows - caused Cdata MCP failures

**URL:** <https://community.cdata.com/t/msix-vs-zipped-version-of-claude-desktop-on-windows-caused-cdata-mcp-failures/1340>\
**Category:** CData Drivers\
**Tags:** mcp-server, windows-apps, msix, claude-desktop, zipped-version, claude, mcp-failures, msix-vs-zip, msix-issues, windows-mcp, discussion\
**Created:** [October 15, 2026, 1:24pm UTC](https://community.cdata.com/t/msix-vs-zipped-version-of-claude-desktop-on-windows-caused-cdata-mcp-failures/1340 "2026-10-15T13:24:04Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![njoffe](https://avatars.discourse-cdn.com/v4/letter/n/ebca7d/32.png) [@njoffe](https://community.cdata.com/u/njoffe)\
**Post date:** [October 15, 2026, 1:24pm UTC](https://community.cdata.com/t/msix-vs-zipped-version-of-claude-desktop-on-windows-caused-cdata-mcp-failures/1340/1 "2026-10-15T13:24:05Z")

</div>

I installed the&nbsp;[CDataSoftware/cdata-jdbc-mcp-server](https://github.com/CDataSoftware/cdata-jdbc-mcp-server)&nbsp;from Github and attempted to query an excel&nbsp;spreadsheet on my Windows 11 laptop.

At one point, I had installed the MSIX version of Claude.&nbsp;Then later, installed the zipped version of Claude. When I launched Claude, the Cdata MCP server connected, then immediately disconnected. The failure trace pointed to an unescaped unicode character. I checked the .json and .prp file and there were no errors.

I killed all the Claude tasks, uninstalled Claude&nbsp;and re-installed just the zipped version of Claude. This worked. The MCP launched and I was able to query the excel spreadsheet.

I’m not sure MSIX installs&nbsp;are&nbsp;going to change the instructions for users experimenting with Cdata connectors. Thank you!

---

<div class="post-metadata">

**Author:** ![Mohsin578](https://sea3.discourse-cdn.com/cdata/user_avatar/community.cdata.com/mohsin578/32/2194_2.png) [@Mohsin578](https://community.cdata.com/u/Mohsin578)\
**Post date:** [November 6, 2026, 6:22pm UTC](https://community.cdata.com/t/msix-vs-zipped-version-of-claude-desktop-on-windows-caused-cdata-mcp-failures/1340/2 "2026-11-06T18:22:23Z")

</div>

Interesting find! It seems the issue may be related to how the MSIX and ZIP versions handle application paths or environment settings. Reinstalling the ZIP version was a useful workaround. It would be worth checking whether the MCP server configuration references the correct Claude installation path, especially when switching between installation types. Thanks for sharing this, as it could help others troubleshooting similar connection issues.

---

<div class="post-metadata">

**Author:** ![jamesevans](https://avatars.discourse-cdn.com/v4/letter/j/77aa72/32.png) [@jamesevans](https://community.cdata.com/u/jamesevans)\
**Post date:** [November 11, 2026, 7:52pm UTC](https://community.cdata.com/t/msix-vs-zipped-version-of-claude-desktop-on-windows-caused-cdata-mcp-failures/1340/3 "2026-11-11T19:52:08Z")

</div>

MSIX apps often run with virtualized file/registry views and a different working directory, so a child MCP process may see different paths or environment than under the ZIP build. I’d compare the exact command, args, cwd and environment used for cdata-jdbc-mcp-server in both installs, and test launching that server manually with the same config. The unicode error may be secondary—for example a path or output-encoding difference—so also check the config for a BOM or non-ASCII characters and whether the MSIX build is passing a package-virtualized path.
