I wanted an agent to help me run a Cloudflare account. I did not want an agent with an edit token deciding that a DNS record looked wrong.

That led to cld-flare-maxxing, a local control center for Cloudflare. Its normal job is simple: collect the account state, check it, explain what changed, and leave the account alone.

The useful part is the order. Read first. Decide second. Change something only after a person names the resource and approves the plan.

The problem with a broad Cloudflare token

Cloudflare has a big surface area. One account can have DNS records, Workers, Pages projects, WAF rules, SSL settings, storage, and audit logs. An agent can make a helpful observation from any of those places.

It can also make an expensive mistake.

I did not want the same token to answer “what changed?” and to change a firewall rule. Those are different jobs with different failure modes.

The project uses two local files for that split:

.cloudflare-maxxing/.env.cloudflare
.cloudflare-maxxing/.env.cloudflare.break-glass

The first holds a read-only token. The second is optional and contains an edit token plus an explicit arming phrase. Routine commands do not load the second file.

This means a normal investigation cannot become a write because a prompt got too confident. The code has to enter a different path first.

A snapshot is a better starting point than a chat prompt

The first command creates a record of the account before it tries to explain anything:

node "<skill-path>/scripts/cf-maxxing.mjs" init
node "<skill-path>/scripts/cf-maxxing.mjs" setup
node "<skill-path>/scripts/cf-maxxing.mjs" refresh

refresh collects account, zone, DNS, WAF, SSL, Pages, Workers, storage, and audit-log state. It then builds a report, beta recommendations, dashboard data, and an allowlisted list of actions.

The current report has 61 checks. A raw snapshot gives the checker something stable to work from, and the next snapshot can be compared with it. That makes questions like “who changed this DNS record?” less dependent on memory or a half-read dashboard.

The snapshot has two versions. The local one keeps the real resource details. The public sibling replaces ids, domains, names, emails, and IP addresses with stable aliases. The public version is useful in a pull request or bug report. The local version is useful when you need to fix the actual resource.

The plugin stays out of the host project

I also did not want this tool to become another thing that edits every repository it touches.

When installed in a project, it creates one directory:

<your-project>/.cloudflare-maxxing/

It does not use the host project’s .env. It does not add a package dependency. It does not change the host build or deploy setup. The snapshots, reports, dashboard files, and credentials all stay inside that directory.

That boundary sounds boring. It has saved me from a familiar problem: running a tool in a repo and later forgetting which config file it read.

The install path is a Codex or Claude Code plugin, but the skill folder can also be copied into a project. The runtime stays the same in both cases.

Writes are separate programs

The project has action scripts for a short, named set of changes. They start in dry-run mode. A real write needs all of the following:

  • an edit token in the break-glass file;
  • CF_ALLOW_DESTRUCTIVE=YES_I_AM_SURE;
  • a concrete action name;
  • an explicit --commit after the dry run has been reviewed.

Each attempt writes an audit record locally. If the audit record cannot be written, the action fails closed.

There is a tradeoff here. A simple change takes more steps than pasting a token into an agent session and asking it to fix the account. That extra friction is intentional. DNS, WAF, and SSL changes are places where a little delay is cheaper than a cleanup.

The dashboard is for the question after the report

The command-line report is good for a first pass. The local dashboard is for looking around after that.

It reads the generated dashboard data, so it does not need a token in the browser. It can show findings, limits, snapshot diffs, audit-log attribution, and product recommendations from the same stored state.

The dashboard is a view of a snapshot. It does not issue changes. That makes it easier to explain what a number means.

What I would do next

If you manage Cloudflare through an agent, start by listing the reads it needs. Give it a read-only token. Save a snapshot before you ask it for recommendations.

Then keep the write path small and visible. A dry run should name the zone, resource, old value, and new value. If the plan cannot explain those four things, it is not ready to run.

That is the main idea behind cld-flare-maxxing. An agent can be useful around infrastructure without being trusted with the infrastructure by default.