90 Minutes for One Merge? Windows Developers Can't Afford to Wait.

description: "Slow CI is only the beginning. Shell differences, executable resolution, special characters in paths, and MCP client configurations create a hidden compatibility tax for developers building AI tools for Windows."
tags: ai, windows, mcp, programming
series: "The Windows Development Challenge"

The Windows Tax: Why Building AI Developer Tools for Windows Is Harder Than It Looks 🪟

In "Part 1, we reduced our Windows CI/CD pipeline from 13.6 minutes to 2 minutes and 44 seconds" (https://dev.to/jackymencz/how-we-slashed-our-windows-cicd-pipeline-from-14-minutes-to-under-3-2id0).

That solved one problem: waiting for tests.

But it exposed another problem that developers working on AI infrastructure know very well.

Getting your software to actually work on Windows is an entirely different engineering challenge.

Writing an MCP server is one thing. Making sure it installs, launches, connects, and behaves correctly across different Windows environments is another.

And sometimes, the problem is not your application code at all.

It's the operating system standing between your code and the user.

🛑 Problem No. 1: "npx" Is Not Always "npx"

Let's start with something deceptively simple.

An MCP server needs to launch through Node.js. On Linux, developers often use a straightforward process invocation:

"spawn("npx", args)"

Easy enough.

Except Windows has a different executable resolution model for command-line tools.

The npm executable on Windows is typically provided through "npx.cmd", not a regular executable that every process launcher can start directly.

During our Windows compatibility testing, a direct "spawn("npx")" failed with "ENOENT" across Node.js 20, 22, and 24.

We tested alternative launch strategies.

The solution was to use the Windows command interpreter:

"cmd /c npx"

Our recorded compatibility tests confirmed that this approach connected successfully across all three Node.js versions.

One small launcher difference. Three Node.js versions. An entirely different execution path.

This is the kind of problem that can make an otherwise perfectly functional AI tool completely unusable.

🧩 Problem No. 2: Windows Paths Are a Minefield

You might think handling a project path is trivial.

Let's try this one:

"C:\sentinel-test\it's $HOME & 100% ^caret! (x)"

This is a legitimate Windows path.

Now imagine passing it through multiple layers:

• Node.js argument handling.
• CMD.
• PowerShell 5.1.
• PowerShell 7.
• An MCP client.
• A process launcher.

Every layer can interpret certain characters differently.

During our tests, unescaped "&" broke VS Code commands. A path containing "%OS%" could also be interpreted as an environment-variable reference when passed through "cmd /c".

PowerShell introduced another layer of complexity because ".ps1", ".cmd", and ".exe" commands do not necessarily behave identically.

The result?

You cannot simply quote everything and assume the problem is solved.

We implemented explicit argument handling and escaping, then tested the actual values received by the target programs.

Our recorded Windows compatibility work includes a quoting probe with 45 successful checks across PowerShell 5.1, PowerShell 7.6.7, CMD, multiple executable types, and difficult project paths.

That's not glamorous software engineering.

But it is necessary software engineering.

⚙️ Problem No. 3: Passing CI Does Not Mean Your MCP Server Works

Here is another misconception.

A green CI badge does not automatically mean your MCP server works in a real desktop application.

There are several distinct stages:

1. The package installs.
2. The launcher starts the correct executable.
3. The server initializes.
4. The MCP client establishes a connection.
5. The client discovers the available tools.
6. An actual request reaches the server and returns the expected result.

A test that verifies only the first three stages does not prove the entire integration works.

We therefore added compatibility checks that go beyond simply running the test suite.

Our "doctor" command checks the Node.js environment, package configuration, project folders, starts the server independently, performs a real MCP handshake, and checks the available tools.

This does not prove that every desktop client's UI or agent works correctly. That distinction matters.

But it provides considerably stronger evidence than checking whether a configuration file exists.

🧪 Problem No. 4: Cross-Platform Tests Need Different Expectations

Windows and Linux do not implement every filesystem behavior identically.

For example, a Linux test using:

"chmod 000"

cannot simply be copied into a Windows test suite and expected to mean the same thing.

Windows uses a different permission model.

Our compatibility records explicitly identify a permission-related test as skipped on Windows rather than pretending that the same behavior was verified.

That is an important distinction.

Cross-platform testing is not about forcing every operating system to behave identically.

It is about testing equivalent guarantees using the mechanisms each platform actually supports.

🔬 What We Learned Building Sentinel-IR-MCP

This is not theoretical research.

We encountered these problems while developing our own MCP server and testing its compatibility.

The project has separate components:

• "Sentinel-IR-MCP on GitLab" (https://gitlab.com/jakubrojicek11/sentinel-ir-mcp) – the MCP server.
• "sentinel-ir-mcp on npm" (https://www.npmjs.com/package/sentinel-ir-mcp) – the published Node.js package.
• "sentinel-ir on npm" (https://www.npmjs.com/package/sentinel-ir) – the underlying code analysis engine.
• "Sentinel-IR-MCP on Glama" (https://glama.ai/mcp/servers/jakcmencz/sentinel-ir-mcp) – the MCP directory listing.
• "Sentinel-IR Playground" (https://sentinel-ir-playground-dc30c8.gitlab.io/) – the browser-based analysis playground.

The implementation includes platform-aware launch configuration, compatibility checks, Windows-specific argument handling, and a separate diagnostic command.

We also maintain a dedicated "Windows compatibility test record" (https://github.com/jakcmencz/sentinel-ir-mcp/blob/main/COMPATIBILITY.md), documenting what was actually tested and what remains unverified.

That last part is important.

We don't consider an untested environment supported just because the code looks portable.

💸 The Hidden Windows Tax

Every platform-specific failure has a cost.

A developer loses time reproducing it.

A maintainer needs another compatibility fix.

A CI pipeline needs another test.

A user encounters another installation problem.

And when the software is designed for AI agents, the consequences multiply.

An MCP server that cannot launch is not merely inconvenient.

The agent loses access to the functionality it was supposed to provide.

You can have a sophisticated analyzer, a carefully designed security model, and a fast execution engine.

But none of those capabilities matter if the process never starts.

🚀 The Next Bottleneck Is Not Intelligence

The AI industry is moving rapidly toward autonomous development environments, persistent agents, and increasingly sophisticated MCP integrations.

Yet developers still have to solve problems that have existed for decades:

Process execution.

Shell compatibility.

Filesystem semantics.

Environment variables.

Executable resolution.

Cross-platform packaging.

These are not exciting problems to advertise.

They are the problems that determine whether someone can actually use your software.

Part 1 was about removing unnecessary waiting from Windows CI/CD.

Part 2 is about removing unnecessary friction from Windows compatibility.

Because building an AI tool that works on your machine is not the same as building one that works for everyone.

And Windows developers deserve better than being an afterthought.