Why AI Coding Agents Struggle on Windows (And How to Fix Them)

Signup Write New Story Why AI Coding Agents Struggle on Windows (And How to Fix Them) by Peter Mamrukov by Peter Mamrukov | @ petermamrukov Enterprise AI & Automation Leader | AI Agents, MCP & Agentic Engineering | ex-CIO/CTO, Hands-On Builder

Enterprise AI & Automation Leader | AI Agents, MCP & Agentic Engineering | ex-CIO/CTO, Hands-On Builder

For a while my workflow with AI was: the chat suggests a fix, I paste it into the terminal, run the tests, copy the error back. I was a very slow USB cable between the model and my Windows PC. Agent modes were supposed to end that. On Windows they often don't, and the reasons are fixable.

The agent writes a command your shell won't parse. It chains steps with && in Windows PowerShell 5.1, mangles backslashes, or runs a bash-style command that resolves to a different Windows program. A Cursor forum thread calls PowerShell in Cursor "consistently broken", and a Claude Code issue reports that native Windows runs aren't really shell aware: move not found, backslashes broken, find resolving to the Windows binary.

The agent starts a dev server and the chat never comes back. npm run dev doesn't exit, so the tool call waits forever, or the agent decides the server started when it didn't. Kill the terminal and the server often keeps its port; one Cursor user put it as "I have to manually kill it."

Both come from the same place. The agent is handed a terminal and expected to type into it like a person. A person knows which shell they're in and when to stop waiting. A model guesses.

Most quoting bugs disappear when nothing parses a command line. If you write your own agent tools or scripts, start real executables directly:

A rule in your agent's instructions is a hint; a hook is enforced. In Claude Code, a PreToolUse hook with matcher PowerShell sees each command first, and exit code 2 blocks it and sends your message back to the model:

import json, sys cmd = json.load(sys.stdin).get("tool_input", {}).get("command", "") if "<<" in cmd: sys.stderr.write("PowerShell has no heredoc. Write the file with the Write tool, or use a @'...'@ here-string.") sys.exit(2) The model reads the message and retries another way. The same pattern catches && on Windows PowerShell 5.1, or helper functions named after built-in aliases such as rd.

Start long-running servers in the background and come back for the log, instead of waiting for them to exit. When one is left behind, the port leads you to it:

netstat -ano | findstr:5173 taskkill /PID <pid> /T /F The PID is the last column of the LISTENING line. /T stops the process together with everything it started (for Vite that includes esbuild); plain Stop-Process only takes the one PID. And before believing "the server is running", ask it:

curl.exe -s -o NUL -w "%{http_code}" http://localhost:5173/ curl.exe ships with current Windows 10 and 11; a 200 is worth more than a log line that says "ready".

Limiting an agent to certain folders and keeping it away from.env and private keys stops the everyday accidents. People have watched agents read secret files and delete home directories; those are mostly habits, and habits can be blocked.

None of that is a sandbox. If node or python is allowed, a script can do anything your account can do, including deleting files. For a real wall, run the agent's tools in a container, under a separate low-privilege account, or in a VM.

I maintain an open-source MCP server, local-commander-mcp-agent (MIT), that packages fixes 1, 3 and part of 4 for agents; it was built around exactly these problems: https://github.com/netbka/local-commander-mcp-agent. If you have a Windows setup that still trips your agent up (unusual paths, non-English usernames, locked-down corporate machines), I'd like to hear about it.