
{/* banner prompt: Clean editorial illustration of a magnifying glass moving over a cloud-shaped invoice, small dials and toggles floating around it (min-instances, CPU, region, disk), a few of them glowing to show waste being switched off, warm white background with teal and orange accents, calm and practical, 16:9. */}

Our monthly Google Cloud bill came in at just over 600 dollars. Nothing was on fire, no traffic had spiked, and no new service had launched. The bill had simply crept up, one reasonable-looking decision at a time.

So we sat down and audited it, line by line. By the end we had a plan that cut the bill by more than half, without leaving the cloud, without moving regions, and without giving up anything we actually used. Almost all of the savings came from understanding *settings* — the dials that cloud platforms leave on their most convenient default rather than their cheapest one.

Here is what we learned.

## Read the bill like a map, not a total

The single most useful thing we did was stop looking at the total and start grouping every line item by what it actually was. Google's cost table breaks charges into dozens of tiny SKUs — "CPU (request-based billing)", "SSD backed PD capacity", "network inter-region data transfer" — and on their own they mean very little. Grouped by *cause*, a shape appears fast.

When we did that, one pattern jumped out immediately:

<Table data={
    {
        headers: ['Where the money went', 'Roughly', 'What it actually was'],
        rows: [
            ['One background workload', 'About 60%', 'A fleet of small agents writing to the database on a timer'],
            ['Web serving', 'A chunk', 'Cloud Run handling real requests'],
            ['Always-on worker', 'Around 50 dollars', 'A container that could never scale to zero'],
            ['One database server', 'Around 90 dollars', 'A virtual machine sitting almost completely idle'],
            ['Small stuff', 'The rest', 'Logs, disks, snapshots, an orphaned IP address']
        ]
    }
} />

The lesson of the audit was almost boring: **one workload was 60% of the bill.** Everything else combined — every website, every API, every bit of storage — was the minority. If you only have time to fix one thing, find your elephant first.

## Cloud Run is cheap, until a setting says otherwise

We love Cloud Run. It scales to zero, you only pay when it runs, and you never patch a server. But "you only pay when it runs" hides two settings that decide whether that promise holds.

### Minimum instances

By default a Cloud Run service scales to zero when no one is using it. Set a minimum number of instances above zero and you are asking Google to keep that many copies warm at all times — which removes cold starts, and bills you around the clock whether or not a single request arrives.

<Table data={
    {
        headers: ['Setting', 'What it does', 'What it costs'],
        rows: [
            ['Min instances = 0 (default)', 'Scales to zero when idle', 'Nothing when idle; a cold start on the first request'],
            ['Min instances = 1 or more', 'Keeps copies always warm', 'You pay for those copies 24/7, including while you sleep'],
            ['CPU only during requests (default)', 'CPU is throttled between requests', 'Cheapest for normal request and response work'],
            ['CPU always allocated', 'CPU keeps running between requests', 'Bills like an always-on VM, not per request']
        ]
    }
} />

We had a couple of services quietly holding a minimum instance warm for a workload that saw almost no traffic. Setting them back to zero cost us nothing but a cold start once in a while, and removed the charge entirely.

### The always-on trap

Here is the sharper lesson. One of our services was not a website at all. It was a background worker that holds a long-lived connection to a message queue and reacts to events. It has no incoming web requests to speak of — just a socket it needs to keep open.

That is exactly the workload Cloud Run is *worst* at. To keep the connection alive, it needs a minimum of one instance and CPU that is always allocated. In other words, it has to behave like a server that never turns off — while being billed as premium serverless compute. It cost around 50 dollars a month to do something a tiny always-on virtual machine, or a container on a machine we already ran, could do for close to nothing.

**The rule we took away:** serverless is brilliant for spiky, request-driven work that can genuinely go to zero. For anything that must stay awake all the time — a queue consumer, a poller, a persistent connection — check whether a small VM you already operate is cheaper. Often it is, by a wide margin.

## When to self-host a database instead of using a managed one

This was the big one, and it is the least obvious.

Managed databases — Cloud SQL, Firestore, DynamoDB and friends — are wonderful. Backups, failover and scaling are handled for you. But many of them bill **per operation**: so much per read, so much per write. That pricing is fantastic when your traffic is small or spiky. It turns brutal when your workload is *chatty*.

Our background fleet was as chatty as it gets. Each agent wrote a small status update to the database on a fixed timer — every 30 to 60 seconds — whether anything had changed or not. Multiply a handful of writes per minute by hundreds of agents across a month and you land at **hundreds of millions of tiny operations**. On per-operation pricing, those cheap little writes added up to the largest single line on the whole bill.

The same writes, sent to a plain MySQL server running on a virtual machine we already operate, cost effectively nothing extra. The disk was already spinning; a few hundred million small writes a month is comfortably within what one modest server handles without noticing.

So when should you reach for each?

<Table data={
    {
        headers: ['A managed database fits when', 'Self-hosting starts to win when'],
        rows: [
            ['Traffic is small, spiky or unpredictable', 'Traffic is steady and high in volume'],
            ['You would rather not run a server at all', 'You already run a VM with spare capacity'],
            ['Per-operation cost is a rounding error', 'Your workload is chatty: many tiny reads and writes'],
            ['You want managed backups and failover', 'You are happy to run your own backups'],
            ['You are early and want to move fast', 'You are steady and want predictable, flat cost']
        ]
    }
} />

There is a second reason we moved this workload onto our own database: **portability.** A plain MySQL server over a standard connection runs anywhere — another cloud, another region, your own hardware. Per-operation managed services are convenient precisely because they lock the shape of your data and your bill to one vendor.

A word of caution, because it cuts both ways: self-hosting means *you* own the backups, the patching and the 3am restart. We did not move a customer-facing production database off its managed home for a few dollars. We moved a high-volume, non-critical, internal workload where the maths was overwhelming and the risk was low. Pick your battles.

Two cheap habits also soften per-operation pricing without moving anything:

- **Write only on change.** A status update that is identical to the last one does not need to be written at all. Debouncing our timer writes alone would have removed most of the volume.
- **Do not read to decide whether to write.** It is easy to "save a write" by reading first — and end up paying for the read instead. On a chatty workload, reads can cost as much as the writes you were trying to avoid.

## Right-size relentlessly

One database server on the bill cost around 90 dollars a month. We logged in to look at it and found the load average sitting at 0.00. Two dedicated CPU cores, 99% idle, around the clock.

We had sized it once, long ago, for a load that never arrived — and then paid for that guess every month since. Swapping it for a smaller, shared-core "burstable" machine — the kind that idles cheaply and borrows extra CPU only when it briefly needs it — cut the compute cost roughly in half. It even came with more memory than before.

The habit worth building: **size machines to what they actually do, measured, not to what you once imagined they might need.** A minute with a load monitor is worth more than an hour of guessing.

## The quiet extras: region, disk, IPs and logs

Once the big items were handled, a set of small ones were each worth a few dollars, and together a meaningful slice.

**Region.** The exact same machine costs noticeably more in some regions than others — a premium of 30 to 40% is common for the more expensive locations. That premium is often worth paying: keeping a database close to your users cuts latency, and moving a production system across the world is risky. But pick your region *on purpose*, knowing what the proximity costs, rather than out of habit.

**Disk tier.** Fast SSD disks cost roughly double a "balanced" disk of the same size. A small database that is mostly idle does not need premium disk performance. Matching the disk tier to the actual workload is an easy, invisible saving.

**Idle IP addresses.** Reserved static IP addresses are billed even when they are attached to nothing. We found one reserved address doing absolutely nothing and released it. Worth a scan.

**Logs.** Log ingestion is free up to a generous monthly allowance, then billed per gigabyte. One noisy service — including a bug that threw the same error thousands of times a day — was pushing us over the line. We added a filter to drop the low-value noise (while keeping real errors) and flagged the bug to fix at the source. Verbose logging is a cost, not just a habit.

## About those "commit and save" discounts

Cloud providers offer real discounts if you commit to a resource for one or three years. They can be worth it for a steady, permanent workload. But read the fine print: the cheap shared-core machines are often *not* eligible, and — importantly — right-sizing first can beat committing. In our case, downsizing an idle machine saved more than a one-year commitment on the oversized one would have. Do the cheap, reversible optimisation before you sign a year-long contract.

## The takeaway

None of this was clever. We did not rewrite anything or adopt a new platform. We read the bill like a map, found the one workload that was most of it, and turned the right dials:

<Table data={
    {
        headers: ['Move', 'Why it worked'],
        rows: [
            ['Group the bill by cause', 'One workload was 60% of it; the rest was noise'],
            ['Mind Cloud Run min-instances and CPU', 'Warm instances and always-on CPU bill 24/7'],
            ['Self-host the chatty database', 'Per-operation pricing punishes high-volume writes'],
            ['Right-size idle machines', 'A 0.00 load average is money burning'],
            ['Sweep the small stuff', 'Region, disk tier, idle IPs and noisy logs add up']
        ]
    }
} />

Cloud platforms are a wall of dials, and the defaults are tuned for convenience and for the provider's revenue — not for your bill. The good news is that the same wall of dials is exactly what lets you fix it. Set a reminder to audit the bill every quarter. The cloud rewards attention, and quietly taxes the lack of it.

*If you run anything in the cloud and have never grouped your bill by cause, that is the single most valuable hour you can spend this month.*


df14e3d9271520b989cd074edc113525f817c67a06a7dcc5b44d3319e182b71f

Practical lessons from auditing a Google Cloud bill: Cloud Run min-instances and CPU billing, when to self-host a database instead of a managed one, and region and machine right-sizing.

A real 600-dollar-a-month cloud bill, audited line by line, and the Cloud Run settings, database choices and machine sizes that quietly drove the cost.

How We Cut Our Google Cloud Bill in Half


{/* banner prompt: A playful but polished 3D clay-render, matte materials in sage green, cream and terracotta, of a stylized detective magnifying glass hovering over a small padlock icon that is cracking open, with a tangled network cable looping around a proxy-server box in the background, soft studio shadows, simple background, 16:9. */}

