DEV Community: buildwithaihub

I gave Claude Code a brand-new Windows PC. Five things went wrong before it wrote a line.

buildwithaihub — Wed, 30 Sep 2026 18:31:38 +0000

Most Claude Code setup guides are written on a machine that already has years of tools on it. I wanted to see what a stranger's first hour actually looks like on Windows, so I gave Claude Code a machine that had never seen it and recorded everything.

Five things went wrong before it wrote a single line of real code. All five are measured, all five have a fix, and one of them is a safety problem.

The clean room: Windows Sandbox

My own PC has months of leftovers on it, so it can't show what a stranger sees. Windows Sandbox is a fresh copy of Windows every time you open it, and it forgets everything when you close it. That makes it a good test bench for "first install" questions.

It isn't free, though. The Sandbox base image took 3.8 GB of my C: drive, and one rehearsal took my free space from 4.4 GB down to 2.2 GB. Check your free space before you start. Also: judge the Windows version by the build number. My Sandbox said "Version 2004", and only the build number told me what I was actually running.

Trap 1: the installer succeeds, and `claude` is still "not recognized"

The official installer finishes cleanly, prints where it put Claude Code, and then tells you that folder is not on your PATH. On a clean machine it doesn't add it for you, so typing claude fails.

The fix: add the .local\bin folder in your user profile to your user PATH. In PowerShell:

[Environment]::SetEnvironmentVariable('Path',
  [Environment]::GetEnvironmentVariable('Path','User') + ";$env:USERPROFILE\.local\bin", 'User')

Then close PowerShell completely, open a new window, and run claude --version. claude doctor will list a few things as "not fetched" before you sign in. That's expected, not an error.

Trap 2: two exits that look like crashes

The first time you start Claude Code in a folder, it asks whether you trust that folder, and the highlighted answer is No, exit. Press Enter without reading and it just closes.

The second one: /logout doesn't only sign you out. It exits Claude Code too.

Neither is broken. Both will make a beginner think it is.

Trap 3: it starts in auto mode (the one that matters)

A new install of Claude Code starts in auto mode. I asked it to list the folder and create a test file, and it wrote the file without asking me first. On someone's first day, that isn't what you want.

The fix is a project settings file, .claude/settings.json, with the default permission mode set back to asking:

{
  "permissions": {
    "defaultMode": "default"
  }
}

With that file in the project, the next start showed manual mode, and Claude asked before it wrote. I measured that in the same run.

Trap 4: a write guard that blocked the product itself

