Claude Code on Windows for Non-Developers: 6 Snags I Hit and How I Got Past Them

Claude Code on Windows for Non-Developers: 6 Snags I Hit and How I Got Past Them

Hi there.
I'm not a developer, and everything I do with AI runs on a single Windows 11 PC.
Claude Code handles the technical side for me, from installing tools to building the small app I use every day.
Here are six Windows-specific snags I hit in my first week, and how each one got fixed.

A big desktop app window in front, with a small terminal window behind it

My setup: a desktop app, not a terminal

I use Claude Code through the Claude desktop app (its Code tab), not a terminal window.
I type what I want in plain language, and Claude runs the commands itself.
In those first few days, I opened a terminal only once (snag #5 explains why).

That choice shaped everything below.
Most guides assume you're comfortable in a terminal.
These snags are what happens when you're not, and the agent has to work around Windows for you.

Hands typing on a laptop with ChatGPT open

Photo: Matheus Bertelli on Pexels

Snag #1: new tools "weren't installed" right after installing them

I needed Node.js and Git.
Claude installed both with Windows' built-in package manager (winget).
My only job was clicking "Yes" on the Windows permission prompt.

Two installer packages flying into a computer while a robot presses a Yes button

Then Claude's next command couldn't find either tool.
The installs had worked, but the app's shell was still using the old list of program locations (the PATH) from before the install.

Fix: reload the PATH at the start of each command.
It's a one-line prefix, and it's only needed until the app restarts and picks up the new PATH.

Snag #2: non-English text turned into gibberish

Claude wrote a small PowerShell script that included some non-English characters.
When it ran, those characters came out garbled and the script threw syntax errors.

Jumbled blocks labeled Gibberish pass through a funnel and come out as neat lines labeled UTF-8

Windows PowerShell 5.1 reads a script file without a byte-order mark using the system's legacy regional encoding (whatever code page Windows uses for your region), not UTF-8.
Any non-English characters in the file get misread.

Fix: save scripts as UTF-8 *with* a byte-order mark, or have PowerShell explicitly read the file as UTF-8 before running it.

Snag #3: a two-letter name that was already taken

Claude named a small helper function gc.
Nothing got recorded, and nothing errored either.
In PowerShell, gc is already a built-in shortcut for reading files, and it ran instead of the new function.

Fix: use PowerShell's verb-noun style for names (it became Invoke-GC), and check the exit code so a silent failure stops the run.

Snag #4: quotation marks that broke a long prompt

To make images, Claude passes a long text prompt to another command-line tool.
When the prompt contained double quotes, PowerShell 5.1 split it into pieces, and the tool complained about unexpected arguments.

Fix: don't pass long text as a command-line argument.
Send it through standard input instead, with the output encoding set to UTF-8.

Snag #5: a folder the rest of the PC couldn't see

Claude installed one command-line tool into my AppData folder.
It said the install succeeded.
But my own terminal couldn't find it anywhere.

A folder sealed in a bubble labeled App Only, next to a folder labeled Your PC

The Claude desktop app on Windows is a packaged (MSIX) app.
Files it writes into AppData get redirected into a private, virtualized folder, invisible to other programs.

Fix: anything that installs into AppData, I install from my own terminal, outside the app.
That was the one time I opened a terminal.

Holding a phone with ChatGPT open

Photo: Matheus Bertelli on Pexels

Snag #6: "Cannot connect to C:"

A script called tar to unpack a file.
It failed with "Cannot connect to C:", as if the C: drive were a remote server.
That shell was Git Bash, and Git ships its own tar that reads C: as a remote host name.

Fix: call Windows' own tar by its full path, under the System32 folder.

Wrapping up

None of these were hard problems.
They were all Windows details that a terminal-fluent developer handles without noticing, and that stop a non-developer cold.
I now keep each one in a running failure log, so the same mistake doesn't happen twice.

If you want to run more than one agent session at a time, I wrote about running multiple Claude Code sessions on one project.
And I explained how I automated publishing to Blogger in an earlier post.

Which Windows quirk has tripped up your AI tools the most?
Tell me in the comments.
Thanks for reading to the end.

Comments

Post a Comment

Popular posts from this blog

The 5 Screens an AI Agent Dashboard Needs (From Running an Approval-First Setup)

Image
I run a handful of AI agents for my side projects, and I don't write code. That combination creates one hard requirement: nothing goes public until I click Approve , and I should never need a terminal to do it. So on day one I had a small local web dashboard built (by an AI coding agent) with exactly that job. It runs only on my own PC. After a day of real use, including one rejected approval and a couple of mistakes, here are the five screens I'd insist on again, and what each one taught me. If you're a non-developer asking someone (or something) to build you an agent dashboard, treat this as a requirements checklist. 1. A task board with honest statuses Every instruction becomes a numbered task that moves through seven states: waiting, in meeting, working, in review, awaiting approval, done, failed . Why seven and not "to do / done"? Because the dangerous moment is the gap between "the agent thinks it's finished" and "a human has signed ...
Read more

Day One With an AI Agent Team: 6 Things That Broke (and the Fixes)

Image
On September 26, 2026, I set up a small team of AI agents on my PC. Claude does research, writing, and review. OpenAI's Codex and Google's Antigravity make images. I don't write code. Most setup guides show the happy path. This post is the other half: the six things that actually went wrong on day one, why they happened, and what I changed. Every item comes from my own failure log, so none of this is hypothetical. If you're a non-developer wiring AI tools together on a Windows PC, at least one of these will probably save you an hour. 1. The image tool had no quota left before I started What happened. My first image request to Codex failed instantly with "You've hit your usage limit," and a time when it would reset. Why. Codex usage on a ChatGPT plan is shared across the places you use it. OpenAI says the same limits apply in the app, the CLI, the IDE extension, and the cloud ( OpenAI Help Center , checked 2026-09-26). I hadn't run anything thro...
Read more

Automating Blog Posts With AI, Safely: What the Blogger API Can't Do (and My Workarounds)

Image
For my first few posts, publishing meant copying HTML from my dashboard and pasting it into Blogger by hand. It worked, but it was slow and error-prone: once, the wrong page's text ended up on my Privacy Policy. So I automated it with Google's official Blogger API. Now I do one thing: click Approve . Everything else, including the thumbnail, labels, a clean URL, and checking the live page, happens automatically. Here's how it works, the two things the API can't do, and one mistake that briefly took my blogs offline. Rule one: no approval, no post Before anything else, the publishing script checks my dashboard's approval records for that task. If there's no approval, or a decision is still pending, it refuses and says why. It also refuses to publish the same draft twice. I tested both refusals before the first real run. If you automate publishing, build the "no" path first. Photo: Andrew Neel on Pexels The one-time setup (about 15 minutes) Cre...
Read more