`yt-dlp` gave us the least helpful error message it has: `HTTP Error 410: Gone`. The standard fix is `yt-dlp -U`. We ran it. Already on the latest stable release. The video was not, in fact, gone — but proving that took three separate bugs stacked on top of each other, and the last one had nothing to do with `yt-dlp` at all.

We were debugging a small local downloader tool — a browser extension that hands a page URL and cookies to `yt-dlp` on the user's own machine, optionally routed through a local HTTP proxy for geo-unblocking. One specific site started failing every time, on a URL that worked fine a week earlier.

## The first clue was buried in `-v`

The plain error told us nothing. Adding `-v` for verbose output surfaced a line that's easy to scroll past:

```
WARNING: [SiteExtractor] The extractor is attempting impersonation, but no
impersonate target is available. If you encounter errors, then see
https://github.com/yt-dlp/yt-dlp#impersonation for information on
installing the required dependencies
```

That's the real signal. A growing number of sites fingerprint the TLS handshake and HTTP/2 frame ordering of incoming requests to tell a real browser apart from a scripted client — even when every header looks identical. `yt-dlp` can spoof a browser's TLS fingerprint via an optional dependency, `curl_cffi`, which wraps `libcurl` with impersonation profiles for Chrome, Safari, Firefox and so on. Without it, some extractors still try the request, get rejected at the TLS layer, and the site's edge returns a generic `410` instead of anything that explains what actually happened. The video was fine. `yt-dlp` just didn't look enough like a browser to be allowed to ask.

## The version window nobody tells you about

The fix looked trivial:

```sh
python3 -m pip install curl_cffi
```

It installed cleanly — `curl_cffi-0.16.0`, the latest release. `yt-dlp` still refused to use it, and `--list-impersonate-targets` came back with every target marked `(unavailable)`. The debug line was the giveaway:

```
[debug] Optional libraries: ... curl_cffi-0.16.0 (unsupported) ...
```

`yt-dlp` doesn't just check that `curl_cffi` is importable — it pins a narrow set of versions it actually trusts, because `curl_cffi`'s impersonation API has changed shape across releases. Digging through the installed `yt-dlp` build (it ships as a zip-app; `python -m zipfile` opens it like any other zip) turned up the exact check:

```python
curl_cffi_version = tuple(map(int, re.split(r'[^\d]+', curl_cffi.__version__)[:3]))

if curl_cffi_version != (0, 5, 10) and not (0, 10) <= curl_cffi_version < (0, 16):
    curl_cffi._yt_dlp__version = f'{curl_cffi.__version__} (unsupported)'
    raise ImportError('Only curl_cffi versions 0.5.10 and 0.10.x through 0.15.x are supported')
```

Latest-and-greatest was one minor version too new. The fix was to pin below the ceiling:

```sh
python3 -m pip install "curl_cffi>=0.10,<0.16"
```

**Lesson:** when a library depends on another native-extension package for an optional feature, don't assume "latest" is "supported" — check for a version gate specifically on the feature you're trying to turn on, not just on whether the import succeeds.

## Collateral damage from `--force-reinstall`

The first install attempt used `--force-reinstall` to make sure the correct version actually took. It did — but it also silently upgraded packages that were already correctly pinned for something else entirely: `certifi`, `cffi`, `markdown-it-py`, and `pygments` all jumped to newer versions than another tool in the same shared Python environment required. `pip` said so plainly, right at the end of the install:

```
ERROR: pip's dependency resolver does not currently take into account all
the packages that are installed. This behaviour is the source of the
following dependency conflicts.
some-other-tool 2.15.0 requires certifi==2026.4.22, but you have
certifi 2026.7.22 which is incompatible.
some-other-tool 2.15.0 requires cffi==2.0.0, but you have cffi 2.1.1 ...
```

None of those four packages actually needed upgrading — `curl_cffi`'s own requirement (`cffi>=2.0.0`, `certifi>=2024.2.2`) was already satisfied by the versions in place. `--force-reinstall` doesn't just reinstall the package you named; it re-resolves and reinstalls its entire dependency subtree, and when it does that it grabs the latest version satisfying each constraint rather than leaving an already-satisfied pin alone. In a shared base environment with several unrelated tools installed, that's a quiet way to break something you weren't even looking at.

The fix was to pin those four straight back:

```sh
python3 -m pip install "certifi==2026.4.22" "cffi==2.0.0" \
  "markdown-it-py==4.0.0" "pygments==2.20.0"
```

**Lesson:** avoid `--force-reinstall` in a shared or base Python environment. If you need a specific version of one package, ask for exactly that (`pip install "pkg==x.y.z"`) rather than forcing a full dependency re-resolve you don't control.

## A new error, and a wrong theory

With the right `curl_cffi` version in place, the impersonation warning was gone — replaced by a new one, appearing on every single attempt:

```
SSLError: Failed to perform, curl: (35) TLS connect error:
error:00000000:invalid library (0):OPENSSL_internal:invalid library (0)
```

This looks exactly like a known class of `curl_cffi` bug: its bundled BoringSSL build can clash with another OpenSSL-family library already loaded in the same Python process — commonly `cryptography`, pulled in transitively by something unrelated like browser-cookie decryption support. The natural fix is isolation: a clean virtual environment with only `yt-dlp` and `curl_cffi`, nothing that could drag in a conflicting crypto library.

We built that environment. Same error, 100% reproducible, in complete isolation — no `cryptography`, no `secretstorage`, nothing else installed at all.

That result was more useful than a fix would have been. A clean-environment reproduction rules out an entire category of theories in one shot. It wasn't a Python packaging conflict. It had to be something outside Python's import graph.

## Stripping back to the dumbest possible test

The next step was to remove every layer of abstraction and test the actual thing that was failing: a TLS handshake over the proxy. Not `curl_cffi`. Not even `yt-dlp`. Plain, unimpersonated `requests`:

```python
import requests
r = requests.get("https://www.example.com",
                  proxies={"https": "http://127.0.0.1:8082"})
```

Same SSL error. Against a domain with nothing to do with the original site. That was the moment the whole investigation flipped: this was never a `curl_cffi` bug, or even a Python bug. Something about the proxy itself was breaking HTTPS.

Raw `curl` confirmed it in the plainest terms available:

```
* CONNECT tunnel established, response 200
> Client hello (1)
* OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to www.example.com:443
```

The proxy's `CONNECT` tunnel came up cleanly — a `200 Connection Established` — and then the TLS handshake died immediately afterward, for every client, on every site. Nothing about `curl_cffi`'s TLS fingerprint mattered; the tunnel itself wasn't relaying bytes correctly once real TLS traffic started flowing through it.

The proxy client had several selectable exit gateways by region. Switching from one region to another and rerunning the exact same `curl` command fixed it instantly — clean `200`, valid response, every time. The original gateway node was in a broken state for HTTPS relaying specifically; nothing in our code, `yt-dlp`, or `curl_cffi` was ever going to fix that from the client side.

## What actually shipped

Three real problems, three real fixes, none of them where the first error message pointed:

<Table data={
    {
        headers: ['Symptom', 'Looked like', 'Actually was'],
        rows: [
            ['HTTP 410: Gone', 'Stale yt-dlp / dead video', 'Site requires TLS impersonation'],
            ['curl_cffi "(unsupported)"', 'Broken install', "Version above yt-dlp's pinned ceiling"],
            ['Unrelated tool broke after install', 'Unrelated bug', '--force-reinstall re-resolved shared deps'],
            ['SSL "invalid library" error', 'curl_cffi vs OpenSSL clash', 'Proxy gateway failing the TLS relay'],
        ]
    }
} />

The lasting fix was to isolate `curl_cffi`-enabled `yt-dlp` into its own virtual environment — so a future dependency bump anywhere else on the machine can never touch it again — and to symlink the `PATH`-resolved `yt-dlp` at that environment's build, so every caller picks it up without extra configuration.

## The general shape of this kind of bug

None of the individual fixes here are exotic. What made this one take longer than it should have was trusting each error message's own framing for too long:

- **"410 Gone" told us the video was gone.** It wasn't — it was an anti-bot response wearing the shape of a different error.
- **"unsupported" told us the install was broken.** It wasn't broken, it was one version too new for a pin we didn't know existed.
- **"invalid library" pointed straight at `curl_cffi` and OpenSSL.** It was neither — it was a proxy gateway with a bad TLS relay.

The pattern that actually broke each false lead was the same one every time: reproduce with the fewest possible moving parts. A clean virtual environment ruled out the packaging theory. Plain `requests` with no impersonation ruled out `curl_cffi` entirely. Raw `curl` against an unrelated domain ruled out the target site. Each step removed one whole category of suspects instead of guessing at the next fix — and the actual root cause, when it finally showed up, wasn't in any of the code we'd been staring at.


9fa2ef35cdb16bce3f05bf518227a3d6de0d42440772c0f4c3b4eaddebedb611

How we debugged a yt-dlp 410 Gone error that wasn't staleness: curl_cffi TLS impersonation, a strict version-pinning gotcha, a --force-reinstall dependency mishap in a shared Python environment, and a proxy gateway failure that mimicked a library bug.

A yt-dlp download kept failing with 'HTTP Error 410: Gone' even on the latest version. The real cause was three layered problems stacked on top of each other: missing TLS impersonation, a narrow curl_cffi version-compatibility window, and an unrelated proxy gateway fault that looked exactly like a library bug.

Debugging a Fake 410: yt-dlp, curl_cffi, and a Proxy That Lied


{/* banner prompt: A vivid isometric infographic scene of a small friendly robot (an AI agent) reaching toward a laptop with a wrench in one hand, while a large shield-shaped antivirus icon looms over it, its glowing eye watching. Three of the robot's tools (a floppy disk, a gear, and a key) are shown mid-air, each caught in a translucent red "quarantined" bubble launched from the shield. Clean light-gray background, sharp isometric perspective, muted blue-and-red palette, technical but approachable, no readable text or logos. */}

We gave an AI agent real hands on a Windows machine: reach it over the network, install itself, register a background service, and get to work unattended. Straightforward, we thought — until the machine had Bitdefender GravityZone on it, and the agent could see the machine perfectly well but couldn't actually *do* anything to it. Not because of a bug in our code. Because an endpoint protection product was quietly erasing our binary and blocking Windows' own service-management APIs, without a single visible error pointing at the real cause.

