DEV Community: Patience Sitati

When RAG Fails: Anchoring Bias and Metacognition in Modern LLMs

Patience Sitati — Tue, 08 Sep 2026 13:00:00 +0000

## How a bizarre Claude Code CLI bug exposed the limits of multi-turn troubleshooting loops, and why the future of AI relies on cognitive routing.

I recently ran into an issue with Claude Code on Windows.

I gave Claude everything it needed: the terminal output, my precise installation details, the active executable path, and a granular breakdown of everything I had already tried.

It kept troubleshooting. But it kept troubleshooting in entirely the wrong direction.

Then I gave the exact same context to Google's Gemini Pro. It identified the root cause almost immediately. I selected its first recommended workaround, and the problem was instantly solved.

That experience raised a far more interesting architectural question than the engineering bug itself: Why did two state-of-the-art AI systems, both fully capable of tool execution and external information retrieval, take such drastically different paths when evaluating the exact same technical telemetry?

The Problem: Claude Code Was Running Bun Instead

This was the strange output I was getting from PowerShell:

PS C:\code\tukole_backend\waitly> & "C:\Users\THINKPAD\.local\bin\claude.exe"

Bun is a fast JavaScript runtime, package manager, bundler, and test runner. (1.4.0+eb835313a)

Usage: bun <command> [...flags] [...args]

Commands:
  run ./my-script.ts
  lint
  test
  x
  ...

Checking the binary's version flag yielded a matching runtime signature:

PS C:\code\tukole_backend\waitly> & "C:\Users\THINKPAD\.local\bin\claude.exe" --version
1.4.0

I wasn't trying to execute Bun. I was trying to invoke Claude Code.

I verified which binary PowerShell was actually resolving:

PS C:\code\tukole_backend\waitly> Get-Command claude

CommandType     Name       Version    Source
-----------     ----       -------    ------
Application     claude.exe 2.1.224.0  C:\Users\THINKPAD\.local\bin\claude.exe

PowerShell was discovering the correct claude.exe path. I manually scanned for active shell aliases and functions. Nothing. I then attempted to override the local path by installing Claude Code globally through npm:

npm install -g @anthropic-ai/claude-code

The installation completed cleanly. Yet, running claude in a fresh shell prompt still yielded Bun's help screen. This was the exact juncture where the model's troubleshooting loop began going in circles.

The Compounding Failure of Agentic Anchoring Bias

Claude repeatedly explored classic Windows system administration hypotheses:

Environment variable PATH resolution
Corrupted PowerShell aliases or profiles
Conflicting node_modules environments
Binary discovery precedence

These are entirely reasonable things to verify in a standard Windows terminal context. The failure, however, was that none of these hypotheses accounted for the strongest piece of anomalous evidence in the system state:

   claude.exe ⟶ Bun 1.4.0 CLI

The shell was invoking the binary cleanly. The issue was not command resolution; it was what was happening internally once execution entered the binary layer.

This failure mode is a prime example of Agentic Anchoring Bias. In multi-turn context windows, once an LLM samples a high-probability initial hypothesis (e.g., “This is a Windows path configuration error”), its attention heads progressively overweight tokens that validate that branch. Instead of treating a major anomaly—like an executable directly outputting an entirely different tool's runtime help menu—as a trigger to discard its mental model, the agent continues to recursively generate edge-case validation tasks within the wrong problem domain.

What Gemini Found: Decoding the Compilation Layer

When I provided the same terminal output and installation history to Gemini, the reasoning model skipped the local environment infrastructure entirely. It instantly correlated the unique token intersections:

{Claude Code + Windows + claude.exe + Bun 1.4.0}

Gemini recognized a structural signature that Claude missed: Anthropic packages its standalone desktop distribution of Claude Code as a single compiled executable via Bun’s native compilation engine (bun build --compile). The executable embeds the entire Bun JavaScript runtime directly inside the target binary.

A tiny bootstrap layer—a launcher trampoline—is supposed to intercept execution immediately and run the packaged Claude agent. When a regression bug breaks this launcher script on specific Windows environments, execution drops straight through to the raw, embedded Bun CLI engine fallback.

