You want Claude to write and post things to your website. That means
Claude needs a way in. Here is exactly what that access is, why it is safe, and how
you turn it off in one click — explained for a business owner, not an engineer.

What you actually do

Once per website. It takes about a minute.

1. Open the Terminal app and run one line:
   blitzpub connect yoursite.com
2. Your browser opens to your own website and asks:
   “Would you like to give Claude access to your site?”
3. Click Yes, I approve.
4. That’s it. You’ll see a green “connected” page. Close the tab.

From then on, when you ask Claude to publish something, it just happens. You are
not asked again — not next week, not next month, not in a new conversation.

What Claude can and cannot do with this

This is the part most people actually want to know. The key is not a master key.
It is cut for one lock.

Claude can

• Create a new page or blog post
• Update a page it created before
• Read your published content so it can match your style

Claude cannot

• Log in to your WordPress dashboard as you — the key does not work there
• See or change your actual password
• Read your customers’ payment details, or anything your website doesn’t store
• Change your billing, your domain, or your hosting
• Take the key with it — the key never leaves your computer

How to check on it, or turn it off

Your website keeps a receipt. Go to Users → Profile → Application Passwords
in your WordPress dashboard. You will see a row named Claude, with the date it
was created, the last time it was used, and the IP address that used it.

To end it, click Revoke. Publishing stops immediately. Your site, your
login, your content, and everything else carry on exactly as before. There is no
cancellation process and nobody to call.

If you’d like the exact link and steps printed for you, run
blitzpub revoke-help yoursite.com.

Straight answers to the usual worries

“Do I have to understand any of this?”

No. Run one command, click one button. This page exists so that you can
understand it if you want to, not because you have to.

“Is this less safe than giving someone my login?”

It is considerably safer, and it is the same mechanism your other apps already use.
A login gives away everything forever and is usually shared over email or text, where
it sits permanently. This key does one job, is visible on a dashboard, records its own
usage, and dies the moment you click Revoke.

“What if my laptop is stolen?”

The key sits in the same vault as your saved browser passwords, locked behind your
computer’s login. If the laptop is gone, revoke the key from any other device — your
phone works — and it is dead everywhere.

“What if I stop working with my agency, or stop using Claude?”

Click Revoke. One button, no notice period, no dependency on anyone else doing
anything.

“Can Claude break my website?”

It can create and update pages, so in principle it could publish a page you don’t
like — which you can edit or trash like any other page. It cannot touch plugins,
themes, settings, or your database. If you want to be extra careful, ask for the key
to be issued from an Editor account rather than an Administrator one; it will
still publish everything, with a smaller blast radius.

“Do I need a new key for each of my websites?”

Yes, one per site, and that is on purpose. Each site’s key only works on that site,
so a problem on one never becomes a problem on the others.

“Something isn’t working. What now?”

Run blitzpub doctor and send Claude the output. It contains no
passwords — only which sites are connected and whether they still answer. Claude can
read it and tell you what to do next.

---

TechnicalHow the connection actually works

The mechanism is WordPress Application Passwords, which has shipped in
WordPress core since 5.6 (December 2020). It is not a plugin, not a BlitzMetrics
invention, and not a workaround. Nothing is installed on your site.

The authorization flow

1. blitzpub connect first calls https://site/wp-json/ and
   confirms the REST API is reachable and that application-passwords
   appears in the advertised authentication methods. If not, it stops and explains why
   in plain language rather than sending you to a browser that will fail.
2. It binds an ephemeral HTTP listener on 127.0.0.1 — loopback only,
   on a random free port, for the duration of the approval and no longer.
3. It opens wp-admin/authorize-application.php with
   app_name, a per-machine app_id, and
   success_url pointing at that loopback address.
4. You authenticate to your own site in your own browser — blitzpub is not in that
   exchange and never sees those credentials — and approve.
5. WordPress generates a 24-character application password and redirects it to the
   loopback listener. It never crosses the public internet; the only network hop is the
   TLS session between your browser and your own site.
6. blitzpub writes it to the system credential store, drops its in-memory
   reference, shuts the listener down, and verifies with an authenticated
   GET /wp/v2/users/me.