This is the anatomy of that block, three layers deep, and the exact GravityZone settings that let an automated agent actually operate on a managed endpoint.

## Layer 1: the binary just disappears

The first symptom looked like a download bug. Our install step used a plain `WebClient.DownloadFile` to fetch the agent binary, and it failed with a generic wrapper exception: *"An exception occurred during a WebClient request."* No useful detail.

The real cause was buried in `.Exception.InnerException`, only visible with `Format-List * -Force`:

```
System.UnauthorizedAccessException: Access to the path
'...\agent.exe' is denied.
```

Access denied, on a fresh download, to a brand-new file, in a folder we owned. Ruling out the obvious suspects — TLS, proxy, file locks, ACLs — took a while, because every one of them came back clean. What finally confirmed it: a pure local `Rename-Item` on the same filename, no network involved at all, threw the identical `UnauthorizedAccessException`. That ruled out anything related to how the file arrived (download provenance, Mark-of-the-Web, whatever) and pointed at one thing: **something was reacting to the filename itself, the instant it appeared on disk.**

`Get-CimInstance -Namespace root/SecurityCenter2 -ClassName AntiVirusProduct` gave the answer: Bitdefender Endpoint Security Tools, centrally managed through GravityZone. It was quarantining the binary on write, silently, with no local error dialog and no entry in the Windows Application or System event logs — Bitdefender logs to its own console, not to Windows, so `Get-WinEvent` finds nothing. From the process's point of view it just looks like the filesystem refused to cooperate.

## Layer 2: even SYSTEM can't create a service

Once we worked around the file-quarantine (more on the fix below), the same binary would download and sit on disk just fine. Installing it as a Windows service was the next wall:

```
Error: install service (run as Administrator if not elevated): Access is denied.
```

Our first assumption was a permissions problem in our own service-install code. To rule that out, we dropped straight to the raw OS tool, running as `nt authority\system`:

```
sc.exe create myagent binPath= "C:\Path\To\agent.exe" start= auto
[SC] CreateService FAILED 5:
Access is denied.
```

`SYSTEM` failing `CreateService` with error 5 is not a permissions problem — SYSTEM has unrestricted access to the Service Control Manager by definition. Something was intercepting the call itself. That's a signature of behavioral/EDR monitoring, not access control: GravityZone's **Advanced Threat Control** module watches for exactly this pattern — a process registering itself as a persistent Windows service — and treats it as a textbook malware-persistence technique, regardless of whether the binary passed the earlier file scan.

## Layer 3: the registry write underneath it

`CreateService` isn't a single atomic action from Windows' perspective — it writes a new key under `HKLM\SYSTEM\CurrentControlSet\Services`. That key path falls under GravityZone's **Sensitive Registry Protection**, a separate sub-feature of Advanced Threat Control that specifically guards persistence-related registry locations and can kill the offending process outright. Two independent enforcement layers were converging on the same operation for two different reasons: one watching "is this process trying to persist," the other watching "is this process touching a sensitive registry key." Either one alone is enough to block a legitimate service install.

## Where "just add an exclusion" falls short

The standard advice for AV false positives is an exclusion: GravityZone's **Antimalware → Exclusions** tab lets you add a Folder, File, Process, or Extension exclusion, and pick which scanning **Modules** it applies to (on-access, on-demand, and — separately — **ATC/IDS**, GravityZone's label for Advanced Threat Control and its Intrusion Detection System). We added both a folder and a process exclusion with all modules selected, including ATC/IDS.

It stopped Layer 1. It did **not** stop Layer 2 or Layer 3. Sensitive Registry Protection turned out to be its own gate, evaluated independently of the Exclusions list — an exclusion tells the scanner to skip a file or process, but it doesn't override a behavioral rule that's watching a system resource (the registry key) rather than the process that's touching it.

## The actual fix

Two policy settings, both under **Antimalware → On-Execute → Advanced Threat Control** in the GravityZone policy:

<Table data={
    {
        headers: ['Setting', 'Default', 'Changed to'],
        rows: [
            ['Action for infected applications', 'Block / Kill process', 'Report only'],
            ['Sensitive Registry Protection', 'Block / Kill process', 'Report only'],
        ]
    }
} />

"Report only" keeps GravityZone watching and logging — you still get visibility into what the agent is doing on the endpoint — but stops it from silently killing the process or deleting the file before the operation can complete. We kept the folder and process exclusions from earlier too, as a belt-and-suspenders measure for the plain file-scan layer, but the two "Report only" toggles are what actually unblocked service installation and registry writes.

This is a real trade-off, not a free lunch. Loosening ATC's response mode on a managed endpoint reduces the odds it auto-remediates a genuine compromise on that box. The right scope for this change is narrow: apply it via a dedicated policy assigned only to endpoints that are supposed to run this kind of automation, not your default fleet-wide policy — and keep "Report only" instead of disabling the module outright, so you still see every detection GravityZone would otherwise have acted on.

## What to check if your automation is being silently eaten

If a process on a GravityZone-managed Windows box can create files but can't seem to keep them, or can enumerate/read everything but can't write to the service registry or call `CreateService`, even running as SYSTEM:

1. **Get past the wrapper exception.** .NET's `WebClient`/`HttpClient` errors and generic "Access is denied" messages hide the real exception. Always drill into `.Exception.InnerException` (`Format-List * -Force` in PowerShell) before concluding it's your own code.
2. **Rule out provenance with a pure local operation.** If `Rename-Item` on the same destination filename also fails with no network involved, the block is about the file/process identity, not how it arrived.
3. **Identify the real AV product**, don't assume it's Windows Defender. `Get-CimInstance -Namespace root/SecurityCenter2 -ClassName AntiVirusProduct` tells you what's actually active — often a third-party product has silently superseded Defender, and Defender's own cmdlets (`Get-MpPreference`) will fail with a generic COM error when that's the case.
4. **Test service creation with the raw OS tool**, not your own code. `sc.exe create` failing under SYSTEM isolates the problem to the platform/EDR layer, not your service-install logic.
5. **Don't stop at Exclusions.** A file/process exclusion silences on-access scanning, but a dedicated behavioral rule — like registry-key protection — can still be watching the *resource* rather than the *process*, and needs its own toggle.

The broader lesson: modern EDR products don't have one enforcement point, they have several, stacked on different signals — file content, process behavior, and resource access — and each one can independently veto the same operation for a different reason. Debugging "access denied" on a managed endpoint means finding out which layer is actually talking, not just the first one you can reproduce.

c7a32d8904e2b087f20b4cdaf8ed027394a9e954e6a0c239b6c3116bdc9a7043

How Bitdefender GravityZone silently blocked an AI agent's own binary, service installation, and registry writes on Windows, and the exact policy settings that fixed it.

Our AI ops agent could reach a Windows box over the network but couldn't install itself, start its own service, or even keep its own binary on disk. The culprit: Bitdefender GravityZone silently eating it, one enforcement layer at a time.

When Your Antivirus Fights Your AI Agent: A Bitdefender GravityZone War Story


{/* banner prompt: An editorial-illustration banner, 16:9: a large softly glowing translucent brain — a powerful AI — held steady and measured by clean, tangible engineering instruments: a spirit level resting across the top with a centered bubble, a ruler alongside, and a pair of calipers. Bright, optimistic, minimal composition on an off-white background with soft shadows; a muted accent palette of sage green, terracotta, and navy. Precise, calm, trustworthy mood. No lettering, no text. */}

Every few weeks, a more capable model lands. Fable 5, GPT-5.6 Sol, Kimi K3 — each genuinely sharper than the last, each able to hold more, reason further, write cleaner code. It is a remarkable thing to watch. It is also, on its own, not enough.

Power and reliability are different axes. A more powerful model still runs out of context on a long enough document. It still loses the thread somewhere in the middle of a big conversation — the "lost in the middle" problem does not vanish just because the window grew. In a long agentic session it still quietly forgets a decision it made an hour ago. And most awkward of all: it states the wrong thing with exactly the same fluent confidence as the right thing. The tone never wavers. The certainty is not calibrated to the correctness.

That last point is the one that matters for anyone putting AI to work. **A model's internal sense of "done" is not a measurement. It is a vibe.** And you cannot manage — or ship, or trust — what you cannot measure.

## Engineering already solved this once

Physical engineering did not become reliable because craftsmen got more talented. It became reliable because it got *instruments*. A ruler. A set of scales. A spirit level. A multimeter. Objective, external, repeatable tools that return an answer independent of how the person holding them feels.

You do not ask the carpenter whether the shelf is level. You put a spirit level on it and look at the bubble. The bubble does not care how many shelves the carpenter has hung. That is the whole point: the measurement lives *outside* the person, so it is immune to the person's fatigue, memory, and overconfidence.

AI needs the same thing — external, quantitative, tangible checks that return a hard answer the model cannot talk its way around. Something the AI can **run**, not something it has to **believe**.

A good measurement for AI has a few properties:

- **Deterministic** — same input, same answer, every time.
- **Numeric or binary** — a pass or fail, a count, a fingerprint. Not a paragraph of reassurance.
- **External to the model** — it lives outside the context window, so it cannot be forgotten or drifted away from.
- **Cheap** — cheap enough to run on every single change, not only when someone remembers.
- **Machine-readable** — so the AI itself can call it, read the result, and act on it.

## A worked example: our deployment guard

We build software with AI in the loop every day, and the single scariest moment is deployment. Did that change actually land correctly? An AI — or a human — can *say* "deployed successfully." That sentence is a vibe. So we gave the deploy a ruler instead.

It is a small tool we call `deploy-checks`. Before and after a release it verifies the live system against a written contract and returns a number: `9/9 passed, exit 0` — or a red line and `exit 1`. No prose. No confidence. No memory. Just the reading.

Here is the tangible part — what it actually measures:

<Table data={
    {
        headers: ['Check', 'What it returns', 'What it catches'],
        rows: [
            ['Token fingerprint match', 'sha8:9c56571d == sha8:9c56571d', 'A shared secret drifting or vanishing across services'],
            ['Permission grant', '1 grant row, or 0', 'A route that returns 403 to everyone before the controller runs'],
            ['Endpoint contract', 'HTTP 400 (want != 401)', 'A fail-closed guard silently rejecting valid callers'],
            ['Health and version', 'exit 0, or exit 1', 'A crashed, stale, or half-promoted release']
        ]
    }
} />