Because Gemini updated its hypothesis based on the compilation mechanics rather than environment pathing, its workaround was clean and effective:

# Remove the problematic native binary mapping
Remove-Item "$env:USERPROFILE\.local\bin\claude.exe"

Restarting the shell forced Windows to look past the deleted native binary and fallback to the global NPM package execution layer. Problem solved.

Web Access is Not Effective Retrieval

It is tempting to oversimplify this outcome by asserting that Gemini simply had real-time web access while Claude was reasoning in isolation. But that explanation fundamentally misunderstands modern LLM runtimes. Both architectures utilize Retrieval-Augmented Generation (RAG) and web-search tools.

The critical lesson here is that web access is not the same as effective retrieval. An AI system can have access to billions of web documents and still fail to surface the single GitHub issue or tracking thread that matters.

The operational pipeline of an engineering agent follows a strict cascading dependency chain:

    User Problem ──► Interpretation ──► Query Generation ──► Document Retrieval 
                                                                    │
    Solution ◄── Hypothesis Update ◄── Pattern Recognition ◄── Evidence Ranking

A failure at any single node in this pipeline breaks the output. If the model's interpretation layer is anchored to a Windows PATH hypothesis, its query generation engine will inherently output search queries focused on Windows shell path resolution errors. It will never formulate a query targeting Bun executable compiler trampoline regressions.

The difference in performance wasn't a question of model "intelligence". It was an architectural failure to abandon a low-confidence hypothesis branch.

This Is Where Andrej Karpathy's LLM Council Gets Interesting

The foundational open-source karpathy/llm-council GitHub repository explores a simple idea: instead of relying blindly on a single model's isolated inference, dispatch a user prompt across multiple models independently, allow them to anonymously peer-review each other's outputs, and use a final "Chairman" layer to synthesize the responses.

While this multi-model approach is robust, running five deep-reasoning models on every trivial developer prompt is an incredibly inefficient use of compute tokens. It highlights the practical limits of throwing raw, unmetered computing power at single-model inferences.

Beyond the Supermodel: The Case for Metacognition

Instead, the solution points toward an architecture built around LLM Metacognition—the system's structural ability to monitor its own cognitive state and evaluate whether it is stuck.

                        ┌────────────────────────┐
                        │      User Problem      │
                        └───────────┬────────────┘
                                    │
                                    ▼
                        ┌────────────────────────┐
                        │   Primary LLM Agent    │
                        └───────────┬────────────┘
                                    │
                    ┌───────────────┴───────────────┐
                    ▼                               ▼
       [Confidence Threshold Met]      [Confidence Threshold Fails]
                    │                               │
                    ▼                               ▼
        ┌───────────────────────┐       ┌───────────────────────┐
        │  Direct Resolution    │       │   Metacognitive State │
        └───────────────────────┐       │       Escalation      │
                                        └───────────┬───────────┘
                                                    │
                                                    ▼
                                        ┌───────────────────────┐
                                        │  Cross-Model Routing  │
                                        │   & Targeted RAG      │
                                        └───────────┬───────────┘
                                                    │
                                                    ▼
                                        ┌───────────────────────┐
                                        │  Synthesized Response │
                                        └───────────────────────┘

The system shouldn't escalate by default. It should trigger an escalation protocol only when specific telemetry metrics are reached:

The same file paths or diagnostic branches are being repeatedly scanned
Successive RAG iterations return highly similar document spaces with low semantic variance
New internal telemetry data directly contradicts the active model hypothesis

When these conditions are met, the cognitive router strips the primary model of its context-lock, routes the problem state to an entirely independent model, and forces a clean-slate hypothesis generation.

Conclusion

The future of AI engineering tools likely won't belong to a single, monolithic "supermodel" that possesses perfect omniscient knowledge. The true performance frontier lies in the orchestration layer wrapped around these models.

The missing capability in my Claude Code debugging session wasn't a lack of technical knowledge. The system simply lacked the metacognitive awareness to step back, look at its own failing troubleshooting loops, and declare: "My current framework cannot explain this telemetry. It is time to wipe the hypothesis and ask another model."