The app_id is a UUID5 of site + hostname, so reconnecting
the same machine replaces its own entry instead of accumulating rows on your
Application Passwords screen.

Where the key is stored

Platform	Store	Protection
macOS	Keychain (/usr/bin/security)	Encrypted at rest, unlocked by your account login
Linux	Secret Service (secret-tool)	Encrypted by the desktop keyring
Fallback	~/.blitzpub/credentials.json	File mode 0600, directory 0700; doctor warns that this is the weaker option

The credential is never written to stdout, stderr, a process argument, an
environment variable, a log file, or the browser confirmation page. The tool’s test
suite asserts this by planting a canary value and checking every output path,
including the local HTTP handler, whose logging is explicitly disabled so query
strings never reach a terminal.

Threat model, stated plainly

If this happens	What an attacker gets	What stops it
Key is exfiltrated from the machine	Ability to create and edit content at the granting user’s role, via REST only	Revoke on the profile screen; last-used timestamp and IP make it detectable
Someone sees the key on screen or in a screenshot	Same as above	Treat as burned and revoke. One-click connect exists precisely so the value is never displayed
Claude’s sandbox is compromised	Nothing. The key is not there and never was	The sandbox holds no secrets and is destroyed after each session
Laptop stolen	Nothing without the machine’s login password	OS-level vault encryption; revoke remotely from any device
Site is compromised by other means	Unrelated to this key	Revoke as part of standard rotation

Application passwords do not grant interactive wp-admin sessions, are
rejected by wp-login.php, and are excluded from cookie authentication.
They authenticate REST and XML-RPC requests only. Where XML-RPC is disabled
fleet-wide — as it is across the BlitzMetrics fleet — the surface is REST alone.

Least privilege

An application password inherits the role of the user who created it. Publishing
needs publish_pages and publish_posts, which the
Editor role already carries. Issuing the key from an Editor account rather than
an Administrator one removes plugin, theme, user and settings capabilities from the
credential entirely, at no cost to the workflow. blitzpub whoami prints
the role so you can see what you granted, and warns if the account cannot publish.

Everyday commands

blitzpub connect yoursite.com          # one-click setup
blitzpub sites                         # what is connected on this machine
blitzpub doctor                        # health check, prints no secrets
blitzpub whoami yoursite.com           # confirm the key still works, show role
blitzpub publish yoursite.com \
    --file page.html --title "Title" --slug page-slug --status draft
blitzpub revoke-help yoursite.com      # exact steps to turn it off
blitzpub forget yoursite.com           # remove the local copy

Publishing is idempotent: the same --slug updates the existing page in
place rather than creating duplicates. Use --status draft to stage a page
for review, then re-run with --status publish. --dry-run
validates authentication and the payload without changing anything.

Running this across a fleet

Each site is connected independently, which is the point — there is no shared
credential and no single key that opens everything. For an agency or a network of
member sites:

• Connect each site once from the machine that will publish to it. The per-machine
  app_id means several people can each hold their own key for the same
  site, and revoking one does not disturb the others.
• Name the granting account after a person, not a role. The Application Passwords
  screen then shows you who, not just what.
• Audit centrally by reading GET /wp/v2/users/me/application-passwords
  per site; it returns names, creation dates, and last-used timestamps and IPs, with no
  secret material.
• Rotate by revoking and re-running connect. It takes the same minute
  it took the first time.

When one-click is unavailable

Some sites block authorize-application.php, serve over plain HTTP, or
sit behind a security plugin that filters the REST API. blitzpub detects each case
during preflight and says which one it is. The fallback is
blitzpub setup yoursite.com --user <username>, which walks through
creating the password by hand and stores it the same way. Everything downstream is
identical.

What this replaces

Before this, granting an assistant or a contractor publishing access meant sharing
an administrator login — usually over email or chat, where it persists indefinitely,
cannot be scoped, cannot be audited, and can only be revoked by changing the password
for everybody. A 2026 audit of one 159-site fleet found 153 of those sites reachable
with just two shared logins, all of them mailed in plaintext to a shared inbox. That
is the practice this replaces, and the reason it is worth the one minute.