None of these ask the model to *recall* anything. The token check does not trust that the secret is right; it computes a fingerprint of each copy and compares them — match, or no match. The grant check does not assume the permission was set; it counts the row in the database — one, or zero. The endpoint check does not believe the guard works; it sends a real request and reads the status code.

And these are not hypothetical. Every check on that list exists because it caught a real, live production failure. A shared secret silently dropped out of an environment file, and every sign-in across three products started failing — a fingerprint comparison catches that in a single run, where no amount of model cleverness would "remember" it had gone wrong. A permission grant went missing, and an admin page returned "forbidden" to everyone — a row count catches that instantly. These are exactly the kind of quiet, confident-looking failures that slip past a tired engineer and an eloquent model alike.

The crucial move is this: **the AI does not decide the deploy is healthy. It runs the ruler and reads the number.** "I think it is fine" becomes "9 of 9, exit 0." And when the number is bad, the same tool refuses to promote the release and rolls it back automatically. The measurement does not merely inform the decision — it *gates* the action.

## Why stronger models need this *more*, not less

It is tempting to assume better models need fewer guardrails. The opposite is true. The more capable the model, the bigger and less-supervised the task we hand it. You babysit a weak model line by line; you hand a strong agent an entire deployment. The blast radius of an *unmeasured* mistake grows with the model's autonomy. The measurement is the seatbelt that lets you drive faster — remove it and you do not go faster, you just crash harder.

There is a second, quieter payoff. A good ruler is **model-agnostic**. A fingerprint match is true whether Fable 5, GPT-5.6 Sol, or next year's model produced the change. Your investment in measurement compounds; your investment in any single model depreciates the day the next one ships. Build the instruments once, and every future model gets safer for free.

## The takeaway

Stop waiting for the model that never forgets. It is not coming — and even if it did, you would still want to *verify* rather than *trust*, because that is simply what responsible engineering is.

Build the rulers instead. Wrap your AI in tangible, quantitative checks: tests, type-checks, fingerprints, health probes, contract assertions, row counts. Give the model something real to measure against, and let the number — not the vibe — decide what ships.

That is the philosophy behind every guard we build, for our own stack and, increasingly, for the businesses that want AI in their pipeline without handing it the keys unmeasured. Powerful is wonderful. But measurable is what lets you sleep.

80bd37051d17be94043e76dce40d57062b6ff328c651265724911b452c51a8cd

Why powerful LLMs still need external, quantitative checks, and how a deterministic deployment guard gives AI a tangible ground truth to verify its own work.

Frontier models keep getting more powerful, and they still forget, drift, and run past their context. The fix is not a bigger model; it is giving AI a tangible, quantitative ground truth to measure against. Here is how our deployment guard does exactly that.

Measurable Beats Powerful: Grounding AI in Tangible Checks

{/* banner prompt: A paper collage illustration with a tangible, handcrafted feel, showing layered cutouts of a browser window (AI agent) and a network file cabinet, connected by a paper bridge with a keyhole representing a secure API, with visible paper textures and soft drop shadows to create depth, in a palette of muted craft paper colors, 16:9. */}

## The Problem

**Claude Cowork** is a desktop application, but it ships with a built-in sandbox. You can toggle the sandbox off in settings — and technically, it could access an SMB/CIFS network share on the same machine or LAN. Yet even with it disabled, accessing a network drive remains out of reach. This is not an oversight; it is a deliberate design decision by Anthropic. An agent with unconstrained access to mounted network shares can do real damage if it misinterprets an instruction or hallucinates a path — deleting a client folder, overwriting an authoritative document, or crawling terabytes of data it was never meant to touch.

The constraint is reasonable. But it creates a practical gap: many businesses keep authoritative files on a local network share — accounting records, client folders, scanned documents. If the AI agent cannot reach those, you end up copy-pasting content manually, which defeats the purpose.

The solution is not to fight Anthropic's design — it is to work within it. An **HTTP API in front of your file share** is something every AI agent already knows how to call. You define exactly which operations are exposed (list, read, write — but not delete). The agent gets the access it needs; you keep meaningful guardrails in place.

## The Solution: HTTP File Server as a Gateway

The key insight is that **any HTTP server sitting in front of your network share immediately makes it universally reachable** — from any network, any device, any AI agent that can make HTTP requests. No VPN. No SMB port forwarding. No credentials beyond a bearer token.