Claude Code's built-in sandboxing isn't supported on native Windows, so I added a guard: a small PreToolUse hook script that refuses file writes (Claude's Write and Edit tools) outside the project folder. It blocked a write to the Desktop and let a write inside the project through.

But the first version also blocked plan mode. Plan mode saves its plans under your user profile, in ~/.claude/plans, which is outside the project. The fix was to allow that one folder.

The lesson I'd keep: before you ship a guard, list every place the product itself writes.

One honest limit: this guard covers Claude's file-writing tools. It is not a sandbox, and it does not stop a shell command from writing somewhere else. Asking before acting (trap 3) is what covers that.

What it cost

The clean install, talking it through as I went, took 32 minutes. The secure setup took 28 more. Undoing everything took about 5. And the first draft of my undo list forgot the PATH entry I had added myself, which is its own small lesson: build an undo list by reversing your own steps, not by copying the vendor's uninstall page.

The files

The settings file and the guard script are free, plain text, and short. Read them before you use them: https://lgcreativestudios.github.io/buildwithaihub/#free (or straight from GitHub: https://github.com/lgcreativestudios/buildwithaihub/tree/main/book/windows-setup).

The five, in one list

It isn't on your PATH.
The trust prompt defaults to exit.
Logging out exits too.
It starts in auto mode.
A guard has to allow the product's own plan folder.

And remember: don't trust the report. Check the number.

Tools I used to make the video

I'm an independent affiliate of ElevenLabs, Higgsfield and vidIQ. If you sign up through these links I may earn a commission, at no extra cost to you.

ElevenLabs (the voices): https://try.elevenlabs.io/n5brzq80coed
Higgsfield (the thumbnail image): https://higgsfield.ai?fpr=buildwithaihub
vidIQ (research and the music bed): https://vidiq.com/buildwithaihub

The narration voices are AI (ElevenLabs). The Sandbox run, the errors and the numbers are real.

ElevenLabs and the ElevenLabs logo are registered trademarks or trademarks of ElevenLabs, Inc. Used with permission. buildwithaihub is not sponsored by, endorsed by, or affiliated with ElevenLabs except as an independent participant in the ElevenLabs Creator Affiliate Program.

The wrapper that made my overnight AI scraper safe to leave running

buildwithaihub — Fri, 25 Sep 2026 01:41:52 +0000

I wanted a small research database to grow from one subreddit to ten communities where people talk about building with Claude Code and automation. Doing it properly was estimated at about $118. It cost about $34, and the corpus went from roughly 1,000 chunks to 5,846. Overnight, while I slept.

The scraping ran through a paid provider (Apify) that charges per delivered record. The cleaning, tagging and indexing were my own Python. Around all of it sat one PowerShell script, which Claude wrote for me. That script is what this post is about, because the agent isn't the hard part. Anyone can make an agent do something impressive while they're watching. The hard part is the wrapper that makes it safe to stop watching.

Three rules.

1. Every phase is resumable

The script keeps its own state: chunks before and after, spend at the start and end, what it recovered and what it couldn't. All of it is set before the work starts and read again at the end.

Scraping is the phase that fails. Reddit blocks a scraper that hits too many communities in one session, with a 403. My first version asked for all ten subreddits at once. Four listings came back empty, including every Claude community, and the run still said it succeeded.

The fix wasn't a smarter agent. It was batching: three subreddits at a time, and anything that comes up short goes into a retry queue and comes back on its own after a pause. All four blocked listings came back that way. Because the provider only bills for delivered records, the failed attempts cost nothing.

Everything after scraping (cleaning, tagging, indexing) can run again on the same input without doubling anything, and the paid tagging step skips whatever it has already done. That's what lets the script retry without asking me. If it needed my permission to re-run, I'd have to be awake.

2. Judge success by the provider's number, not yours

The obvious check: count your rows before the scrape, count them after, and if the number went up, it worked.

It's wrong, and it's wrong in a way that looks exactly like a failure. The pipeline deduplicates on the way in. A second pass over a community pulls the day's top posts, and many of those are already stored from the first pass. So the provider can deliver hundreds of good records while your database barely moves. A check on your side calls that a dead run and pays to scrape it again.

So success is the provider's delivered-record count, checked against a minimum I set for each community. My side can legitimately show no change and still be fine.

Money works the same way. Before every paid attempt, the script reads the account's actual spend for the month from the provider and stops at a hard cap. It doesn't keep its own estimate. If something in my pipeline miscounts, the budget check can't be fooled, because it isn't counting anything. It asks the account.

3. Write the report even if it crashes

The end of the script is a finally block. Whatever goes wrong above it (an error, a failed scrape, the provider going down), it still builds a coverage table, writes a status banner, saves the report and opens it in Notepad. One caveat: finally covers errors inside the script. If the whole process is killed, nothing runs.

The first real report said PARTIAL: one community, one listing not recovered, named, with the command to re-run it. Not a failure, a to-do. The mop-up the next day brought back 47 records, which was everything that community had that day.

When you're asleep for the whole run, silence is the worst output. Silence can mean everything worked, or that it died in the first 30 seconds, and from the couch those look the same. The report is what tells them apart.

What went wrong anyway

Two things, both the same lesson.

Headless Claude Code holds back its output. Launched from a script, it prints nothing until it exits unless you tell it to stream. So the log file sits at zero bytes for the whole run, and a healthy agent looks exactly like a dead one. I now judge an agent by the timestamps on the files it's writing and its CPU time climbing, never by the log.

My summary tables were one row long. The script that builds them had a nested database cursor that reset the outer loop after the first row. Every table came out formatted and plausible, and wrong. Now I count the rows I expect instead of eyeballing the top of the file.

A run that reports success and is wrong is scarier than a run that crashes. The crash tells you. The plausible report doesn't.

Get the script

The script is free on GitHub, with a header marking which lines to adapt:
https://github.com/lgcreativestudios/buildwithaihub/blob/main/scripts/v1/phaseC_overnight_orchestrator.ps1

It runs locally in PowerShell on Windows, reads your own Apify and OpenRouter keys from your user environment variables, calls those two services with them, and writes only local files. Read it before you run it.

Here's the 7-minute walkthrough, with the real report on screen:

Tools I used to make the video

I'm an independent affiliate of ElevenLabs, Higgsfield and vidIQ. If you sign up through these links I may earn a commission, at no extra cost to you.

ElevenLabs voices the narration: https://try.elevenlabs.io/n5brzq80coed
Higgsfield made the presenter images and thumbnail options: https://higgsfield.ai?fpr=buildwithaihub
vidIQ scored the title options and rendered the animated title cards: https://vidiq.com/buildwithaihub

I also turned these rules into a short book, It Ran While I Slept: five rules instead of three, the whole wrapper annotated, and a one-page pre-run checklist. Every store in one link: https://books2read.com/u/4DLP87

I'm building the whole system in public. If you want the next pieces as they land, there's a waitlist: https://lgcreativestudios.github.io/buildwithaihub/

Drafted with Claude's help from the video script. The run, the code and the numbers are real.

DEV Community: buildwithaihub

I gave Claude Code a brand-new Windows PC. Five things went wrong before it wrote a line.

The clean room: Windows Sandbox

Trap 1: the installer succeeds, and claude is still "not recognized"

Trap 2: two exits that look like crashes

Trap 3: it starts in auto mode (the one that matters)

Trap 4: a write guard that blocked the product itself

What it cost

The files

The five, in one list

Tools I used to make the video

The wrapper that made my overnight AI scraper safe to leave running

1. Every phase is resumable

2. Judge success by the provider's number, not yours

3. Write the report even if it crashes

What went wrong anyway

Get the script

Tools I used to make the video

Trap 1: the installer succeeds, and `claude` is still "not recognized"