Building AI systems that know how to solve problems is easy. Building AI systems that know exactly when they are failing to solve a problem will be the real transformation.

I Built a Waitlist with Waitly. The README Made It Look Easier Than It Was

Patience Sitati — Wed, 01 Jul 2026 13:00:00 +0000

A build log for future-me—and for the next person who does not want to discover every missing step through a series of 500 errors.

It looked like a 10-minute setup

I am working on a product that I am not ready to talk about publicly yet.

Before launching it, I wanted somewhere to send interested people: one page that explains enough about the product, collects their email addresses, and gives me a list of people to invite when it is ready.

In other words, I needed a waitlist.

The plan sounded simple:

Add a headline.
Add an email form.
Save the signups somewhere.
Send a confirmation email.
Deploy.

Then I found Waitly, an open-source waitlist template with a good README, and thought I had saved myself a lot of work.

I had saved myself some work.

I had not saved myself from debugging.

The template itself is solid, but several parts of the setup either assume prior knowledge or only become clear after something breaks. This post covers what I set up, what went wrong, and what I wish I had known before starting.

How I found Waitly

My first instinct was to build the waitlist from scratch. I write code, so why not?

But while researching waitlist options through Google’s AI Mode, the search wandered into a place I hadn't expected and surfaced Waitly. Once I opened it, I realized it already had most of what I needed.

Waitly is a Next.js template that connects three services:

Notion to store signups
Upstash Redis for rate limiting
Resend for confirmation emails

The repository is:

https://github.com/revokslab/waitly

Instead of rebuilding the whole signup flow, I decided to customize the template around my product.

That was the easy decision.

The setup was where things became interesting.

Step 1: Fork and keep it separate

I kept the waitlist in its own folder beside my main application instead of nesting it inside the app:

projects/
├── main-product/
└── waitlist/

This kept the Git history, dependencies, and deployment settings separate.

I also forked the repository to my GitHub account before cloning it:

git clone https://github.com/YOUR_USERNAME/waitly.git
cd waitly
pnpm install

A fork made sense for me because I wanted to deploy from my own repository while keeping a link to the original project.

If you want a completely independent repository, GitHub’s Use this template option may suit you better.

Step 2: Turn the template into my product

Once the project was running locally, I replaced the template content with my own branding.

I changed:

the headline and supporting copy;
the early-access incentive;
the FAQ;
the footer and wordmark;
the confirmation email;
the feature section; and
the primary, accent, and background colors.

I also replaced the template’s logo strip with feature cards because that made more sense for the product I am building.

One small lesson: do not assume every brand color is controlled by one CSS variable. The original accent color appeared in several places, so I searched the whole codebase for the old value and replaced the remaining hardcoded instances.

Three template issues I found

I also found a few things worth checking before assuming your own changes caused the problem.

1. The countdown date was already in the past

The hero countdown used an old hardcoded target, so it displayed a dead timer. I replaced it with my actual launch target.

2. `dynamic` was misspelled

One page configuration used:

dyamic

instead of:

dynamic

Because the option was misspelled, Next.js ignored it. That could affect whether changing data, such as the signup count, appears as expected.

3. A component had stray characters in a class name

They did not completely break the interface, but they were worth cleaning.

None of these were major issues, but they taught me not to assume every strange behavior was due to my customization.

Step 3: Set up the three services

The interface can load perfectly even when none of the backend integrations work.

To make the full signup flow functional, I needed credentials for Notion, Upstash, and Resend.

Notion: the database is more specific than it looks

At first, I assumed I only needed a name and email field.

That assumption caused several of my errors.

Waitly includes a referral system, so the code expects five Notion properties:

Property	Type
`Name`	Title
`Email`	Email
`Referral Code`	Text
`Referred By`	Text
`Referrer`	Relation to the same database

The names must match what the code expects, including spacing and capitalization.

After creating the database, I:

Created a Notion integration (https://app.notion.com/developers/connections).
Copied its internal integration token.
Connected the integration to the database.
Copied the database ID from the URL.

The connection step is easy to miss. Creating an integration does not automatically give it access to your database.

The Notion columns trap

My first signup failed with a Notion validation_error.

The code was trying to write properties that did not exist:

Referral Code
Referred By
Referrer

I fixed them one at a time.

First, the terminal listed three missing properties. Then two. Then one.

Finally, I got a different error because I had created Referrer as a text field instead of a relation. I changed it to a Relation pointing back to the same database.

It was one of those debugging sessions where every new error was annoying, but also proof that I was getting closer.

Set up all five fields correctly at the beginning and save yourself that journey.

Upstash: simple until I needed a second database

For Upstash, I needed two values:

the REST URL;
the REST token.

Waitly uses Redis for rate limiting so that one person cannot repeatedly spam the signup form.

The setup was straightforward, but I ran into a limitation because I already had a Redis database on my free Upstash account.

When I tried to create another one, Upstash required me to add a payment method, such as a Visa card, Mastercard, or PayPal account, and set a spending limit of at least $20.

At first, it looked like I had to pay $20 just to create the database.

That was not the case.

The $20 was a spending limit, not an upfront deduction. I would only be charged if I used services or resources that exceeded the free allowance.

My options were to:

add billing details and create a separate database;
reuse my existing database with clearly separated key prefixes; or
use another suitable account or workspace.

I preferred keeping the waitlist database separate from my other project.

Once it was available, I added the REST URL and token to .env.local, and that part worked without much drama.

Compared with Notion and Resend, it was refreshingly uneventful.

Resend: testing and real email are different stages

I created a Resend API key and initially used:

onboarding@resend.dev

This was useful for testing, but in my setup it could only deliver to the email address connected to my Resend account.

That meant I could confirm that the route worked, but I could not use it for public signups.

To send confirmation emails to real users, I needed a verified domain.

That requirement turned my waitlist task into a domain, DNS, Vercel, and email-deliverability task too.

Step 4: Add the environment variables

I placed the local credentials in .env.local at the project root:

NOTION_SECRET=...
NOTION_DB_ID=...
UPSTASH_REDIS_REST_URL=...
UPSTASH_REDIS_REST_TOKEN=...
RESEND_API_KEY=...
RESEND_FROM_EMAIL=...

Then I started the project:

pnpm dev

I submitted a test signup and checked three things separately:

Did the form return a success response?
Did a row appear in Notion?
Did the confirmation email arrive?

Testing them separately helped me work out whether the problem was in the interface, Notion, or Resend.

Watch the Notion environment-variable name

In the version I used, the README referred to:

NOTION_DB

but the code expected:

NOTION_DB_ID

An environment variable can exist perfectly and still do nothing if its name does not match what the application reads.

Check the source code, not only the README.

Vercel needs its own environment variables

Vercel does not read the .env.local file on your computer.

I had to add the same variables under:

Vercel → Project Settings → Environment Variables

I also had to redeploy after changing them.

The biggest Resend gotcha: I needed a domain

A .vercel.app address can host the waitlist, but it cannot act as an email-sending domain.

My process became:

Test with Resend’s development sender.
Buy a domain.
Connect the website hostname to Vercel.
Configure a sending subdomain in Resend.
Update RESEND_FROM_EMAIL.
Redeploy and test again.

The Vercel and Resend setups are technically separate, but doing the website side first helped me organise the DNS records without mixing everything together.

Why I used a sending subdomain

Instead of sending directly from the root domain, I used a subdomain such as:

send.yourdomain.com

This keeps automated product emails separate from future business email.

For example:

hello@yourdomain.com

could be used for ordinary communication, while:

updates@send.yourdomain.com

handles automated waitlist confirmations.

This separation can make DNS management cleaner and help isolate the reputation of transactional email from regular business correspondence.

Connecting the waitlist domain to Vercel

One domain can support several services through subdomains:

yourdomain.com       → main website
join.yourdomain.com  → waitlist
send.yourdomain.com  → automated email

I did not need to buy a separate domain for the waitlist.

In my registrar’s DNS dashboard, I removed the default parking records that conflicted with the hostnames I wanted to use. I then added the records Vercel requested.

A typical setup may look like this:

I also added the waitlist hostname to the correct Vercel project under:

Settings → Domains

Both sides have to match:

The registrar points the hostname to Vercel;
Vercel connects that hostname to the correct project.

I followed the exact values shown in my Vercel dashboard rather than assuming every setup would use the same records.

One more domain lesson: check the renewal price before buying. The very low price you see is often only for the first year.

The runtime errors I actually hit

A clean build did not mean the waitlist worked.

Most of the real problems appeared only after I submitted the form.

`Unable to acquire lock at .next/dev/lock`

I also saw a message saying port 3000 was already in use.

A previous Next.js development process was still running and holding the port and development lock.

I stopped the stray Node process and started the server again.

On Windows, check for old terminal sessions or background Node processes before deleting build folders or changing configuration.

`POST /api/mail 500`

The browser only told me that the mail request failed.

That was not enough information to fix it.

I added server-side error logging and checked the terminal. Resend was rejecting the recipient because I was using its test sender with an email address that was not authorized for that testing mode.

For testing, I used the email connected to my Resend account.

For public signups, I moved to a verified domain.

Once the sender and recipient setup matched Resend’s requirements, the route returned 200.

`POST /api/notion 500`

This came from the database property mismatch.

The application was sending referral fields that my Notion database did not contain.

The fix was not in the interface or the API route. It was in the Notion schema.

After I added the missing properties and changed Referrer to a relation, the signup finally appeared.

The debugging lesson I am keeping

When the browser says:

500 Internal Server Error

it is only telling you that the server failed.

It is not telling you why.

The frontend showed me that something had broken.

The terminal told me what to fix.

What I would do differently next time

I would still use Waitly. I would just set it up in a better order:

Was it worth it?

Yes.

It took longer than the “quick waitlist” I thought I was setting up, but more importantly, I now understand how the pieces connect.

And now, when future-me forgets why Referrer is a relation instead of a text field, this post will be here.

Claude Code Ate My Storage, So I Asked Claude Code to Fix It

Patience Sitati — Wed, 24 Jun 2026 12:00:00 +0000

I knew AI tools and development work could take up storage, but using Claude Code ran through my space faster than you can say "go."

I started using Claude Code in the terminal in April, and honestly, it has been helpful. It helps me fix bugs faster, understand errors, and move through development quicker.

But it has also helped me finish my storage quicker.

At first, I did not realise how much space I was losing. I just kept working until Windows started reminding me that my storage was almost full every five minutes.

So, naturally, my first instinct was to ask Claude Code how to fix the problem it had helped create.

I asked it to give me a script that could clear about 15GB of storage.

It gave me one.

The first script

# --- CLAUDE CODE MASTER CLEANUP & OPTIMIZATION ---

# 1. AUTO-FIX: Set 2GB Node Memory Limit (Prevents 15GB Pagefile Bloat)
$varName = "NODE_OPTIONS"
$varValue = "--max-old-space-size=2048"
$currentValue = [Environment]::GetEnvironmentVariable($varName, "User")

Write-Host "⚙️  Optimizing system memory limits..." -ForegroundColor Cyan
if ($currentValue -like "*$varValue*") {
    Write-Host "   - ✅ Memory limit is already correctly configured." -ForegroundColor Green
} else {
    $newValue = if ($currentValue) { "$currentValue $varValue" } else { $varValue }
    [Environment]::SetEnvironmentVariable($varName, $newValue, "User")
    Write-Host "   - 🛠 Applied 2GB limit to Windows User Variables." -ForegroundColor Yellow
}

# 2. KILL LEAKING PROCESSES (Releases locked RAM/Pagefile)
Write-Host "`n🛑 Terminating orphaned Claude & MCP processes..." -ForegroundColor Yellow
$procs = Get-Process -Name "claude", "node" -ErrorAction SilentlyContinue | 
         Where-Object { $_.Path -match "anthropic" -or $_.CommandLine -match "mcp" }
if ($procs) {
    $procs | Stop-Process -Force
    Write-Host "   - Closed $($procs.Count) ghost processes." -ForegroundColor Green
}

# 3. GLOBAL CACHE CLEANUP
$claudePath = "$HOME\.claude"
if (Test-Path $claudePath) {
    Write-Host "`n🧹 Wiping global Claude cache (Logs, History, Temporary files)..." -ForegroundColor Cyan
    $folders = "debug", "projects", "file-history", "image-cache", "shell-snapshots", "todos", "plans"
    foreach ($folder in $folders) {
        $subDir = Join-Path $claudePath $folder
        if (Test-Path $subDir) { 
            Remove-Item -Path "$subDir\*" -Recurse -Force -ErrorAction SilentlyContinue 
        }
    }
}

# 4. DEEP SCAN: Hidden Worktrees & Project Memory
$searchRoot = "C:\code" # <--- Change this to your main folder if different
Write-Host "`n🔍 Deep scanning $searchRoot for hidden .claude folders..." -ForegroundColor Cyan
$worktrees = Get-ChildItem -Path $searchRoot -Include "worktrees" -Recurse -Hidden -ErrorAction SilentlyContinue | 
             Where-Object { $_.FullName -match "\.claude\\worktrees" }

if ($worktrees) {
    $worktrees | ForEach-Object {
        Write-Host "   - Removing: $($_.FullName)" -ForegroundColor Gray
        Remove-Item -Path $_.FullName -Recurse -Force -ErrorAction SilentlyContinue
    }
} else {
    Write-Host "   - No hidden worktrees found." -ForegroundColor Gray
}

# 5. FINAL SPACE AUDIT
$drive = Get-PSDrive C
$freeGB = [math]::Round($drive.Free / 1GB, 2)
Write-Host "`n✨ CLEANUP COMPLETE!" -ForegroundColor Green
Write-Host "📊 Current Free Space: $freeGB GB" -ForegroundColor White
Write-Host "🚀 IMPORTANT: RESTART YOUR PC NOW to shrink the Pagefile and reclaim the full 15GB." -ForegroundColor Magenta

Notice section 5: it prints reclaim the full 15GB as fixed text. It never measured anything. That one line is the whole reason the numbers never added up.

I ran the script, and in the terminal it showed that around 15GB would be restored after restarting my PC.

I restarted.

I got back about 1GB.

Sometimes it was even just a few hundred MBs.

I ran the script again, and the same thing happened. The terminal would make it look like I was about to recover all this space, but when I checked my actual storage, almost nothing had changed.

At first, I thought Claude had given me a bad script.

But then I looked at my original prompt.

I had asked it to create a script that would clear 15GB every time I ran it.

That was the mistake.

A script cannot clear 15GB when that number was never measured in the first place. The "15GB" was just hardcoded text the script printed every time, no matter what it actually deleted. I was asking it to give me a specific result instead of asking it to first check what was actually taking up space.

So that part was not really Claude's fault. It was mine.

My prompt should have been something like:

Check which folders are using the most storage, identify what can safely be deleted, calculate the real size of those files, and create a script that reports the actual space recovered.

That would have made more sense than telling it, "Give me back 15GB."

I also tried clearing the cache for some of my apps manually, but that created another problem. The apps had to download some of the same information again, which cost me data.

I also ran npm cache clean --force, thinking it would help. npm politely warned me it had disabled its own protections and that the cache rebuilds itself anyway — so that freed almost nothing and just meant re-downloading later. Same lesson as before: clearing caches feels productive but mostly costs you data when everything downloads again.

I deleted ZIP files, old downloads, unused folders, extensions and other things I thought I no longer needed.

Still, the storage situation did not improve as much as I expected.

So today, I decided to put on my man pants and properly investigate the monster I had created.

I now have a better script that checks the available storage before and after the cleanup, instead of promising that it will magically recover 15GB every time.

The improved script

# --- CLAUDE CODE MASTER CLEANUP & OPTIMIZATION (v2) ---

# 0. MEASURE BEFORE — so we can report what we actually freed
$beforeGB = [math]::Round((Get-PSDrive C).Free / 1GB, 2)
Write-Host "📊 Free space before cleanup: $beforeGB GB" -ForegroundColor White

# 1. AUTO-FIX: Set 2GB Node Memory Limit (caps FUTURE Node memory growth)
$varName = "NODE_OPTIONS"
$varValue = "--max-old-space-size=2048"
$currentValue = [Environment]::GetEnvironmentVariable($varName, "User")

Write-Host "`n⚙️  Optimizing Node memory limit (affects future sessions)..." -ForegroundColor Cyan
if ($currentValue -like "*$varValue*") {
    Write-Host "   - ✅ Memory limit already configured." -ForegroundColor Green
} else {
    $newValue = if ($currentValue) { "$currentValue $varValue" } else { $varValue }
    [Environment]::SetEnvironmentVariable($varName, $newValue, "User")
    Write-Host "   - 🛠 Applied 2GB cap to Windows User Variables." -ForegroundColor Yellow
}

# 2. KILL LEAKING PROCESSES
Write-Host "`n🛑 Terminating orphaned Claude & MCP processes..." -ForegroundColor Yellow
$procs = Get-Process -Name "claude", "node" -ErrorAction SilentlyContinue |
         Where-Object { $_.Path -match "anthropic" -or $_.CommandLine -match "mcp" }
if ($procs) {
    $procs | Stop-Process -Force
    Write-Host "   - Closed $($procs.Count) ghost processes." -ForegroundColor Green
} else {
    Write-Host "   - No orphaned processes found." -ForegroundColor Gray
}

# 3. GLOBAL CACHE CLEANUP
$claudePath = "$HOME\.claude"
if (Test-Path $claudePath) {
    Write-Host "`n🧹 Wiping global Claude cache (Logs, History, Temp files)..." -ForegroundColor Cyan
    $folders = "debug", "projects", "file-history", "image-cache", "shell-snapshots", "todos", "plans"
    foreach ($folder in $folders) {
        $subDir = Join-Path $claudePath $folder
        if (Test-Path $subDir) {
            Remove-Item -Path "$subDir\*" -Recurse -Force -ErrorAction SilentlyContinue
        }
    }
}

# 4. DEEP SCAN: Hidden Worktrees
$searchRoot = "C:\code"   # <--- change to your main code folder if different
Write-Host "`n🔍 Deep scanning $searchRoot for hidden .claude worktrees..." -ForegroundColor Cyan
$worktrees = Get-ChildItem -Path $searchRoot -Include "worktrees" -Recurse -Hidden -ErrorAction SilentlyContinue |
             Where-Object { $_.FullName -match "\.claude\\worktrees" }

if ($worktrees) {
    $worktrees | ForEach-Object {
        Write-Host "   - Removing: $($_.FullName)" -ForegroundColor Gray
        Remove-Item -Path $_.FullName -Recurse -Force -ErrorAction SilentlyContinue
    }
} else {
    Write-Host "   - No hidden worktrees found." -ForegroundColor Gray
}

# 5. FINAL SPACE AUDIT — report the REAL delta, not a guess
$afterGB = [math]::Round((Get-PSDrive C).Free / 1GB, 2)
$reclaimedGB = [math]::Round($afterGB - $beforeGB, 2)

Write-Host "`n✨ CLEANUP COMPLETE!" -ForegroundColor Green
Write-Host "📊 Before: $beforeGB GB  |  After: $afterGB GB" -ForegroundColor White
Write-Host "♻️  Actually reclaimed: $reclaimedGB GB" -ForegroundColor White

if ($reclaimedGB -lt 1) {
    Write-Host "ℹ️  Small gain is normal — most space here is cache/logs." -ForegroundColor Gray
    Write-Host "    If your pagefile is system-managed and large, a reboot may free more." -ForegroundColor Gray
}

The difference is small but honest: the new version takes a snapshot before it starts, another at the end, and reports the real difference. No more magic 15GB.

So yey, progress.

At this point, I may still need to increase my storage or finally accept that this PC has served its time and purpose.

Unless someone here knows a safe way to clear Windows storage without deleting important project files or forcing my apps to download everything again.

Has anyone else had their storage disappear while using Claude Code or other AI development tools?