We used [FileBrowser Quantum](https://github.com/gtstef/filebrowser), a self-hosted file manager that exposes a clean REST API. It mounts your network shares as named "sources" and lets you list, read, search, download, and write files through standard HTTP calls.

---

## Architecture

```
┌─────────────────────────────────────────────────────────────┐
│  Office / LAN                                               │
│                                                             │
│  \\fileserver\data   (SMB/CIFS)                             │
│          │                                                  │
│          │  mount                                           │
│          ▼                                                  │
│  Linux VM  /srv/nas_data                                    │
│          │                                                  │
│          │  volume mount                                    │
│          ▼                                                  │
│  ┌──────────────────────┐                                   │
│  │  FileBrowser Quantum │  :8080                            │
│  │  Docker container    │                                   │
│  └──────────┬───────────┘                                   │
│             │                                               │
│             ▼                                               │
│  nginx  :443  ──── Cloudflare ────▶  files.example.com     │
└─────────────────────────────────────────────────────────────┘
                                            │
                         ┌──────────────────┤
                         │                  │
                         ▼                  ▼
              Claude Code / API      Claude Desktop (Windows)
              (direct HTTP calls)    ┌────────────────────┐
                                     │  filebrowser-mcp   │
                                     │  local Node.js     │
                                     │  stdio MCP server  │
                                     └────────────────────┘
```

The file server host can be set up in two ways:

- **Cloud VM with VPN or peering into the LAN** — the VM mounts the SMB share over a private tunnel; only the HTTPS endpoint is public-facing.
- **Office server with a port exposed** — FileBrowser runs directly on a machine that already has access to the share; nginx (or a reverse proxy like Cloudflare Tunnel) exposes only port 443 to the internet.

Either way, FileBrowser Quantum runs as a Docker container and mounts the share as a local path. nginx sits in front, terminates TLS via Cloudflare, and enforces an IP allowlist. The whole stack is reachable at `https://files.example.com`.

AI agents on any network — a cloud VM, a remote laptop, a Windows desktop — reach the file server through that HTTPS endpoint.

---

## Setting Up FileBrowser Quantum

### 1. Mount the SMB share on the Linux host

```bash
# /etc/fstab entry
//192.168.1.100/data  /srv/nas_data  cifs  credentials=/etc/smbcredentials,uid=1000,gid=1000,file_mode=0664,dir_mode=0775  0  0
```

The `uid`/`gid` and mode flags are important — they ensure the Docker container (running as a non-root user) can both read and write files.

### 2. docker-compose.yaml

```yaml
services:
  filebrowser:
    image: gtstef/filebrowser:stable
    container_name: filebrowser
    ports:
      - "8080:80"
    volumes:
      - /srv/nas_data:/nas:rw
      - /opt/filebrowser/data:/config
    environment:
      - FB_DATABASE=/config/database.db
      - FB_CONFIG=/config/config.yaml
    restart: unless-stopped
```

### 3. config.yaml — define sources

```yaml
sources:
  - name: main
    path: /nas
```

You can define multiple sources if you have more than one share.

---

## REST API at a Glance

Once running, the API is straightforward:

```bash
TOKEN="<your-jwt-token>"

# List a folder
curl "https://files.example.com/api/resources?source=main&path=/CLIENTS" \
  -H "Cookie: filebrowser_quantum_jwt=$TOKEN"

# Read a text file
curl "https://files.example.com/api/resources?source=main&path=/CLIENTS/acme/notes.txt&content=true" \
  -H "Cookie: filebrowser_quantum_jwt=$TOKEN"

# Download a binary file (PDF, xlsx, etc.) — note: file= not path=
curl "https://files.example.com/api/resources/download?source=main&file=/CLIENTS/acme/report.xlsx" \
  -H "Cookie: filebrowser_quantum_jwt=$TOKEN" \
  --output report.xlsx

# Search by filename
curl "https://files.example.com/api/tools/search?source=main&query=tax+return+2024" \
  -H "Cookie: filebrowser_quantum_jwt=$TOKEN"

# Write a file
curl -X POST "https://files.example.com/api/resources?source=main&path=/CLIENTS/acme/summary.txt&override=true" \
  -H "Cookie: filebrowser_quantum_jwt=$TOKEN" \
  -H "Content-Type: text/plain" \
  --data "AI-generated summary goes here"
```

> **Gotcha:** The download endpoint uses `file=` as the query parameter, not `path=`. Using `path=` returns `{"status":400,"message":"no files specified"}`. This inconsistency is worth documenting — it tripped us up initially.

---

## Security Measures

Opening file server access to the internet requires deliberate controls. Here is what we applied, from most to least important.

### 1. Scoped, long-lived JWT tokens

FileBrowser Quantum supports issuing named API tokens with explicit permission sets embedded in the JWT payload. We created a dedicated `ai` user with only the capabilities the agent actually needs:

```json
{
  "Permissions": {
    "api":      true,
    "modify":   true,
    "create":   true,
    "download": true,
    "share":    true,
    "delete":   false,
    "admin":    false
  }
}
```

**Delete is disabled.** An AI agent that can delete files is a data-loss risk — one hallucinated path and important client files are gone. Write access is sufficient for almost every automation use case. If you genuinely need deletion, do it through a separate, human-triggered workflow.

The token is set to expire in ~3 years. Long enough that it does not need babysitting, short enough that it will eventually rotate.

### 2. Removing delete — the BoltDB patch

FileBrowser Quantum stores user records in a BoltDB (key-value) database. The standard HTTP API for updating user permissions (`PUT /api/users?id=N`) had a quirk in our version: it always reset all permissions to false. We had to patch the database directly.

We wrote a small Go script that:
1. Stopped the Docker container to release the exclusive BoltDB lock.
2. Opened the database directly using the `bbolt` library.
3. Located the user record by its big-endian uint64 key.
4. Decoded the JSON user record, set `permissions.delete = false`, and cleared the `tokens` field (to invalidate any old tokens that still had delete enabled).
5. Wrote the record back, verified it in the same transaction, then restarted the container.

The `tokens` field step is critical. FileBrowser embeds the full permission set inside the JWT itself. If an old token with `delete: true` is still stored in the user record, the server restores those permissions on startup — overriding your DB change. Clearing `tokens` forces the server to issue fresh tokens reflecting the updated permissions.

### 3. nginx IP allowlist

The public URL is fronted by nginx, which checks the real client IP (passed through by Cloudflare via `X-Forwarded-For`) against an allowlist:

```nginx
geo $allowed_ip {
    default         0;
    200.0.13.10    1;   # office static IP
    2004:ab8::/48   1;   # authorised IPv6 prefix
}

server {
    listen 443 ssl;
    server_name files.example.com;

    if ($allowed_ip = 0) {
        return 403;
    }

    location / {
        proxy_pass http://127.0.0.1:8080;
    }
}
```

If a request comes from an unknown IP — even with a valid token — nginx returns 403 before FileBrowser ever sees the request. This means a leaked token is useless from outside the authorised IPs.

For AI agents running on cloud VMs, add their static IPs or CIDR prefix to the allowlist.

### 4. HTTPS only via Cloudflare

All traffic goes through Cloudflare, which handles TLS termination and provides DDoS protection. The origin (nginx) only accepts connections from Cloudflare's IP ranges, so the raw VM IP is not directly reachable on port 443.

---

## Wiring It Into Claude Desktop via MCP

For Claude Desktop on Windows (where you want the agent to work with local files after downloading them), we added a local [MCP](https://modelcontextprotocol.io/) server. The MCP server is a small Node.js process that wraps the FileBrowser HTTP API as MCP tools, communicating with Claude Desktop over stdio.

`claude_desktop_config.json`:
```json
{
  "mcpServers": {
    "workspace": {
      "command": "C:\\Program Files\\nodejs\\node.exe",
      "args": ["C:\\Tools\\filebrowser-mcp\\index.js"],
      "env": {
        "FILEBROWSER_URL": "https://files.example.com",
        "FILEBROWSER_TOKEN": "<token>"
      }
    }
  }
}
```

The MCP server exposes these tools to the agent:

<Table data={
    {
        headers: ['Tool', 'Purpose'],
        rows: [
            ['fs_list_sources', 'List available drives'],
            ['fs_list_folder', 'Browse a folder'],
            ['fs_read_file', 'Read text file content'],
            ['fs_download_file', 'Download binary file to local temp folder'],
            ['fs_search_files', 'Search by filename'],
            ['fs_get_file_metadata', 'Get size / date / type'],
        ]
    }
} />

The key tool here is `fs_download_file`. Claude's `web_fetch` tool cannot pass custom headers, so it cannot supply the auth cookie. The local MCP server, running as a native process with the token in its environment, has no such restriction — it fetches the file over HTTPS and saves it to the Windows temp folder, returning the local path so Claude can then read it with normal file tools.

```javascript
async function downloadFile({ source, path, save_to }) {
  // note: download endpoint uses file= not path=
  const url = `/api/resources/download?source=${encodeURIComponent(source)}&file=${encodePath(path)}`;
  const res = await fbFetch(url);
  const buffer = await res.arrayBuffer();
  const filename = path.split("/").pop();
  const localPath = save_to || join(tmpdir(), filename);
  writeFileSync(localPath, Buffer.from(buffer));
  return { source, path, filename, local_path: localPath, size_bytes: buffer.byteLength };
}
```

---

## Why This Works Better Than Alternatives

Claude does provide built-in connectors for services like Dropbox and OneDrive. In practice, though, most organisations have multiple accounts spread across different purposes — a Dropbox for one team, an OneDrive for another, a legacy NAS for a third. Each connector needs its own authorisation flow and only covers one account at a time.

An HTTP file server flips this: you mount every share behind a single endpoint, define named sources, and the agent accesses all of them through one token and one API. No per-account OAuth dance, no switching contexts.

<Table data={
    {
        headers: ['Approach', 'Trade-off'],
        rows: [
            ['VPN', 'Requires credential management; gives the agent broad network access'],
            ['Cloud sync connectors (Dropbox, OneDrive)', 'One connector per account; multiple accounts across teams means multiple authorisation flows to manage'],
            ['Direct SMB exposure', 'SMB was not designed for internet exposure; serious security risks'],
            ['HTTP file server (this setup)', 'Single endpoint, multiple sources; scoped token; IP allowlist; works for cloud storage and on-prem shares alike'],
        ]
    }
} />

The HTTP approach is universally accessible because every AI agent — whether it is Claude Code running on a cloud VM, Claude Desktop on a Windows workstation, or an API-driven automation script — already knows how to make HTTP requests. No special drivers, no OS-level mounts, no VPN configuration.

---

## Summary

If you have an office NAS that AI agents need to reach:

1. **Deploy FileBrowser Quantum** (or any HTTP file server) on a VM that can mount the share.
2. **Issue a scoped token** — read/write, no delete, fixed expiry.
3. **Lock it down at the network layer** — nginx IP allowlist, TLS via a CDN.
4. **For Claude Desktop**, add a local MCP server that wraps the HTTP API, so the agent can download binary files it could not otherwise fetch (PDFs, spreadsheets, etc.).

The result is an AI agent that can list folders, search for files, read documents, write results back, and download any file type — from any network — without ever needing a VPN or direct NAS access.

19d70f3a5c423474d12673586217abe4f6503a0656277adc7416c5cb5fed4a42

A practical walkthrough of deploying FileBrowser Quantum as an HTTP gateway over SMB network shares, issuing scoped long-lived JWT tokens, and wiring the API into Claude Desktop via a local MCP server — so AI agents can access office files without VPN or physical LAN access.

Claude Cowork (and similar browser-based AI agents) can browse web pages but cannot reach SMB/CIFS network shares. Here is how we wrapped our office NAS in an HTTP API so the agent can list, read, search, and write files from anywhere — with proper security controls.

Giving AI Agents Access to Network Drives via an HTTP File Server

{/* banner prompt: A minimal Scandinavian-style office scene with soft, natural light from a window; on a clean light oak desk, an elegant metal padlock and a small white block with a Google Cloud logo are physically separated by a translucent orange glass cube, creating a sense of a clear, frustrating obstacle.

Additional instructions: an unitree style robot as a runner */}

# From App Engine to Cloud Run: A New Chapter

For a long time, Google App Engine (GAE) has been my go-to for hosting web applications. It’s reliable and handles the heavy lifting of infrastructure. However, Google’s **Cloud Run** has emerged as a compelling successor that promises even better cost efficiency and flexibility.

## What is Cloud Run?

Cloud Run is a fully managed compute platform that automatically scales your stateless containers. Unlike App Engine, which has specific language runtimes, Cloud Run allows you to run **any** language, library, or binary because it is built on the **Knative** (Kubernetes-based) standard.

### Benefits vs. App Engine

1.  **Scale to Zero:** Cloud Run is truly "pay-as-you-go." If no one is using your app, it scales to zero instances, and you pay $0. App Engine's standard environment does this too, but Cloud Run's pricing model is often more granular and cheaper for low-to-medium traffic.
2.  **Containerization:** Since it uses Docker containers, the "it works on my machine" guarantee is much stronger. No more worrying about App Engine-specific constraints or proprietary APIs.
3.  **Concurrency:** A single Cloud Run instance can handle up to 250 requests simultaneously, whereas App Engine instances are often more restricted in how they handle concurrent loads.

## Why the "Trading Journal" Project?

For a project like a **Trading Journal**, Cloud Run is a perfect fit:
*   **Cost Efficiency:** This trading tool is built for a small audience and may get very few visitors, if any. Cloud Run is a good fit because it can scale to zero when nobody is using it, keeping the monthly cost minimal.
*   **Fast Iteration:** If this tool ever evolves, the container-based workflow will make it easier to roll out new calculation logic or UI improvements.
*   **Portability:** If we ever need to move to a full Kubernetes cluster or another cloud provider, the Docker image is already built and ready.

---

# The "Gotcha": Domain Mapping & The 24-Hour Wait

After successfully deploying the Trading Journal to Cloud Run, I hit a major roadblock: **Domain Mapping.** 

I mapped [`sprolo.tyosis.com`](sprolo.tyosis.com) to the service, and then... nothing. I waited 24 hours, and the status remained stuck on **"Waiting for certificate provisioning."**

### How it works under the hood
Cloud Run uses a Kubernetes-based technology stack. The domain mapping service behaves similarly to a **Certbot** container. To provide you with a managed SSL certificate, Google must prove to the Certificate Authority (CA) that it controls your domain. It does this via an ACME challenge: the CA looks for a specific token at your domain's IP address.

### Why the mapping failed
The issue was **Cloudflare**. My domain was using Cloudflare's "Proxy" mode (the Orange Cloud). 

When Google's verification bot tried to check the domain, it didn't see the Google servers; it saw **Cloudflare's edge nodes**. Because Cloudflare was hiding the actual IP from the internet, the authentication and validation process could never finish. Google was effectively shouting into a void, waiting for a challenge response that Cloudflare was intercepting.

### The Fix: The "Grey Cloud" Strategy

To solve this, you have to temporarily "step out of the way" of the SSL handshake:

1.  **Grey Cloud the Record:** In Cloudflare DNS, change the `sprolo` CNAME record from "Proxied" to **"DNS Only"** (Grey Cloud). This exposes the `ghs.googlehosted.com` target directly to the public internet.
2.  **Wait for Google:** Once the proxy is off, Google's verification bot can see the challenge data. In my case, the "Ready" status appeared within about 20 minutes after being stuck for a day.
3.  **Re-enable Proxy:** After the Cloud Run domain status shows a green checkmark and "Ready," you can flip the Orange Cloud back on in Cloudflare to regain your CDN and security benefits.

### Summary
If you are moving to Cloud Run and use Cloudflare, don't wait 24 hours like I did. **Turn off the proxy until the certificate is issued.** Once Google has that initial validation, the routing works perfectly even when you turn the proxy back on.


ecfeee512d771830333c602faaecf4077cedfcb0c744b3d89aca01031ae9a0c1

A practical note on fixing a Cloud Run custom domain that stays stuck on 'Waiting for certificate provisioning' behind Cloudflare. Explains why orange-cloud proxying breaks validation and how switching the record to DNS-only lets the SSL certificate complete.

Cloud Run domain mapping can stay stuck on certificate provisioning when Cloudflare proxying blocks Google's SSL validation.

Cloud Run Domain Mappings with Cloudflare: Why Your SSL is Stuck

{/* banner prompt: Of course! Here are three creative and engaging prompts for a banner image, each with a different artistic focus but all reflecting the core idea of the blog post.

---

### Option 1 (Metaphorical & Cinematic)

This prompt focuses on the idea of an AI breaking free from its digital confines to take direct control of a system.

**Prompt:**
> A cinematic digital art masterpiece. On the left side of the frame, a brilliant, glowing AI neural network is trapped inside a transparent, sandboxed cube representing a browser. A powerful, focused beam of light, composed of streaming green `bash` and blue `PowerShell` command-line text, shatters the cube's wall. This beam, representing the Cygwin SSH connection, extends to the right side of the frame, where it elegantly manipulates a complex, holographic 3D model of the Windows operating system. The beam is precisely deleting registry hives, stopping service gears, and cleaning up file system clutter, transforming chaos into order. The overall aesthetic is dark, futuristic, and infused with glowing neon data streams. --ar 16:9

---

### Option 2 (Direct & Illustrative)

This prompt visualizes the conversational aspect and the direct cause-and-effect of the user's request.

**Prompt:**
> A futuristic command center interface. In the foreground, a sleek, floating chat window displays a human's request: `"Uninstall all bloatware and clean the registry."` An AI responds: `"On it. Establishing SSH connection..."`. In the background, a massive, dynamic data visualization of the Windows OS shows the command in action. Streams of code flow from a central SSH terminal icon, targeting and dissolving icons for unwanted programs, while a 3D representation of the Windows Registry is being methodically scanned and cleaned by glowing green cursors. The style is clean, high-tech, and focuses on UI/UX design, with a dark theme and vibrant blue and green highlights. --ar 16:9

---

### Option 3 (Symbolic & Abstract)

This prompt uses symbolism to represent the fusion of two different tech worlds: the open, command-line world and the Windows GUI world.

**Prompt:**
> An abstract digital painting. A stylized, glowing Tux penguin (representing Linux/Cygwin) and a serene, blue AI entity (representing Claude) are working together as one. They are extending their hands, which are made of pure command-line code, through a shimmering portal shaped like the Windows logo. On the other side of the portal, their code-hands are masterfully deconstructing and reassembling Windows components like services, registry keys, and startup items, represented as intricate, glowing geometric shapes. The background is a dark, digital void, emphasizing the powerful and precise nature of the remote management. The lighting is dramatic and symbolic. --ar 16:9

Additional instructions: An AI maid */}

## The Problem with Browser-Based AI Assistants

If you've ever tried to get an AI assistant to help you actually *do* something on your Windows computer — not just tell you *how* to do it — you've probably hit a wall like this:

> *"I don't have direct access to your Windows system settings, so I can't check or change remote connection settings on your behalf."*

> *"I appreciate you asking, but there are a couple of important limitations here: I can't install software on your Windows computer. I have access to a sandboxed Linux environment for running code, but that's separate from your actual Windows system. I have no way to download or install applications like Cygwin or Python onto your PC directly."*

These are real responses from browser-based AI tools like "Claude Cowork" (Claude.ai in a chat window). They're not wrong in this context, but the limitation is narrower than "can only give advice": Claude Cowork can work with local files you expose to it and automate tasks that live inside the Chrome browser. What it still can't do is directly administer your Windows machine end-to-end the way an SSH-connected agent can.

But what if Claude could actually *do* it?

That's exactly what **Claude Code, Codex, Gemini, or any smart agent** with SSH access enables. Once your Windows machine is reachable over SSH, the agent — running on another machine on your network — can log in, run commands, read files, edit the registry, and manage your system end-to-end. No GUI required. No copy-pasting commands. You just ask.

---

## Part 1: The Hard Part — Making Windows SSH-Accessible

The one-time setup requires physical or RDP access to the Windows machine. After that, you'll never need it again.

### Step 1: Install Cygwin with OpenSSH

Download the Cygwin installer from [cygwin.com](https://www.cygwin.com) and install it. During package selection, make sure to include:

- `openssh` — the SSH server and client
- `cygrunsrv` — used to register Cygwin services as Windows services (will be included in standard installation)
- `bash`, `coreutils`, `grep`, `sed`, `awk`, `findutils` — standard Unix tools (often included in standard installation)
- `git` — useful for cloning repositories and working with source code

![](https://storage.googleapis.com/www-tyolab-com-blog-assets/images/blog/2026/04/managing-windows-made-easy-with-cygwin-and-claude/2026-04-15-20-08-42.png)

![](https://storage.googleapis.com/www-tyolab-com-blog-assets/images/blog/2026/04/managing-windows-made-easy-with-cygwin-and-claude/2026-04-15-20-14-53.png)

The default install path is `C:\cygwin64`.

### Step 2: Clone the Setup Scripts

The scripts are available on GitHub. Open a Cygwin terminal (not PowerShell yet) and clone the repo:

```bash
git clone https://github.com/e-tang/installcygwinsshd
cd installcygwinsshd
```

The repo contains two scripts:
- **`installsshd.ps1`** — installs and configures the Cygwin SSHD service
- **`verify.ps1`** — verifies the installation is working correctly

Basically, to install / enable the sshd service:
```bash
ssh-host-config --yes --cygwin 'ntsec' --name 'sshd' --port 22 --user 'cyg_server'
```

### Step 3: Run the Install Script

Open PowerShell **as Administrator** and run:

```powershell
cd C:\path\to\installcygwinsshd
Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass
.\installsshd.ps1
```

What the script does:
- Runs `ssh-host-config` inside Cygwin to generate host keys and create a `cyg_server` service account
- Sets the `CYGWIN=ntsec` environment variable (required for proper permissions)
- Opens port 22 in Windows Firewall
- Sets the `sshd` service to start automatically and starts it immediately

### Step 4: Verify the Setup

Still in the Administrator PowerShell, run:

```powershell
.\verify.ps1
```

### Step 4: Set Up SSH Key Authentication

From your Linux/Mac machine (or another machine running a smart agent: e.g. Claude Code), copy your SSH public key to the Windows machine so you don't need a password every time:

```bash
ssh-copy-id username@a-win-machine
```

You'll be prompted for the Windows user password once. After that, all SSH connections use your key. If `ssh-copy-id` isn't available, do it manually:

```bash
# On the client machine, copy your public key
cat ~/.ssh/id_ed25519.pub

# Then on the Windows machine (via password SSH), paste it into:
# C:\cygwin64\home\username\.ssh\authorized_keys
```

Also add the host to your known_hosts to avoid interactive prompts:

```bash
ssh-keyscan a-win-machine >> ~/.ssh/known_hosts
```

Once this is done, you can SSH in silently:

```bash
ssh a-win-machine "uname -a"
# CYGWIN_NT-10.0-19045 a-win-machine 3.6.7-1.x86_64 ...
```

That's it. **The hard part is over.** From this point on, you manage the machine through Claude Code — just by asking in plain English.

---

## Part 2: The Easy Part — Let Claude Do the Work

### Real Example: Removing Riot Games Completely

Here's a real session. I simply told Claude Code:

> *"I need you to remove / delete 'Riot Games' for me"*

Claude SSHed in, found the installation, confirmed before deleting, removed the directories, then I asked it to clean the registry too. Here's exactly what it did — autonomously:

**1. Locate the installation:**
```bash
ssh a-win-machine "find /cygdrive/c -maxdepth 2 -iname '*riot*' -type d 2>/dev/null"
# /cygdrive/c/ProgramData/Riot Games
# /cygdrive/c/Riot Games
# /cygdrive/c/Riot Games/Riot Client
```

**2. Check for running processes before deleting:**
```bash
ssh a-win-machine "tasklist.exe | grep -i riot"
# (nothing running — safe to proceed)
```

**3. Delete the directories:**
```bash
ssh a-win-machine "rm -rf '/cygdrive/c/Riot Games' '/cygdrive/c/ProgramData/Riot Games'"
```

**4. Search the registry for leftover keys:**
```bash
ssh a-win-machine "reg.exe query 'HKLM\\SOFTWARE' /f 'Riot' /k"
ssh a-win-machine "reg.exe query 'HKCU\\SOFTWARE' /f 'Riot' /k"
```

**5. When I mentioned "but it started when the computer starts"**, Claude found it immediately:
```bash
ssh a-win-machine "reg.exe query 'HKCU\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run'"
# RiotClient  REG_SZ  C:\Riot Games\Riot Client\RiotClientServices.exe --launch-background-mode
```

**6. Deleted the startup entry:**
```bash
ssh a-win-machine "reg.exe delete 'HKCU\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run' /v RiotClient /f"
```

Total time: a few minutes of conversation. No GUI. No digging through Add/Remove Programs. No regedit hunting. Just asking.

---

## Part 3: What Else Can You Do?

Once Claude Code has SSH access to your Windows machine, the possibilities are broad. Here are examples of tasks you can just *ask* for:

### Software Management

```
"Install Python 3.12 silently"
"Check what version of Node.js is installed"
"Uninstall all Adobe products"
"List all installed programs and their versions"
```

Claude can use `winget`, `choco`, or direct installers:
```bash
ssh a-win-machine "winget.exe install Python.Python.3.12 --silent"
ssh a-win-machine "winget.exe list | grep -i node"
```

### Windows Services

```
"Stop and disable the Windows Search indexing service — it's slowing down the disk"
"Restart the print spooler"
"Show me all services that are set to auto-start but are currently stopped"
```

```bash
ssh a-win-machine "sc.exe stop WSearch && sc.exe config WSearch start= disabled"
ssh a-win-machine "sc.exe query type= all state= all | grep -B1 'STOPPED' | grep 'SERVICE_NAME'"
```

### Startup and Scheduled Tasks

```
"Show me everything that runs at startup"
"Remove that suspicious MLWapp startup entry"
"Create a scheduled task to run a backup every night at 2am"
```

```bash
ssh a-win-machine "reg.exe query 'HKCU\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run'"
ssh a-win-machine "schtasks.exe /create /tn 'NightlyBackup' /tr 'C:\\backup.bat' /sc daily /st 02:00"
```

### Disk and File Management

```
"Find the 20 largest files on C: drive"
"Delete all .tmp files in AppData"
"How much space is left on each drive?"
```

```bash
ssh a-win-machine "df -h /cygdrive/c /cygdrive/d"
ssh a-win-machine "find /cygdrive/c/Users/dev/AppData -name '*.tmp' -delete"
ssh a-win-machine "du -sh /cygdrive/c/* 2>/dev/null | sort -rh | head -20"
```

### Registry Management

```
"Disable Cortana telemetry in the registry"
"Find all registry keys pointing to a deleted program path"
"Back up the HKCU Software hive before I make changes"
```

```bash
ssh a-win-machine "reg.exe export HKCU\\SOFTWARE C:\\backup\\hkcu_software.reg"
ssh a-win-machine "reg.exe add 'HKLM\\SOFTWARE\\Policies\\Microsoft\\Windows\\Windows Search' /v AllowCortana /t REG_DWORD /d 0 /f"
```

### Network and Firewall

```
"Show me all open ports and what's listening on them"
"Block port 8080 in the firewall"
"What's my current IP address and DNS servers?"
```

```bash
ssh a-win-machine "netstat.exe -ano | grep LISTENING"
ssh a-win-machine "New-NetFirewallRule -DisplayName 'Block 8080' -Direction Inbound -Protocol TCP -LocalPort 8080 -Action Block" 
ssh a-win-machine "ipconfig.exe /all"
```

### System Health and Monitoring

```
"What processes are using the most CPU right now?"
"How long has this machine been running?"
"Show me the last 20 error events from the System event log"
```

```bash
ssh a-win-machine "tasklist.exe /fo csv | sort -t',' -k5 -rn | head -10"
ssh a-win-machine "wmic.exe os get LastBootUpTime"
ssh a-win-machine "powershell.exe -Command \"Get-EventLog -LogName System -EntryType Error -Newest 20 | Format-List TimeGenerated,Message\""
```

### Windows Updates

```
"Check if there are pending Windows updates"
"Install all available updates and tell me when it's done"
```

```bash
ssh a-win-machine "powershell.exe -Command \"Get-WindowsUpdate\"" 
ssh a-win-machine "powershell.exe -Command \"Install-WindowsUpdate -AcceptAll -AutoReboot\""
```

---

## Why This Beats Browser-Based AI

<Table data={{
    headers: ["Capability", "Browser AI (Claude Cowork)", "Claude Code + Cygwin SSH"],
    rows: [
        ["Read files on your PC", "Yes", "Yes"],
        ["Delete files or programs", "Yes", "Yes"],
        ["Edit the registry", "No", "Yes"],
        ["Manage Windows services", "No", "Yes"],
        ["Run PowerShell commands", "No", "Yes"],
        ["Set up scheduled tasks", "No", "Yes"],
        ["Monitor processes", "No", "Yes"],
        ["Install software", "No", "Yes (via winget/choco)"],
        ["Fix startup items", "No", "Yes"],
        ["Works without GUI", "No", "Yes"],
    ],
}}
/>

The browser-based assistant can mostly *advise*. Claude Code with SSH access can *act*. The gap is enormous.

---

## Tips for Day-to-Day Use

**Give your Windows machine a stable local hostname.** Whether via your router's DHCP reservation or `C:\Windows\System32\drivers\etc\hosts` on the client, `ssh a-win-machine` is much nicer than an IP address `ssh 192.168.X.X`.

**Keep SSH keys, not passwords.** Run `ssh-copy-id` once. After that, Claude Code can SSH in without any credential prompts — fully automated.

**Cygwin gives you Unix tools on Windows.** `grep`, `find`, `awk`, `sed`, `curl` all work inside your SSH session. You're not limited to `cmd.exe` syntax. Mix PowerShell (`powershell.exe -Command "..."`) with Unix tools freely.

**Combine with Claude Code's file editing.** Claude Code can read and edit config files directly over SSH, not just run commands. Got a broken `sshd_config`? Claude can fix it in place.

**It's auditable.** Every command Claude runs goes through the SSH session you can see. Unlike opaque agent frameworks, you can watch exactly what's happening.

---

## Conclusion

The one-time setup — installing Cygwin, running two PowerShell scripts, copying your SSH key — unlocks something genuinely powerful: a Windows machine you can manage entirely through conversation.

No more digging through nested menus. No more manually hunting for registry keys. No more wondering which startup entry belongs to which program. You describe what you want, Claude figures out how to do it, and it's done.

Browser-based AI tools will tell you to "open regedit and navigate to...". Claude Code with SSH will just do it.


2b98dc65befd9b586cd6103472ab7a81c42cf32a8530ee698f7048c5066dd26a

A practical guide to setting up Cygwin SSHD on Windows and using Claude Code to manage it remotely — far beyond what browser-based AI assistants can do.

Stop fighting with Windows GUIs. With Cygwin, an SSH daemon, and Claude Code, you can manage any Windows machine from the command line — uninstalling software, cleaning the registry, killing startup entries — just by asking.

Managing Windows Made Easy with Cygwin and Claude

{/* banner prompt: Excellent! This is a great blog post that tells a clear story of a problem, a solution, and the resulting empowerment. Here are a few creative and engaging prompts for the banner image, ranging from conceptual to more literal, all designed to capture the essence of the post.

### Prompt Option 1 (Conceptual & Dynamic)

This prompt focuses on the partnership between the human and the AI, showing the AI as a powerful tool that untangles complexity.

**Prompt:**
> A dynamic digital art scene of a developer collaborating with a luminous AI entity. On a holographic interface floating between them, tangled, broken lines of red code representing bugs are being methodically repaired and woven into clean, flowing green code by the AI's energy. In the background, abstract cloud and DNS icons glow softly, symbolizing the Cloudflare API being fixed. The overall mood is one of breakthrough and efficiency, with a sleek, futuristic aesthetic. --ar 16:9

### Prompt Option 2 (Metaphorical & Powerful)

This prompt uses the metaphor of a bridge being repaired, which directly reflects the story of fixing a broken tool to connect the developer's intent to the API's function.

**Prompt:**
> Cinematic digital illustration of a broken bridge made of glowing code connecting a developer's command-line terminal to a massive, stable cloud structure representing the Cloudflare network. A sleek, intelligent AI, depicted as a focused beam of light or a robotic entity, is rapidly reconstructing the broken sections of the bridge, transforming chaotic red error symbols into solid, green success pathways. The scene is set in a dark, high-tech environment, emphasizing the AI as a beacon of solutions. --ar 16:9

### Prompt Option 3 (Direct & Action-Oriented)

This prompt is more direct, showing the "before and after" of the debugging process within a single, compelling image.

**Prompt:**
> A split-view digital artwork in a modern, tech-themed style. On the left, a frustrated developer is looking at a terminal screen filled with red error messages like "Invalid request headers" and "ENOENT". On the right, the same developer now looks confident as a helpful, transparent AI avatar hovers beside the screen, which now displays a stream of green "✓ Success!" messages and successfully executing CLI commands. The AI is pointing to the fixed code, bridging the gap between error and success. --ar 16:9

---

**Recommendation:**

**Prompt 1** is the most balanced and creative. It captures the core themes of AI collaboration, bug fixing, and open-source empowerment in a visually stunning and modern way without being overly literal. It provides the image generator with rich concepts like "luminous entity," "tangled red code," and "flowing green code" to create a unique and engaging banner. */}

## Introduction

In today's fast-paced development world, managing DNS records manually through web interfaces is time-consuming and error-prone. As someone who frequently needs to update DNS configurations across multiple domains, I wanted a better solution—a command-line tool that AI could use to automatically construct and execute commands based on the information I provide.

When I tried to set up domain for my a Google Cloud project, the below are the DNS records I needed to add:

{/* | Type  | Data                      | Alias |
|-------|---------------------------|-------|
| A     | 216.239.32.21             |       |
| A     | 216.239.34.21             |       |
| A     | 216.239.36.21             |       |
| A     | 216.239.38.21             |       |
| AAAA  | 2001:4860:4802:32::15     |       |
| AAAA  | 2001:4860:4802:34::15     |       |
| AAAA  | 2001:4860:4802:36::15     |       |
| AAAA  | 2001:4860:4802:38::15     |       |
| CNAME | ghs.googlehosted.com      | www   | */}

<Table data={
  {
    headers: ['Type', 'Data', 'Alias'],
    rows: [
      ['A', '216.239.32.21', ''],
      ['A', '216.239.34.21', ''],
      ['A', '216.239.36.21', ''],
      ['A', '216.239.38.21', ''],
      ['AAAA', '2001:4860:4802:32::15', ''],
      ['AAAA', '2001:4860:4802:34::15', ''],
      ['AAAA', '2001:4860:4802:36::15', ''],
      ['AAAA', '2001:4860:4802:38::15', ''],
      ['CNAME', 'ghs.googlehosted.com', 'www'],
    ],
  }
} />

And I am too lazy to click through the Cloudflare web dashboard to add them one by one. That's when I discovered [cloudflare-cli](https://github.com/danielpigott/cloudflare-cli) (cfcli), a promising Node.js tool for managing Cloudflare DNS records from the terminal. The vision was simple: I could tell an AI assistant "update these DNS records for my domain," and it would construct the proper cfcli commands and execute them automatically.

But there was a problem — cfcli was broken.

## The Problem: A Broken Tool

### The Configuration File

Cfcli requires a configuration file (`~/.cfcli.yaml`) containing your Cloudflare API credentials. I created mine with the following content:

```yaml
defaults:
   account: work
accounts:
   work:
      token: "p9XvQ2s7LwT8zR4bJ6yNf0c3KjHqWmVtSdFgLbXy"
       email: "eric@tyo.com.au"
       domain: example.com

```

When I first tried to use cfcli, I immediately ran into two critical bugs:

### Bug #1: Missing help.txt File

```bash
$ cd /tmp
$ cfcli help
Error: ENOENT: no such file or directory, open '/tmp/doc/help.txt'
```

Running cfcli from any directory outside its installation folder caused it to crash when trying to display help documentation.


### Bug #2: Invalid Request Headers

```bash
$ node ./bin/cfcli zones
Error response received: Invalid request headers
```

Every API request to Cloudflare was failing with cryptic "Invalid request headers" errors. The tool was completely unusable.

Initially, I used Google Gemini to run cfcli commands and update DNS records for me, but it kept failing due to these bugs. And Gemini simply gave up and asked me to update those records manually.

![](https://storage.googleapis.com/www-tyolab-com-blog-assets/images/blog/2025/10/empowering-open-source-development-with-ai-my-experience-fixing-cfcli/Screenshot_2025-10-04_17-01-24.jpg)

## Why This Mattered

These bugs weren't just inconvenient—they completely blocked my automation workflow. I needed cfcli to work reliably so that AI tools like Google Gemini, Claude Code, OpenAI Codex or others could:

1. **Automatically construct commands** based on natural language requests
2. **Execute DNS updates** without manual intervention
3. **Work from any directory** in my system
4. **Handle bulk operations** like updating multiple A, AAAA, and CNAME records at once

Without a working CLI tool, my entire automation strategy fell apart. I could continue using the Cloudflare web dashboard, but that defeated the purpose of having AI assistance.

## Enter Claude Code: From Broken to Fixed in Minutes

This is where things got interesting. Instead of spending hours debugging Node.js code, diving into axios documentation, and testing different configurations, I simply asked Claude Code to help me fix the bugs.

First, I forked the project to my own GitHub account: [e-tang/cloudflare-cli](https://github.com/e-tang/cloudflare-cli).

Then, I started a new conversation with Claude Code, providing the context about the two bugs I encountered.

Here's what happened:

### Step 1: Reproducing the Bug

Claude Code immediately understood the context and ran the local cfcli to confirm the error:

```bash
$ node ./bin/cfcli zones
Error response received: Invalid request headers
```

### Step 2: Intelligent Debugging

Rather than randomly trying fixes, Claude Code:

1. **Analyzed the codebase** to understand how authentication headers were being set
2. **Checked the axios version** (1.12.0) to identify compatibility issues
3. **Created test scripts** to isolate the problem
4. **Tested different authentication methods** (Bearer token vs. API Key)

Through systematic testing, Claude Code discovered that:

- The newer axios version (1.12.0) sets `Content-Type: undefined` by default
- This undefined header causes Cloudflare's API to reject requests
- The deprecated API Key authentication (X-Auth-Email + X-Auth-Key) doesn't work properly with newer axios versions
- Bearer token authentication works perfectly

### Step 3: The Fix

Claude Code implemented two elegant fixes:

**Fix #1: Remove the undefined Content-Type header**
```javascript
// lib/apiClient.js
const client = axios.create({
  baseURL: 'https://api.cloudflare.com/client/v4',
  timeout: 20000
});

// Remove the Content-Type header set to undefined by axios
// which causes issues with Cloudflare API in newer axios versions
delete client.defaults.headers.common['Content-Type'];
```

**Fix #2: Force Bearer token authentication**
```javascript
// bin/cfcli
let params = { ...config, ...argv };
// Remove email from params to force Bearer token authentication
// The old API Key authentication (email + key) is deprecated and causes issues with newer axios
if (params.token && params.email) {
  delete params.email;
}
```

### Step 4: Fixing the Path Resolution Bug

For the second bug, Claude Code identified that `path.resolve()` returns the current working directory, not the module's directory. The fix was straightforward:

```javascript
// index.js
import { fileURLToPath } from 'url';

const __filename = fileURLToPath(import.meta.url);
const __dirname = path.dirname(__filename);

showHelp() {
  return Promise.resolve(new Result([
    fs.readFileSync(path.join(__dirname, 'doc', 'help.txt'), 'utf8')
  ]));
}
```

### Step 5: Testing and Validation

Claude Code didn't just fix the bugs—it verified them:

```bash
# Test from the project directory
$ node ./bin/cfcli zones
✓ Success! Listed 4 zones

# Test from a different directory
$ cd /tmp && node /data/tyolab/node/cloudflare-cli/bin/cfcli help
✓ Success! Help text displayed correctly

# Test actual DNS operations
$ node ./bin/cfcli add --domain example.com --type A @ 216.239.32.21
✓ Added A record example.com -> 216.239.32.21
```

### Step 6: Proper Git Commits

Claude Code even created well-documented git commits following best practices:

```
commit e9ff7a6
Fix "Invalid request headers" error with axios 1.12.0

This fixes compatibility issues with the newer axios version (1.12.0)...

commit feef4f7
Fix help command path resolution when run from different directory

Changed from using path.resolve() (which returns current working
directory) to using import.meta.url with __dirname...
```

## The Real Magic: AI-Powered Automation in Action

With cfcli fixed, I could finally achieve my original goal. Here's what happened next:

**Me:** "For my domain example.com, please update them with: A 216.239.32.21, A 216.239.34.21, A 216.239.36.21, A 216.239.38.21, AAAA 2001:4860:4802:32::15, AAAA 2001:4860:4802:34::15, AAAA 2001:4860:4802:36::15, AAAA 2001:4860:4802:38::15, CNAME ghs.googlehosted.com www"

Claude Code immediately:
1. Parsed my natural language request
2. Constructed the proper cfcli commands
3. Executed them in sequence
4. Verified the results

```bash
# Added 4 A records
Added A record example.com -> 216.239.32.21
Added A record example.com -> 216.239.34.21
Added A record example.com -> 216.239.36.21
Added A record example.com -> 216.239.38.21

# Added 4 AAAA records
Added AAAA record example.com -> 2001:4860:4802:32::15
Added AAAA record example.com -> 2001:4860:4802:34::15
Added AAAA record example.com -> 2001:4860:4802:36::15
Added AAAA record example.com -> 2001:4860:4802:38::15

# Updated CNAME record
Added CNAME record www.example.com -> ghs.googlehosted.com
```

What would have taken me 15-20 minutes of clicking through the Cloudflare dashboard took **less than 10 seconds** with AI assistance.

## Lessons Learned

This experience taught me several valuable lessons about AI-assisted development:

### 1. AI Excels at Systematic Debugging

Rather than guessing, Claude Code used a methodical approach:
- Reproduce the error
- Analyze the codebase
- Identify the root cause
- Test potential solutions
- Implement the fix
- Verify it works

### 2. AI Understands Context

Claude Code didn't just fix the immediate bug. It understood:
- The purpose of the tool
- The compatibility issues with newer dependencies
- Best practices for path resolution in ES modules
- Proper git commit message formatting

### 3. AI Accelerates Learning

Throughout the debugging process, I learned about:
- How axios handles headers in different versions
- The difference between API Keys and API Tokens in Cloudflare
- ES module path resolution with `import.meta.url`
- Better patterns for CLI tool development

### 4. The Compound Effect of Automation

By fixing cfcli, I unlocked a new level of productivity:
- **Before:** Manual DNS updates through web UI (15+ minutes per domain)
- **After:** Natural language commands to AI → Automatic execution (seconds)

## The Bigger Picture: AI as a Development Multiplier

This story isn't just about fixing two bugs in a CLI tool. It's about how AI tools like Claude Code are fundamentally changing software development:

### From Bug Fixing to Feature Building

Instead of spending hours debugging, I spent minutes. That freed me to:
- Update DNS records for all my domains
- Write this blog post
- Think about other automation opportunities

### From Manual Work to Intelligent Automation

The combination of AI and CLI tools creates powerful workflows:
1. I describe what I want in natural language
2. AI translates it into technical commands
3. AI executes and verifies the results
4. I review and confirm

### From Isolated Tools to Connected Systems

By fixing cfcli, I created a reliable bridge between:
- Natural language (what I want)
- Technical commands (how to do it)
- Cloud APIs (where it happens)

## Conclusion: Life Becomes Easier with AI

The title says it all—life really does become much easier with AI assistance. But not in the way you might expect.

AI didn't replace my understanding or judgment. Instead, it:
- **Amplified my productivity** by handling repetitive debugging tasks
- **Accelerated my learning** by showing me best practices
- **Enabled new workflows** that weren't practical before

The open source community benefits too. Those two bug fixes are now committed to my local fork, ready to be shared back with the project maintainers. You can find the pull request here: [Fix axios compatibility and path resolution bugs in cfcli](https://github.com/danielpigott/cloudflare-cli/pull/95)

This is the promise of AI-assisted development: not replacing developers, but empowering them to focus on what matters—solving real problems and building valuable tools—while AI handles the tedious details.

## What's Next?

With cfcli working perfectly, I'm exploring more automation opportunities:
- Automated DNS configuration for new projects
- Bulk DNS record management across multiple domains
- Integration with infrastructure-as-code tools
- Automated SSL certificate management

The possibilities are endless when you combine AI intelligence with reliable CLI tools.

---

**Have you used AI to debug open source software?** I'd love to hear your stories. Share them in the comments or reach out on Twitter [@_e_tang](https://twitter.com/_e_tang).

**Want to try Claude Code?** Visit [claude.com/claude-code](https://claude.com/claude-code) to get started with AI-assisted development.

---

*This post was written with assistance from Claude Code—the same AI that helped fix the bugs described in this story. Meta, right?*


<ContactFooter />

cc5986a45e8f91e6feac595ddd12932f209416b208058d8075b09906fb373b46

A practical story of using AI-assisted development to fix open source software bugs, featuring axios compatibility issues and path resolution problems in the Cloudflare CLI tool.

How Claude Code helped me debug and fix critical bugs in cloudflare-cli, transforming a broken tool into a reliable DNS management solution in minutes.

Tag: Devops