DEV Community: Rapls

My Claude Code auto mode config still said GITHUB_ACCOUNT_HERE. One command found it.

Rapls — Thu, 12 Nov 2026 15:34:04 +0000

I've been running Claude Code in auto mode for a while. In auto mode, Claude doesn't stop to ask before every routine action. A separate classifier model looks at each action and blocks the risky ones.

You can tell that classifier about your setup in ~/.claude/settings.json, under autoMode. I had done that. I wrote down who I am, what's normal for my work, and what must never leave my machine.

This week I printed that block to check it. One of my lines still said this:

Source control: GitHub personal account GITHUB_ACCOUNT_HERE; repositories under it are trusted.

It had been a placeholder since the day I wrote the config. The classifier never knew which GitHub account was mine.

Below is how I found it, and the two checks I'd now run on any auto mode config.

What the `autoMode` block is

The autoMode block has four lists, and each one is plain English, not patterns:

environment: context about your setup. Who you are, which repos and domains you trust.
allow: exceptions. Things the classifier would normally block, but that are fine for you.
soft_deny: things to block unless you clearly asked for them.
hard_deny: things to block no matter what.

By default, the classifier trusts only the repo you're working in and its configured remotes. Anything else, like your other repos on the same account, is "outside" until you say otherwise in environment.

That's exactly what my placeholder line was supposed to do.

Check 1: does every list you set still have `"$defaults"`?

This is the one that can actually hurt you.

Each list ships with built-in rules. If you set a list and include the literal string "$defaults", your entries are added to the built-in ones. If you set a list without it, your entries replace the built-in ones.

The docs are blunt about what that means:

soft_deny without "$defaults" drops every built-in soft block, including force pushes, curl | bash, production deploys, and auto mode bypass.
hard_deny without "$defaults" drops the built-in data exfiltration rule.
allow without it drops the built-in exceptions. That's not dangerous, but you'll get more prompts.
environment is the exception. If you generate it with /auto-mode-setup, it's written without "$defaults" on purpose, because the draft spells out the built-in entries itself.

To see what you wrote, print your autoMode block:

jq '.autoMode' ~/.claude/settings.json

My soft_deny, hard_deny, and environment all started with "$defaults". That's also where I saw the placeholder.

Check 2: what is the classifier actually using?

Your settings file is what you wrote. It isn't necessarily what the classifier reads, because entries from different scopes are combined.

This prints the effective config, your settings merged with the defaults:

claude auto-mode config

To confirm the built-in force-push rule is still there:

claude auto-mode config | grep -c 'Git Destructive'

Anything above 0 means it's in effect.

To check the line I cared about:

claude auto-mode config | grep 'Source control'

After I replaced GITHUB_ACCOUNT_HERE with my real account name, this showed two lines. One is the built-in default, saying it trusts the current repo and its remotes. The other is mine, naming my account.

Two more commands worth knowing

claude auto-mode critique sends your custom entries to a model and flags ones that are ambiguous, redundant, or likely to cause false positives.

claude auto-mode defaults prints the built-in rules. Read these before you ever write a list without "$defaults".

If you don't want to open a terminal, /permissions inside a session has an Auto mode tab where you can view and edit the same entries.

Why I missed it

I wrote the config once, it looked complete, and nothing broke loudly. Auto mode is a judgment call by a model, so a missing piece of context doesn't produce an error. At most, it makes the classifier a little more cautious than it needs to be.

That's the same pattern as every other silent failure I've hit with AI tools: the output looks finished, and nothing tells you otherwise until you check.

One rule from the Claude Code best practices page fits here. Auto mode is a classifier, not a hard rule, and it can be wrong. So the things that must never happen still belong in permissions.deny or hooks. The autoMode block is for context, not for guarantees.

The two-minute check

If you use auto mode, run these once:

jq '.autoMode' ~/.claude/settings.json          # what you wrote
claude auto-mode config | grep -c 'Git Destructive'  # built-in blocks still on?
claude auto-mode config                        # what the classifier really reads

Then read your environment lines one more time, looking for anything that still looks like a template.

Disclaimer: The config lines in this post are from my own setup. English isn't my first language, so I use an AI assistant to help draft and edit the writing.

I thought Claude Code would make my work lighter. I became its checker instead. Here's every file I wrote to stop

Rapls — Thu, 05 Nov 2026 13:20:36 +0000

I thought handing work to Claude Code would make my days lighter.

I build and sell WordPress plugins on my own. The AI would write the code, I'd ask for things and collect the results. Two extra hands.

What actually started was a different job.

Claude Code would say "Done," and I'd open the release zip to find files that should never ship. It would say "Tests pass," and I'd ask which tests. Every permission prompt, I'd read the command and press "Yes." I had gone from the person who writes the code to the person who checks the AI's work, one item at a time.

This post is every file I added to get out of that role, from the development of my caching plugin, Prime Cache: the CLAUDE.md, the permission settings, the hook I added after an incident, and how I hand work over between sessions. For each piece, I'll say why the line is there.

What I wanted to hand off was checking, not writing

Getting an AI to write code isn't the hard part anymore. Checking that the code is right is. If I do all the checking, my hands are never free.

So I changed how I write instructions. Along with "write this," I add "when you're done, run this. If the output is empty, it passed." If the AI checks its own work and shows me the evidence, I only have to read the evidence.

The Claude Code team described the same idea for their own process in "How the Claude Code team does code review" (October 15, 2026): Claude reviews and fixes a change before a person is asked to look, and human attention goes to the riskier changes. I work alone, so instead of a team process, I put it in files.

1. CLAUDE.md: write the reason next to the rule

CLAUDE.md is the file Claude Code reads first when it opens a project. Mine for Prime Cache is about 250 lines. It didn't start that long; a line got added each time something went wrong.

Prime Cache saves pages as HTML files and serves them before WordPress loads. That means one file runs before WordPress exists:

### Important Constraints
- `dropins/page-cache.php` runs before WordPress — cannot use any WP functions (no `get_option()`, `wp_parse_url()`, etc.)
- Atomic writes (temp file + rename) prevent serving partial files under concurrency
- Path traversal protection via `realpath()` validation against cache directory

Before I wrote this, Claude would sometimes helpfully reach for get_option() in that file. It's correct in an ordinary plugin file. Here it doesn't work. The AI wasn't wrong, it just didn't know.

The reason matters more than the rule. "Don't use WP functions" alone, and the AI looks for a similar function. "Because it runs before WordPress," and it can work out on its own that the similar function is out too.

Say what's banned, and what isn't

I keep two other caching plugins in my dev WordPress to study how they work. The AI is very good at "referencing" code that's lying around: copy a function body, rename the variables. So my CLAUDE.md has an originality policy, and the important half is the second list:

Prohibited:
- Copying a function/method body and only renaming variables or constants
- Copying comment blocks or docblocks
- Directly mimicking multi-line code structure

Acceptable similarities:
- `wp_cache_*` signatures required by the WordPress drop-in API
- WordPress hook names (`transition_post_status`, `create_term`, ...)
- Checks for standard WordPress constants (`DONOTCACHEPAGE`, `WP_CACHE`, ...)
- Industry-standard patterns (atomic write, gzip, 304 responses)

(The real file is in Japanese, and it names the plugins I'm studying.)

Write only "don't copy," and the AI starts avoiding WordPress's required function names too, which breaks things. With examples on both sides, it can draw the line between them.

The release zip, and "empty means pass"

This is the part I most want to share.

My CLAUDE.md has the zip command with its exclude list, and then a check that must be run afterwards:

unzip -Z1 prime-cache.zip | grep -iE "\.gitattributes|\.claude|/\.git/|\.serena|\.DS_Store|CLAUDE.md|/tests/|/docs/"

It lists the files in the zip and looks for names that must not be there. CLAUDE.md says the result "must be empty."

That's the smallest form of handing off the checking. If Claude only says "I built the zip," I have to open it. If it says "I built the zip, and the check came back empty," I read one line. The pass condition is "empty," which neither the AI nor I can misread.

Two notes in that section exist because of real near-misses:

Nested files. claude-mem, a plugin I use for session memory, drops .claude/ folders and CLAUDE.md files into subfolders like languages/.claude/ and includes/CLAUDE.md. My first exclude list only covered the top level, so these leaked. The excludes now use */.claude/* and **/CLAUDE.md forms.
Git-ignored isn't zip-ignored. tests/ is in .gitignore, but the zip is built from the working folder. The -x exclude is what actually keeps it out.

For the Pro add-on, there's one block marked "MUST exclude": tooling that only I use on my side for licenses. CLAUDE.md says what to exclude and why it matters, and the zip check fails if any of it shows up.

Keep the places that broke before

Near the end of CLAUDE.md is a pre-release checklist. One item says: with the Pro add-on installed and Cloudflare/Sucuri API keys saved, open the generated config file and confirm the keys are NOT written there. The free plugin skips them on purpose, and the line ends with "this is the regression case to protect."

Leaving the keys out was deliberate. Someday someone (an AI) tidying up the code might decide that line isn't needed. This item is how I'd notice.

2. AGENTS.md: a find-and-replace copy that broke silently

While writing this up, I compared files and found a mistake I should be honest about.

I also use OpenAI's Codex, which reads AGENTS.md, not CLAUDE.md. I had made AGENTS.md by copying CLAUDE.md. Comparing them, every "claude" had been replaced with "Codex":

-x "prime-cache/.Codex/*" \
-x "prime-cache/*/.Codex/*" \
-x "prime-cache/AGENTS.md" \
-x "prime-cache/**/AGENTS.md" \

It looks adapted for Codex. But now .claude/ and CLAUDE.md aren't excluded. If Codex built a release from these instructions, Claude Code's settings and instructions would ship in the zip.

Worse, the check was replaced the same way:

unzip -Z1 prime-cache.zip | grep -iE "\.gitattributes|\.Codex|/\.git/|\.serena|\.DS_Store|AGENTS.md|..."

It doesn't look for .claude or CLAUDE.md, so even if they were in the zip, the result would be empty. A pass.

The exclude and the check broke together, from the same replacement, so neither one complains. The copy also had "Codex-mem" (a plugin that doesn't exist) and "Codex.ai/code".

Two lessons:

When you copy an instruction file for another agent, reread and rewrite it; don't find-and-replace. The exclude list should cover both agents' files, so either one can build the zip safely.
The check needs checking too. "Empty means pass" is only as good as the names it searches for. Feed it a zip that deliberately contains .claude/, once, and see whether it fails.

3. settings.json: stop it with mechanisms, not requests

CLAUDE.md is a request. Claude follows it almost every time. Almost.

What must never happen goes into ~/.claude/settings.json, in three boxes.

allow is what Claude can do without asking: read, search, edit, git status, git diff, run tests and linters, compile translations. If these aren't here, Claude asks every time, and pressing "Yes" all day was exactly the checker job.

ask has only four entries in my setup:

"ask": [
  "Bash(svn commit:*)",
  "Bash(svn ci:*)",
  "Bash(gh release create:*)",
  "Bash(git push --tags:*)"
]

All of them lead to a release. svn commit publishes to WordPress.org: every site using the plugin gets an update notice, and it can't be taken back. The fewer things that ask, the more seriously I read the ones that do. Four kinds of prompt means that when one shows up, my hand stops: this is a release.

deny is what must not happen:

"deny": [
  "Read(**/.env)",
  "Read(~/.ssh/**)",
  "Edit(~/.claude/settings.json)",
  "Edit(~/.claude/hooks/**)",
  "Bash(curl:*)",
  "Bash(wget:*)",
  "Bash(sudo:*)",
  "Bash(git reset --hard:*)",
  "Bash(git push --force:*)",
  "Bash(wp plugin delete:*)",
  "Bash(wp db drop:*)",
  "Bash(wp eval:*)"
]

(There are more.) The settings file and the hooks can't be edited, so the AI can't decide "this restriction is in the way, so I removed it." A lock you can lift off with the key inside isn't a lock.

Sandbox: decide which roads are open

"sandbox": {
  "enabled": true,
  "failIfUnavailable": true,
  "network": {
    "allowedDomains": ["registry.npmjs.org", "packagist.org", "wordpress.org", "*.wordpress.org", "github.com"],
    "strictAllowlist": true
  }
}

(The real list has a few more npm and Composer hosts.) failIfUnavailable means: if the sandbox can't start, refuse to run instead of running without it. The scariest case is the fence being broken and things running with no fence at all.

Auto mode: tell it what's normal here

defaultMode is auto, where Claude judges for itself whether an action needs asking. I describe my environment for it, in plain sentences. Paraphrased:

Rapls Works is a one-person WordPress plugin business.
Production sites, their databases, and the WordPress.org SVN are to be handled carefully. An SVN commit ships to every user and can't be undone. Release only when I explicitly say so.
Stripe keys, Pro licenses, customer data, .env, and wp-config.php must never leave this machine or go into Git.
There's no staging environment. Some folders in the working tree are deliberately untracked; if they're deleted, Git can't bring them back.
Commits, branches, local merges and rebases, builds, tests, and pushing to my own GitHub are routine. No need to ask.

The last line is the one that ends the checker job. Write only what's dangerous, and the AI checks everything with you. Write what's routine too, and it asks only what it should.

4. A hook: never lose the folder twice

Hooks run my own script right before Claude Code executes a command. Mine starts like this:

# Blocks shell commands that could delete, move, or overwrite the Prime Cache
# plugin *development* folders (prime-cache / prime-cache-pro) or otherwise wipe
# the working tree. Added after the 2026-07-19 folder-loss incident.

Yes. I lost it once.

deny already had dangerous commands, but there are many ways to write them. Block rm -rf and mv, rsync --delete, and find -delete are still open. So the hook blocks a command when it contains both a destructive operation and a dev folder name:

destructive='rm[[:space:]]+-[a-z]*r|(^|[[:space:]])rmdir[[:space:]]|(^|[[:space:]])mv[[:space:]]|(^|[[:space:]])trash[[:space:]]|-delete([[:space:]]|$)|-exec[[:space:]]+rm|rsync[[:space:]].*--delete|git[[:space:]]+clean'
if printf '%s' "$low" | grep -Eq "$destructive"; then
  if printf '%s' "$low" | grep -Eq "$target"; then
    deny "Blocked: this command could delete, move, or overwrite the Prime Cache plugin development folder ..."
  fi
fi

Two design choices:

It doesn't block prime-cache.zip. Building a release deletes the old zip first. A folder name followed by . is treated as something else, so the daily release work isn't blocked. A guard that blocks normal work ends up getting removed.
If the script breaks, it lets things through. A bug in the guard must never wedge the session (fail-open).

That's the opposite of the sandbox, which fails closed. The sandbox is the last fence, so if it's broken, stop. The hook is one guard inside that fence, so if it's broken, step aside. Where to stop and where to let through is decided by role.

5. Handovers: make the new session start itself

Long work eventually needs a fresh session, and the new session doesn't know what we decided. Explaining it all again is checker work too. I write a HANDOFF.md and open the new session with one request:

Read HANDOFF.md. Then run /init to create CLAUDE.md, and make sure it includes chapter 3 (decisions) and 3.3 (what we decided not to do). When you're done, start with the request in chapter 8.

/init writes what it read into a file, so it survives the next session too. "What we decided not to do" is named explicitly because it's the first thing lost in a handover. The reasons were discussed mid-conversation, so the document tends to be short there, and a new session will kindly do exactly what we ruled out.

6. Ask for evidence with "done"

The last piece is how "done" arrives. Here is what I'd add to the end of a CLAUDE.md:

## When you finish, report in this form
- What you did: each changed file and what changed, one line each
- What you checked: the commands you ran and their results ("empty", "12 of 12 passed")
- What you did NOT check: anything time or environment kept you from verifying
- What caught your eye: things you didn't fix but that seem worth a look

The third item matters most. An AI won't volunteer what it didn't check, so you assume it checked everything. Give it a field for that, and it fills it in. Then I check only what's listed there.

One more thing: the same session reviewing its own work tends to go easy on it. For big changes I also have another Claude session, or Codex, look. From outside the session that wrote it, you see things the writer can't, like the find-and-replace mistake above. I only found that one because I put the two files side by side.

Checklist

CLAUDE.md

Project-specific constraints ("runs before WordPress"), with reasons
What's banned, with examples of both banned and acceptable
A check command to run when finished, and its pass condition
Places that broke before, kept as pre-release checks
The shape of the completion report, including "what you did not check"

Other agents' instruction files (AGENTS.md etc.)

Not made by find-and-replace; names and exclude lists make sense
The check has been fed a deliberately bad zip, once

settings.json

Read-only and verification actions in allow
Only irreversible actions in ask
Secrets, the settings file itself, and history rewrites in deny
A sandbox with an allowlist of hosts
In auto mode, routine work described alongside the dangers

Hooks

A guard where something actually went wrong once
Normal work isn't blocked
A broken guard doesn't stop all work

Handovers

The handover document has a "what we decided not to do" chapter
The first message of a new session covers read, write it down, and start the next task

Almost every line in these files was added after something went wrong. You don't need a perfect CLAUDE.md on day one. When the AI gets something wrong, add one line instead of getting annoyed, and put in it why it's wrong and how to check.

Disclaimer: The files in this post are from my own project; I quoted and translated the relevant parts for this post. English isn't my first language, so I use an AI assistant to help draft and edit the writing.

My Cursor state.vscdb was 8.9 GB. You can work out how much VACUUM will save before you run it

Rapls — Sun, 01 Nov 2026 04:35:58 +0000

My Mac was running low on disk space, so I went through the big folders one at a time. One of them was Cursor's globalStorage, at 19 GB:

~/Library/Application Support/Cursor/User/globalStorage
  8.9G  state.vscdb
  8.9G  state.vscdb.backup

state.vscdb is a SQLite database. It holds Cursor's settings and state, including the agent chat history. The usual advice is to quit Cursor and run sqlite3 state.vscdb "VACUUM;".

Before you do that, you can work out how much it will shrink. Multiply page_size by freelist_count and you have the space VACUUM will give back. I built a 574 MiB test database, deleted two thirds of the rows, and predicted 191.4 MiB. After VACUUM it was 191.5 MiB.

I'm not the first to write about this file. The Cursor forum has several threads about state.vscdb reaching tens of gigabytes, and the quit-then-VACUUM fix is posted there. The SQLite docs also say VACUUM needs temporary disk space. What I'm adding is a set of measurements on a WAL-mode database shaped like Cursor's: the prediction, how much free disk VACUUM used while running, and when it refuses to run.

Deleting rows doesn't shrink the file

When SQLite deletes data, the file stays the same size. The freed pages go on a "freelist" and get reused by later writes. VACUUM rebuilds the file without them.

You can see the count without changing anything:

cd ~/Library/Application\ Support/Cursor/User/globalStorage
sqlite3 state.vscdb "PRAGMA page_size; PRAGMA page_count; PRAGMA freelist_count;"

This only reads the file, so you can run it while Cursor is open.

My test database had the same two tables as Cursor's (ItemTable and cursorDiskKV) and used WAL mode, like the real file (mine had -wal and -shm files next to it). I inserted 3,000 rows of 200 KB each, then deleted 2,000 of them:

after insert:        574.3 MiB
after deleting 2/3:  574.3 MiB   <- no change

page_size       4096
page_count      147030
freelist_count  98017

4096 × 98017 is about 383 MiB. Take that from 574.3 MiB and you get 191.4 MiB.

after VACUUM:        191.5 MiB

I also ran VACUUM on a copy where I hadn't deleted anything. freelist_count was 0 and the file stayed at 574.3 MiB. If your freelist is small, VACUUM won't help much; the file really is that full of data.

VACUUM needs about twice the final size in free space

VACUUM builds a new copy of the database and then writes it back. While that happens, it uses disk.

I watched df while the 574.3 MiB database was being vacuumed. At the peak, disk usage was 384 MiB higher than before I started. That's about twice the final size (191.5 MiB).

The WAL file accounts for half of it: -wal grew to 192.6 MiB. The other half is most likely the temporary copy. SQLite deletes its temp file from the directory as soon as it opens it, so du never saw it. Only df did.

For Cursor, this matters if the file won't shrink much. If 8.9 GB only drops to 8 GB, you'd need around 16 GB free while it runs. If your disk is nearly full, clear something else first.

Quit Cursor first

I also tried running VACUUM while another connection had the file open:

Other connection	VACUUM
open, idle	succeeded
inside a read transaction	succeeded
inside a write transaction	`Error: stepping, database is locked (5)`

In WAL mode, a reader didn't block VACUUM. A writer did. Cursor writes to this database while you use it, so quit it fully (Cmd+Q) before you run VACUUM.

The .backup file

A reply on the Cursor forum describes state.vscdb.backup as a backup Cursor makes automatically, and says it should shrink once the main file does. I didn't find anything about when it's created.

In my case, VACUUM brought state.vscdb down to [TO FILL IN: size after VACUUM]. I started Cursor, checked that it worked normally, and then deleted the .backup file.

cd ~/Library/Application\ Support/Cursor/User/globalStorage
sqlite3 state.vscdb "VACUUM;"
du -sh state.vscdb
# start Cursor, check it works, then:
rm state.vscdb.backup

If VACUUM doesn't shrink it, the same forum thread describes deleting chat-history keys from cursorDiskKV and then running VACUUM again. That removes old chats from the UI, so I haven't tried it.

Checklist

Work out the gain first: page_size × freelist_count
A small freelist_count means VACUUM won't free much
Have about twice the final size free while it runs
Quit Cursor; a writer makes VACUUM fail with database is locked
Delete state.vscdb.backup only after Cursor starts fine

How big is your globalStorage right now?

Reproduce it

# mk.py: a WAL-mode database shaped like Cursor's
import sqlite3, os, sys
c = sqlite3.connect(sys.argv[1])
c.execute('pragma journal_mode=wal')
c.execute('create table ItemTable(key text unique on conflict replace, value blob)')
c.execute('create table cursorDiskKV(key text unique on conflict replace, value blob)')
b = os.urandom(200_000)
for i in range(3000):
    c.execute('insert into cursorDiskKV values(?,?)', (f'bubbleId:{i}', b))
c.commit()
c.execute('pragma wal_checkpoint(truncate)')
c.close()

python3 mk.py s.db
sqlite3 s.db "delete from cursorDiskKV where cast(substr(key,10) as int) % 3 != 0;
              pragma wal_checkpoint(truncate);"
sqlite3 s.db "pragma page_size; pragma page_count; pragma freelist_count;"
sqlite3 s.db "VACUUM;"
ls -l s.db

I ran these with SQLite 3.45.1 on Linux. The real Cursor file on a Mac may not give the same numbers.

Disclaimer: The tests were run on a test machine I set up for this post. English isn't my first language, so I use an AI assistant to help draft and edit the writing.

php -v over SSH doesn’t tell you which PHP your website runs

Rapls — Sat, 24 Oct 2026 03:55:47 +0000

After a PHP release, the quickest check is to SSH in and type php -v. I've done that myself. For this post I set up a test machine to see how much that number says about the website. Not much.

php -v reports the command-line PHP. Your site is served by whatever PHP the web server hands requests to, and on the same box those can be different builds, different versions, with different extensions and different php.ini files.

Same machine, two answers

I put this together on Ubuntu 24.04: Apache 2.4.58 passing .php requests to PHP-FPM 8.3, and the php command pointing at the PHP 8.4 CLI that was already installed. Then I asked each side who it was.

How I checked	Result
`php -v` over SSH	PHP 8.4.21 (cli)
`PHP_VERSION` from a page in the browser	8.3.6
`PHP_SAPI` on the command line	cli
`PHP_SAPI` in the browser	fpm-fcgi
php.ini loaded on the command line	/etc/php/8.4/cli/php.ini
php.ini loaded in the browser	/etc/php/8.3/fpm/php.ini
WordPress Site Health, opened in the browser	8.3.6, fpm-fcgi
The same Site Health data, read from the CLI	8.4.21, cli

None of this is new. The PHP manual's chapter on the command line covers the separate SAPI and the separate php.ini. Seeing the two side by side on one machine shows how easy it is to check the wrong one and call it done.

Why they drift apart

On Ubuntu, each PHP version and each SAPI is its own package: php8.3-cli, php8.3-fpm, php8.4-cli, and so on. The bare php command is a symlink to one of them.

$ which -a php php8.3 php8.4
/usr/bin/php
/usr/bin/php8.3
/usr/bin/php8.4
$ ls -l /usr/bin/php
/usr/bin/php -> /etc/alternatives/php

Here it pointed at 8.4. The web server config sent requests to php-fpm8.3. Those two choices are made in different places, by different people sometimes, and nothing keeps them in sync.

It wasn't only the version

Halfway through, WordPress refused to load in the browser:

Your PHP installation appears to be missing the MySQL extension which is required by WordPress.
Please check that the mysqli PHP extension is installed and enabled.

From the command line, the same WordPress install worked fine. The 8.4 CLI had mysqli. The 8.3 FPM didn't. php -m happily listed mysqli, because php -m was asking the CLI. Installing php8.3-mysql and restarting FPM fixed the browser side.

So the gap covers extensions and ini settings as well as the version number. A check run from the CLI only tells you about the CLI.

Checking the PHP your site actually runs

The answer has to come from a web request.

A tiny file does it. Give it a name nobody will guess, open it in the browser, then delete it:

<?php
header('Content-Type: text/plain');
printf("PHP_VERSION=%s\nPHP_SAPI=%s\nphp.ini=%s\n",
    PHP_VERSION, PHP_SAPI, php_ini_loaded_file());

PHP_VERSION=8.3.6
PHP_SAPI=fpm-fcgi
php.ini=/etc/php/8.3/fpm/php.ini

phpinfo() tells you the same and much more. I prefer the small file, because forgetting to delete it costs less.

On WordPress you don't need a file at all. Tools → Site Health → Info → Server shows the PHP version and SAPI, and since you open it in the browser, it's the web PHP.

The catch: WP-CLI runs on the CLI PHP. When I pulled the same Site Health data from the command line, it reported 8.4.21 and cli. If you check from WP-CLI, you're checking the wrong PHP again, just more politely.

== Web
php_version: 8.3.6 (Supports 64bit values)
php_sapi: fpm-fcgi
== CLI
php_version: 8.4.21 (Supports 64bit values)
php_sapi: cli

What I check now

When I want to know whether a PHP update reached my site, I check from the browser side: the small file, phpinfo(), or Site Health. php -v and WP-CLI tell me about the shell. That's still useful, for cron jobs and CLI scripts, but it isn't the answer to "is my website patched?"

One thing I didn't test: what happens when the FPM package updates but the FPM service hasn't restarted yet. I'd expect the old binary to keep serving until a restart, but I haven't measured it, so I won't claim it.

What does php -v say on your server, and does it match what your website reports?

I build WordPress plugins and write about them at https://raplsworks.com/.

Disclaimer: The tests were run on a test machine I set up for this post. English isn't my first language, so I use an AI assistant to help draft and edit the writing.

Claude Code now blocks the git command that almost cost me a day's work. I'm keeping my deny rules anyway.

Rapls — Thu, 25 Jun 2026 00:53:28 +0000

A while back I asked an agent to roll back to my last push so I could glance at some old code. It reached for git reset --hard and took my uncommitted work with it. After that near-miss I started adding deny rules to my settings.json by hand: the boring lines that refuse the destructive git commands I never want run without me asking for them by name.

This month, Claude Code shipped the guardrail I had been building by hand. According to the June 19, 2026 changelog, auto mode now blocks the destructive ones by default. git reset --hard, git checkout -- ., git clean -fd, and git stash drop are refused when you didn't ask to discard local work. git commit --amend is blocked when the commit wasn't made by the agent this session. And terraform, pulumi, and cdk destroy are blocked unless you named the specific stack.

My first reaction was to delete my own lines. The default now does the thing I had been doing manually, so why keep the maintenance? Then I read what the guard actually is, and I put my deny rules back.

The guard is real, and it's a classifier, not a rule

Here is the part that changed my mind. In auto mode, Claude Code doesn't ask you to approve each command. A safety classifier, a second model reading the conversation, decides in real time whether each action is safe. The new guardrail lives inside that classifier. When it blocks git reset --hard, it isn't matching a fixed pattern. It is inferring, from the transcript, that you didn't ask to throw work away.

That inference is good, and it is welcome, and it is not the same thing as a rule. A classifier judges intent, which means it can also misjudge it. The honest tell is in the failure mode: when the classifier model is temporarily unavailable, auto mode fails closed and blocks commands until it comes back. Failing closed is the right call, and it is also a reminder that this protection is a live inference with a dependency, not a static line that is simply true whether or not a model is reachable.

Three reasons my hand-written lines stayed

The first is mode. This guardrail is an auto-mode feature. If you run Claude Code with normal permission prompts, or in any setup where the auto-mode classifier isn't the thing gating commands, the default isn't doing this for you. A deny rule in settings.json, or a PreToolUse hook, runs regardless of mode. It doesn't care how you happen to be driving the agent today.

The second is determinism. The classifier infers whether you asked; a deny rule matches whether you did. For most commands, inference is fine, and for the one command that would cost me a day, I want the boring certainty of a pattern that either fires or doesn't. PreToolUse hooks also run before the permission system, so they catch things that slip past softer checks. Inference raises the floor. A matched rule is the floor.

The third is scope. The new guard covers git and infrastructure-as-code. That is exactly the right place to start, and it is not the whole map. It does not stand between an agent and rm -rf, a dropped database, a force-push to main, or a secret read out of a file and sent somewhere. Some of the near-misses I worry about most aren't git at all, and for those, the default did nothing, because it was never meant to.

Inference is not the only layer, and neither is the sandbox

It is worth saying that the sandbox doesn't cover this either, for a subtle reason. Auto mode's sandboxing isolates the filesystem and network, but git reset --hard looks safe to a sandbox: it only touches files inside your project directory. The boundary was never crossed. The work is just gone. Destructiveness and containment are different questions, and a tool can answer one perfectly while leaving the other open.

So I stopped thinking of these as competing options and started stacking them. The built-in classifier is intent inference. My deny rules and hooks are deterministic enforcement. The sandbox is containment. Each one misses what the others catch, and the cheapest near-miss to prevent is the one three layers refuse instead of one.

What I actually changed

I didn't delete the lines the guard now duplicates. I left them as the deterministic backstop under a probabilistic improvement, which is what defense-in-depth is. What I did change is where I spent the attention the new default freed up: on the gaps it doesn't cover. The git case is handled three ways now. The rm -rf, the database, and the secret-exfiltration cases are the ones still leaning on rules I wrote, so that's where the next hour of config goes.

A note to my next self

A better default is a reason to audit your config, not to delete it. When the floor rises, check what is now redundant, keep it anyway as a backstop, and move your effort to whatever the new default still doesn't reach. The day the classifier is uncertain about your intent, or the command isn't a git command at all, the only thing standing between you and lost work is the deterministic line you wrote back when you didn't trust anything to catch it for you.

The auto-mode safety details (the blocked git and IaC commands, the "didn't ask to discard" condition, the amend rule) are from the official Claude Code changelog, June 19, 2026: https://code.claude.com/docs/en/changelog . The near-miss is mine. Behavior and version specifics change quickly, so confirm against the current changelog before relying on any of it.

Disclaimer: The experiences and decisions in this post are my own. English isn't my first language, so I use an AI assistant to help draft and edit the writing.

Disclaimer: The experiences and decisions in this post are my own. English isn't my first language, so I use an AI assistant to help draft and edit the writing.

I trusted my CLAUDE.md. WordPress.org rejected the exact thing it was supposed to prevent.

Rapls — Tue, 23 Jun 2026 23:46:08 +0000

My CLAUDE.md had a rule about it. The generated code broke the rule anyway. And the thing that finally caught it wasn't my config file. It was a rejection from the WordPress.org plugin review team.

I'd been building plugins with a long CLAUDE.md. Over time I'd folded two whole guides into it: the WordPress Japanese translation style rules I follow, and my own plugin design conventions, including the things you're specifically not supposed to do. It got long. And the longer it got, the safer I felt. It's written down, so it'll be followed. That was the assumption, and I never once questioned it.

Then I shipped a plugin with trialware-shaped code around how paid features were gated, the kind of thing the WordPress.org directory guidelines push back on, and the kind of thing my own design guide explicitly told the agent to avoid. The rule was right there in the file. The generated code stepped on it anyway, and I didn't notice until the rejection came back.

That rejection did something useful. It turned my trust in the config file inside out. I had written the rule. I had never checked whether it was in effect. And the thing that finally graded whether my own guide was working wasn't my guide. It was a reviewer on the other side, weeks later.

Written is not the same as in effect

Here's the assumption I think most of us run on: a config file is something you write and then trust. Written equals followed. A long instruction file doesn't actually work that way, though. Its effect starts leaking the moment it gets long. There's good writing on this now: a monolithic CLAUDE.md that runs to a few thousand lines creates two problems at once. The agent processes all of it regardless of the task, and nobody fully owns it, so sections accumulate debt until it becomes the file everyone references and no one really trusts. I'd read exactly that, nodded, and kept adding lines anyway, because adding is easy and nothing ever tells you to delete.

Two ways it stops being followed, neither of them loud

A config rule can go dead in two ways, and both are silent. The first is length. The rule is in there, it gets read, and it still doesn't shape the output, because it's one line competing with a couple thousand others for the model's attention. The second is drift: your conventions move on, but the file keeps steering the agent by the old ones, so it generates yesterday's practice with complete confidence. Both look identical from where you sit. The rule is written. You can point straight at it. And it isn't doing anything.

That's the part I had backwards. I thought a careful enough config file was something I could trust. It can't be, because a config file can't certify its own effect. The proof that a rule is live never comes from the file. It comes from outside it: a test, or a review that catches what slipped through. My CLAUDE.md couldn't tell me the trialware rule had quietly stopped mattering. Only the rejection could.

What I do now instead of trusting it

So I stopped trying to build a config file I could trust, and started trying to measure whether the one I have is still in effect.

In practice that's a few small changes. I keep it shorter than feels comfortable, and I treat adding a line as a cost rather than a free safety net, because every line I add dilutes the ones already fighting for attention. I put a little metadata at the top, an owner and a last-reviewed date, less for the agent than for the version of me six months from now who needs to know whether a section has gone stale. And before I lean on a rule for anything that actually matters, like a directory guideline I can get rejected over, I open a fresh session and ask the agent to tell me which conventions it thinks are currently in effect. Then I read that list for the ones that have gone missing. None of this restores trust in the file. It just gives me a way to keep checking, which turns out to be the only thing that was ever really holding.

A note to my next self

A config file is not as loaded as it looks. The length that makes you feel safe is the same length that dilutes the one rule you're counting on, and you won't feel it happen. Before you add the next line, check whether the last one is still doing anything.

A config file isn't something you write and then trust. It's only as loaded as your last check. Mine was lighter than I thought, and it took a stranger's review to tell me.

Background reading on the monolithic-file problem, context drift, and config-file metadata: Packmind's 2026 context-engineering guides. The experience and the rejection are my own.

Disclaimer: The experiences and decisions in this post are my own. English isn't my first language, so I use an AI assistant to help draft and edit the writing.

AI found 300 WordPress plugin zero-days in 72 hours. I build plugins. Here's what changed for me.

Rapls — Mon, 22 Jun 2026 22:47:18 +0000

Before I released my own AI chatbot plugin, I ran it through a security review. It came back with 35 bugs, three of them critical, and the one that made my stomach drop was an HTML injection coming straight out of unsanitized model output. At the time, that felt like my low point as a developer. Then I read this year's ecosystem numbers, and 35 started to look quaint.

The numbers got loud in 2026

A pipeline built by security researchers, reported by Help Net Security, paired AI static analysis with automated verification and surfaced more than 300 critical zero-days across the WordPress plugin ecosystem in about 72 hours of scanning, with every finding manually verified before disclosure. Patchstack's 2026 report puts a name on one of the causes: vibe coding, where developers ship LLM-generated plugin code they can't actually audit. One agency reported finding 100 distinct security issues in a single vibe-coded plugin.

AI moved both sides of the board at once. It writes plugins fast, and while it's writing it skips the boring security parts: escaping, capability checks, nonce validation. Then it finds those exact holes fast, including on the attacker's side. The two things that used to protect a small plugin, obscurity and time, are both gone. Patchstack measured the weighted-median time from public disclosure to mass exploitation at roughly five hours. The standard advice, keep your plugins updated, assumes you have a window to react. Five hours is not a window.

Why my own plugin had those 35 bugs

This is the part I think solo authors underrate, and it's the same thing that bit me. AI-written code gets trusted twice. Once because the AI wrote it, so it's probably fine. And again inside the code, where model output gets treated as safe and processed without a check. Both of those trusts were wrong in my codebase.

My output-side HTML injection was that double-trust made concrete. I rendered the model's response straight into the page as HTML because I had quietly assumed that since the model generated it, it was clean. It wasn't. Model output carries other people's content inside it: whatever the user typed, whatever a retrieval step pulled off an external page. Treat that as safe and no amount of input-side guarding saves you. It leaks on the way out.

What I actually changed as a one-person shop

I stopped treating "it runs" as "it's safe." I now read every AI-written handler by hand in three places: input, output, and permissions.

On output, I treat the model's response as untrusted input and neutralize it for wherever it's going. Escape for HTML, allowlist for Markdown, validate any URL before fetching it. In WordPress terms that's the unglamorous stuff the model loves to skip: esc_html, wp_kses with a tight allowlist, current_user_can and a nonce check at every AJAX and REST entry point, $wpdb->prepare on every write. None of it is new. It's the web security we've always done, pointed at the half of the code I didn't write myself.

And the surface keeps growing. WordPress 7.0's Abilities API lets plugins expose actions to AI agents in a standard way, which is useful and is also a fresh place for under-scoped permissions to leak. That one I'm watching closely, because a plugin that hands an agent more power than it should is the next version of this same mistake.

The uncomfortable part isn't the code

Here's where I think the 2026 conversation is actually pointing, and it's not a code problem. Patchstack found that 52 percent of plugin developers don't ship a patch before the vulnerability goes public, and that 46 percent of disclosed vulnerabilities had no fix available at all at the moment of disclosure.

So finding bugs is no longer the bottleneck. AI does that in seconds. The bottleneck is everything after. Most plugins are free, maintained by one person between paying jobs, and a plugin earning zero revenue can't justify the cost of a fast security patch. The ecosystem's failure mode in 2026 isn't that bugs are hard to find. It's that the people who would fix them aren't paid to. AI didn't create that gap. It just made it visible at scale and handed attackers a five-hour head start.

That reframes what "responsible" means for someone like me. Writing more carefully is necessary and nowhere near sufficient, because careful or not, the holes I miss are now findable in seconds by someone who isn't on my side.

The deadline nobody's talking about enough

There's a clock on this too. By September 2026, plugin and theme developers distributing to EU users are required by law to have a vulnerability disclosure program. For a solo author that sounds like overhead, but it's the one structural fix that matches the threat: a real channel for someone to report the bug AI found, quietly, before it becomes a public CVE with a five-hour timer attached. Standing one up doesn't have to be heavy. For a solo author, the minimal version is a security contact in the plugin readme or a SECURITY file, a place for reports to land that isn't the public issue tracker, and a stated response window so the reporter knows the message won't sit unread. The point isn't ceremony. It's that the person who finds the bug has somewhere to send it before it turns into a public CVE with a five-hour timer attached.

A note to my next self

The 35 bugs taught me to distrust the code I didn't write. This year taught me the rest of it. The window to fix what I miss is shorter than it has ever been, and obscurity was never protecting me in the first place.

If you ship plugins, AI-assisted or not, the move isn't to write more carefully and hope. It's to assume the holes are already findable in seconds, and to build the parts that catch them first: the hand review of input, output, and permissions, the output sanitization, and a disclosure channel that lets a friendly stranger reach you before an unfriendly one does.

Sources: Patchstack's 2026 State of WordPress Security report (vibe coding, the five-hour mass-exploitation median, the 52% and 46% patch figures, and the EU disclosure-program requirement). The 300-plus zero-days in 72 hours pipeline was reported by Help Net Security. The single-plugin "100 issues" figure and the WordPress 7.0 Abilities API note come from hosting.com's 2026 plugin-security writeup. Please confirm the latest figures against the primary reports before publishing.

Disclaimer: The experiences and decisions in this post are my own. English isn't my first language, so I use an AI assistant to help draft and edit the writing.

GitHub Copilot is usage-based now. Here's what that changes for terminal users.

Rapls — Mon, 22 Jun 2026 03:14:44 +0000

As of June 1, 2026, all GitHub Copilot plans run on usage-based billing. Premium request units are gone. What replaced them is a token-metered currency called GitHub AI Credits: one credit equals one cent, and every model interaction converts into credits based on the input, output, and cached tokens it consumes, charged at each model's published rate.

GitHub's framing is that Copilot outgrew its old pricing. A one-line completion and a multi-hour autonomous run used to cost the same, and once agentic use went mainstream, that flat rate stopped matching the compute behind it. Tying the price to tokens fixes the mismatch.

If your Copilot use is mostly autocomplete, this barely registers. If you drive Copilot as an agent from the terminal, it changes which moves cost money. Here's the practical shape of it.

Requests out, tokens in

Old model: each interaction cost one premium request, scaled by a per-model multiplier, drawn from a monthly request allowance.

New model: each interaction costs whatever its tokens cost on the model you picked. Every paid plan still ships with a monthly pool, now denominated in credits, with the option to set a budget for usage past it. Published figures put the included pool at 1,500 credits for Pro, 7,000 for Pro+, and 20,000 for Max, with pooled per-user allowances on Business and Enterprise.

Worth knowing if you pay yearly: annual Pro and Pro+ subscribers stay on the request-based model until the term ends, and several model multipliers went up for them on June 1. An annual plan doesn't dodge the change. It postpones part of it while making the strong models eat more of the old allowance.

Autocomplete is untouched

Before anyone starts rationing, here's the part that didn't move.

Inline completions and Next Edit Suggestions are still unlimited and still free. If your day is mostly tab-completion in the editor, your costs read identical to May. Nothing to monitor there.

The meter lands on the rest: chat, and especially the agentic runs that open files, plan, run commands, and iterate. That surface is the one that ballooned, and it's the one the new pricing is built around.

The terminal is where it bites

In the CLI you decide which model answers. Until June, that was a quality call and nothing else. Reaching for the strongest model on a trivial task cost nothing you could see.

Now the per-token prices sit behind that choice, and the gap between models is large. One analysis of GitHub's published rates pointed out that output on the priciest listed model runs many times the cheapest, wide enough that grabbing a heavyweight model by reflex is basically a billing bug. Spinning one up to reflow a paragraph isn't just wasteful anymore. It's billable waste.

So for agentic and CLI-heavy work, two ordinary habits become cost decisions: the model you default to, and how long you let a session run. A sprawling all-day agent session now carries a price tied to its length, not just its result.

What "heavy" costs

The included pools feel roomy until you hold them against real agent use. On the GitHub community thread, a Pro+ user reported spending around 360 credits in one ordinary development day and projected a normal month running well past the included 7,000.

That's one workload, not a benchmark, and how near you get depends entirely on how agentic your days are. The signal isn't the number, it's the shape: under the new system, an ordinary day has a credit cost, and for agent-leaning work that cost can rise faster than the monthly pool implies.

New guardrails, and a double charge

GitHub shipped budget controls with the switch, including a hard stop at your limit and a usage view that shows credits draining over the month. There's also a pay-as-you-go path, so you can keep working on your current plan after the included credits run dry instead of being pushed to upgrade.

The wrinkle teams should flag: Copilot code review moved to an agentic architecture, and as of June 1 it consumes GitHub Actions minutes on private repositories on top of AI Credits. A single pull request review can now hit two parts of the bill, the model cost and the runner minutes. Public repos keep their free Actions minutes.

The open question

Cheaper or pricier isn't one answer. For autocomplete-first users it's about flat. For agent-first CLI users the bill now tracks how hard they run sessions and which models they reach for, which can land either way depending on discipline.

Two things to keep an eye on. The price spread rewards matching the model to the task, so a deliberate default plus selective escalation is now a cost strategy, not only a quality one. And the budget hard stop is the cleanest defense against a surprising month, the kind of setting that's better on before you need it than after.

The pattern underneath is the one GitHub says out loud: agentic coding has cloud economics attached now. The terminal feels it first, because the terminal is where the long, autonomous, token-hungry sessions actually run.

Sources: GitHub's announcement "GitHub Copilot is moving to usage-based billing" and the June 1 changelog "Updates to GitHub Copilot billing and plans" (github.blog). Included-credit figures from GitHub Docs; the per-day usage figure from GitHub Community discussion #192948; model-rate analysis from published Copilot per-token rates.

Disclaimer: The experiences and decisions in this post are my own. English isn't my first language, so I use an AI assistant to help draft and edit the writing.

Connecting an MCP server gives your agent hands. It also gives a stranger a way in.

Rapls — Sun, 21 Jun 2026 01:53:52 +0000

The moment you connect an MCP server, your coding agent stops being a thing that reads and writes in your repo and becomes a thing that can reach out and act. Read a database, hit an API, touch a service, pull in a web page. That's the entire appeal. It's also the entire problem, and the two are the same feature seen from two sides.

I went through this wiring up tools for my own plugin work, and the thing that saved me from a worse mistake was a scar I already had. I'd shipped an AI chatbot earlier where I rendered the model's output straight to the page and ate an HTML injection bug. That one taught me a rule the hard way: anything an LLM hands back is untrusted input. MCP is that same lesson with the blast radius turned up, because now the untrusted thing isn't just my model's text, it's whatever a connected server decides to return.

Two different fears, and people only have one

When people talk about agent safety, they almost always mean: what if the agent runs something destructive. Deletes files, force-pushes, curls something it shouldn't. That fear is real and it has a real answer, which I'll get to.

But it's only half the threat, and it's the visible half. The other half is quieter: what if the agent believes something it shouldn't. An MCP server returns an API response, a database row, an issue body, an email thread, and somewhere in that returned content is a line that reads like an instruction. The model has no reliable way to tell your instruction from text that arrived inside data. To it, they're the same channel. So the danger isn't only the command the agent runs, it's the command it gets talked into running by content that came back through a tool.

Those are two separate problems, and they need two separate defenses. Most setups install one and assume they're covered.

The output side: treat every tool return as a form field

Here's the rule I carry over from the chatbot bug. Whatever an MCP server returns is in exactly the same trust category as a string a stranger typed into a form on your site. Not "data from my tool." Data from outside, that happens to arrive through my tool.

That reframe changes what you do with it. You don't pass a tool's raw output straight into the arguments of the next command. You don't render it to a screen without escaping. And you don't let an imperative sentence buried in a returned document quietly become something the agent treats as a directive. The output is a payload to inspect, not a value to trust, and the fact that it came from a server you connected doesn't launder it. You connected the pipe. You didn't vouch for everything that flows through it.

This is the half the tooling won't do for you, because it can't. No sandbox flag knows whether a returned string is a legitimate API result or a planted instruction. That judgment lives in how you wire the data, not in a setting.

The action side: walls, not manners

The other half, the destructive-command fear, does have a settings answer, and it's worth getting exactly right because it's easy to half-do.

Asking the model nicely not to run dangerous things is manners, and manners get bypassed the moment the input talks it into something. What you want is a wall. In Claude Code that's the sandbox: turn it on and Bash execution gets isolated at the OS level, with the restriction inherited by every subprocess the agent spawns. Seatbelt on macOS, Bubblewrap on Linux and WSL2.

// .claude/settings.json
{
  "sandbox": {
    "enabled": true,
    "allowUnsandboxedCommands": false
  }
}

Here's the part that surprised me, straight from the docs: the sandbox restricts writes to your working directory, but by default it still allows reads across most of the machine. Which means credentials like ~/.aws/credentials and ~/.ssh/ are readable unless you say otherwise. The sandbox is a wall around writing and executing, not around reading. Reading you close yourself, with deny rules:

{
  "permissions": {
    "deny": [
      "Bash(rm -rf *)",
      "Bash(curl *)",
      "Bash(wget *)",
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(~/.ssh/**)",
      "Read(~/.aws/**)"
    ]
  }
}

This is the combination that actually matters, and it's exactly where the two halves meet. If a tool return talks the agent into exfiltrating a secret, the read-deny is what stops it from reading the secret, and the network-command deny is what stops it from sending it. The output-side problem is what gets the agent to try; the action-side walls are what make the attempt fail. Neither covers for the other.

The third thing: don't connect what you don't trust, or don't need

The server itself is attack surface. A connected MCP server you didn't vet is code running in your loop with a channel into your agent. So three habits, none of them clever:

Vet the source before you connect it. Who wrote it, can you see the code. An MCP server is not a browser tab you can close and forget; while it's connected, it's part of your trust boundary.

Drop the ones you're not using. Every idle server is attack surface and context weight at once, and /mcp will show you what's actually connected versus what you wired up once and forgot.

And the one I reach for most: if a CLI already does the job, don't stand up a server at all. I drive WordPress with wp-cli, and rather than wrap it in an MCP server I call it from a Skill when I need it. One less always-connected surface, one less thing returning content I'd have to distrust. "Connect a server" and "call a command" are not the same risk, and the second is often the smaller one.

What I actually check now

Before I wire up any MCP server, three questions, in this order. Do I trust where this server came from. What's the worst command it could talk my agent into, and is that command walled off by deny rules. And is the output going to get treated as untrusted input everywhere it lands, or am I about to pass a stranger's text straight into a sink.

The sandbox answers exactly one of those. The other two are on me, and they're the ones that bit me first. Connecting a server is genuinely the moment your agent grows hands. Worth remembering that hands can be guided by whoever's holding the other end of the tool.

I build WordPress plugins and write about AI tooling and security at https://raplsworks.com/.

Disclaimer: The experiences and decisions in this post are my own. English isn't my first language, so I use an AI assistant to help draft and edit the writing.

I Created a Gemini API Key and Got AQ. Instead of AIza

Rapls — Sat, 20 Jun 2026 02:13:04 +0000

I created a free Gemini API key in Google AI Studio. When I went to copy it, I stopped. It started with AQ.Ab. Not the AIza I had been looking at for as long as I can remember.

My first thought was that something had gone wrong with my account. A leaked key, or a restriction, or some flag on the project. I looked into it, and it was none of that. Google is partway through changing how API keys are issued, and a freshly created key now comes out in the new format. Nothing broke. This is the plan.

That said, you can't drop the new key into every path and expect it to work. Some routes reject it. I run a WordPress plugin called Rapls AI Chatbot, and one of its no-card onboarding paths uses the Gemini free tier, so the first thing I did was check what was affected. Here is the short version before the details. The new AQ. key works fine on the native Gemini endpoint. It gets rejected on OpenAI-compatible endpoints and by some third-party tools that assume the AIza format.

Checked: June 2026
Issued from: Google AI Studio (free tier)
Routes tested: native generativelanguage.googleapis.com and OpenAI-compatible /v1beta/openai
Reference: Google docs, "Using Gemini API keys" https://ai.google.dev/gemini-api/docs/api-key

From AIza to AQ., what is actually happening

Google is moving Gemini API keys from the old Standard key (AIza...) to a new Auth key (AQ.Ab...). Keys you create in AI Studio now come out as Auth keys automatically. So someone who saw AIza yesterday gets AQ. today. That is what happened on my end.

There are dates attached, and this was the part that mattered most. Starting June 19, 2026, the Gemini API began rejecting requests from unrestricted Standard keys. By the time I am writing this, that deadline has already passed. Then in September 2026, Standard keys get rejected outright. Restricted or not, an AIza Standard key stops working after September.

One thing worth adding. A Standard key with an explicit restriction keeps working past June 19. So it is not that every AIza key died on the 19th. The unprotected ones go first, and the rest follow. It is a staged shutdown.

Auth keys behave a little differently in one place. Requests authenticated with an Auth key do not show up in Google Cloud's service account usage metrics. The project and key live on the AI Studio side. If you have been watching requests in the Cloud Console, your numbers may stop adding up, and that is why.

The trap I hit was compatibility, not the key itself

The format change matters less than the compatibility fallout. The AQ. key has a few known snags. Here is what I saw in my own testing alongside what people are reporting on the official forum.

Route	How the key is passed	What the `AQ.` key does
Native Gemini	`?key=` query or `x-goog-api-key` header	Works. curl returns 200
OpenAI-compatible	`Authorization: Bearer` to `/v1beta/openai/...`	400 with `Multiple authentication credentials received`. 401 in some implementations
AIza-assuming third party	Tool expects the `AIza` format internally	`401 invalid_api_key`

Native is fine. If you hit generativelanguage.googleapis.com directly and pass the key as a query param or header, AQ. goes through the same as before. The official SDKs (google-genai and friends) handle that internally, so going through an SDK you probably will not even notice.

The OpenAI-compatible path is where it jams. Send an AQ. key with Authorization: Bearer to an OpenAI-compatible endpoint and it can come back with Multiple authentication credentials received, as if you passed credentials twice. In the same family of reports, a key that returns 200 through the native route still comes back as 401 invalid_api_key once a tool quietly routes it through an OpenAI-compatible transport. The nasty part of that second case is that the key is alive, but the error says the key is invalid. Trust the message, blame the key, and you never get out of the loop.

Some desktop tools that assume the AIza format throw the same 401.

In my case, the plugin talks to Gemini natively, so the AQ. key sailed through. To be safe I ran a new AQ. key through a full round trip, and it sent and received without trouble. I am folding that confirmation into the plugin's guidance in an update going out the next day. If I had been routing through an OpenAI-compatible path, users would have hit a 401 the moment they pasted a new key. With something you ship, your code being correct does not help. What piles up is a stack of "I entered the key and it will not work" reports. I was glad I checked first.

If you are still on an AIza key

This part I will spell out. If you are running on a key that starts with AIza and it still works, that is not a reason to relax. The dates above are why.

Check whether the key is restricted. In the AI Studio key list, if a key carries the Unrestricted label, that is the kind that stops after June 19. To keep it alive, restrict it. Hover the Unrestricted label on the API Keys page, click Add restrictions in the dialog, choose Restrict to Gemini API only, and confirm with Restrict key. Now it is locked to the Gemini API and keeps running past June 19.

This restriction only buys time. September pulls in Standard keys as a whole, so even a restricted AIza key eventually stops. Treat it as breathing room for an unhurried migration, nothing more. The destination is the AQ. Auth key.

Restricting a key needs the apikeys.keys.update permission on the relevant Google Cloud project, which the API Keys Admin and Editor roles already include. If your key is shared across other Google APIs (not a setup you want), you restrict it from the Cloud Console rather than AI Studio.

For what it is worth, the forum also has a separate thread about accounts getting restricted and no longer being able to create AIza keys at all. The AQ. issuance here is unrelated. It is the format change that applies to everyone. A new key coming out as AQ. does not mean something is wrong with your account.

One line of action

Put together, there is not much to verify on your end. If you are using a new AQ. key, confirm your traffic goes to the native Gemini endpoint. If you run an OpenAI-compatible path, test on real hardware whether Authorization: Bearer accepts the AQ. key. If you are still on an AIza key, restrict it to buy time and move to AQ. before September. That is the whole list.

Back to where I started. Staring at AQ.Ab in AI Studio with my hand frozen over the copy button, I suspected the key. What I actually had to fix was not the key. It was how I was handing the key to each route. If you froze at the same screen, point your suspicion at the route first.

Reference: Google AI for Developers, "Using Gemini API keys" https://ai.google.dev/gemini-api/docs/api-key

Disclaimer: The experiences and decisions in this post are my own. English isn't my first language, so I use an AI assistant to help draft and edit the writing.

I automated everything except the code, and that's where Claude Code actually paid off

Rapls — Fri, 19 Jun 2026 23:54:19 +0000

I build WordPress plugins on my own, and I started using Claude Code for the obvious reason: to write code faster. Six months later, the part it actually saved me wasn't the code at all. It was everything around the code.

Every release, I ran the same small gauntlet. Bump the version, update the readme, write the changelog, check the translation files for gaps, draft the announcement. None of it is hard. All of it is fiddly, and every one of those chores pulled me out of the part of my brain that was actually building the thing. By the time I'd finished the release ritual and came back to code, I had to reload the whole mental context I'd just dropped.

That reload is the real cost, and it took me a while to see it. The chores don't just eat their own time. They evict the code from your head, and you pay again to bring it back. So I started handing the chores to Claude Code instead of the code, and that was the version that worked.

The chore that breaks releases silently

The one I least wanted to get wrong is version mismatch. In a WordPress plugin, the displayed version comes from the Version header in the main PHP file, but the readme's Stable tag points at which tagged version is "stable." They are two separate fields with two separate jobs, and when they disagree, updates can reach users wrong. No error fires. You find out from a bug report.

This is a perfect chore to hand off, because it's pure checking, no judgment. I keep the steps in a file and have Claude Code run them before every release:

does the main file Version match the intended release
does the readme Stable tag point at the right thing
is the top changelog entry actually this version
is Tested up to tracking the current stable WordPress, and not set higher than it should be

The important half is the instruction I attach to it: surface mismatches, don't fix them. Show me the file and line, and let me make the call. I don't want the convenience of auto-correction on the one step where a wrong guess ships to users.

I stopped writing the prompt and made it a command

The version check is identical every single time, so writing the prompt by hand each release was its own small chore. I moved it into a reusable command.

Worth knowing if you're on a recent Claude Code: custom slash commands got merged into Skills back in the April update. The old .claude/commands/ files still work, but the current home is .claude/skills/<name>/SKILL.md, which gets you the same /name invocation plus the option of Claude calling it on its own when the context fits.

Mine looks roughly like this:

---
name: release-check
description: "Check a WordPress plugin's version and readme consistency before release. Use right before shipping."
allowed-tools: Read, Grep, Bash(grep:*)
---

# Release check

Verify before release:
1. main PHP Version header vs readme Stable tag
2. top changelog entry is this version
3. Tested up to tracks current stable, not above RC

Report mismatches as file + line. Do not edit. The human decides.

Two things earn their place here. The allowed-tools line scopes it to reading and grep, so a check can't quietly turn into an edit. And the description says when to use it in plain terms, which is what lets Claude reach for it at the right moment instead of guessing. Now the whole thing is /release-check and I never retype it.

Turning developer noise into user-facing notes

The other recurring time sink is the readme and changelog. WordPress readmes use their own markdown subset with a fixed shape, so turning a pile of commits into the right section is well-suited to a model, as long as you keep it honest.

I hand it the commit range and ask for a draft:

git log --oneline v1.9.2..HEAD

Then: rewrite these as a user-facing changelog, keep the format, and where a number or detail isn't certain, write (to confirm) instead of guessing. That last rule matters more than it looks. Left alone, a model fills every gap smoothly, and smooth is exactly what hides the spot you needed to check. Forcing it to leave the uncertain parts visibly blank means I catch them.

The translation step works the same way: I have it diff the .pot against each .po and list only the untranslated strings, no translating yet. See the gap first, decide second. Same shape as the version check: show me the state, don't act on it.

One small landmine I hit once: WordPress readmes don't render tables, and if the file grows past about 10KB the parser starts misbehaving. So when the changelog gets long, I have Claude move the old entries into a separate changelog.txt, as a pure move, no rewriting. The rule there is explicit: relocate, don't summarize, or you lose the history.

Where I draw the line

I keep all of this at half-automation on purpose. Three things stay manual: hitting the release button, the wording that users actually see, and merging code. Everything Claude produces arrives as a draft or a check result, never as a done deal.

That isn't caution for its own sake. Hand the whole thing over and you end up shipping text to users that nobody read first, and for a plugin that's a trust problem, not a time problem. The allowed-tools scoping and the forced (to confirm) markers are both just mechanisms for holding that line: let the machine do the fetching and the diffing, keep the judgment with me.

The part I didn't expect

I went in wanting Claude Code to make the coding faster. What it actually did was give me the coding back, by clearing the rubble around it.

The chores were never the expensive part on their own. The expensive part was what they did to focus: each small task knocked the code out of my head, and the reload was the tax. Moving the chores off my plate didn't just save their minutes. It let me stay in the build instead of climbing back into it five times a release. If you're reaching for an AI agent to write more code, it's worth checking whether the thing actually slowing you down is the code at all, or the ring of small jobs around it that keep breaking your attention. For me it was the ring, and that's the part worth handing off first.

I build WordPress plugins and write about AI tooling and security at https://raplsworks.com/.

Disclaimer: The experiences and decisions in this post are my own. English isn't my first language, so I use an AI assistant to help draft and edit the writing.

Write your error states for a stranger three months from now, not for yourself today

Rapls — Thu, 18 Jun 2026 23:40:13 +0000

Most error messages are written for the wrong reader.

They're written for the person who's watching when the thing breaks. You're at the terminal, the run fails, the message says connection refused or validation failed at step 3, and that's enough, because you have all the context in your head right now. You know what you were doing, what you changed, what the system was supposed to do. The message just has to jog a memory you already have.

The reader who actually needs the error state is someone else entirely, and they show up months later. I got talked into this view in a long comment thread on an earlier post, and it changed how I think about failure handling, especially for the async, agent-driven work I do a lot of now.

The reader you're not designing for

Here's the gap. When an interactive tool fails, there's a human in the loop who reacts immediately. The error can be terse because the context is live. You scroll up, you see the conversation, you fix it.

Async work has none of that. An agent runs a pipeline at 2am, something fails partway, and nobody sees it land. There's no conversation to scroll back through, no replay button, no warm context in anyone's head. Whoever investigates shows up cold, hours or weeks later, and the only thing they have is whatever the process wrote down before it stopped.

Which means, for that reader, the error state isn't a report about the failure. It is the failure, as far as they can ever see. If the record doesn't contain what they need to reconstruct what happened, the information is gone. Not hard to find. Gone.

That reframes the whole design question. It stops being "how do we format this error" and becomes "what does an investigator need to rebuild this run from nothing." Those are different specs, and almost every error message I've ever written was quietly answering the first one.

A message versus a record

The cleanest way I can put the distinction: most errors are a message, and what async work needs is a record.

A message is written for someone who shares your context. It can be short because it's pointing at things you both already know. "Validation failed" is a fine message when you're standing right there.

A record is written for someone who has nothing. It has to carry the context with it, because there's no shared memory to lean on. What was the input. What stage was this. What did the system believe was true when it decided to proceed. What got retried, how many times, with what result. A record is heavier on purpose, because its whole job is to survive the gap between the failure and the person who reads about it.

The test I use now: if I deleted the rest of the system and handed someone only this error state, could they tell me what went wrong? If the answer depends on context that lives anywhere other than the record itself, I'm writing a message and calling it a record.

The gap is also where organizations forget

There's a second reason the later reader has nothing, and it's not just time. It's people.

The person who built the system often isn't the person debugging it three months on. They've moved teams, moved companies, or just moved on to other work and dumped the context. So the investigator isn't even future-you, who at least shared your assumptions once. It's a stranger who was never in the room when the decisions got made.

That's the strongest version of the spec, and the most honest one. You're not writing for yourself later. You're writing for someone who has none of your context and never did, and who is meeting your system for the first time through its failure. If the error state only makes sense to someone who already understands the system, it's useless to exactly the person most likely to be reading it.

What this changes in practice

I haven't rebuilt everything. But a few habits shifted, and they're cheap.

I write error states as if the reader has no access to the rest of the run. Not "step 3 failed" but what step 3 was trying to do, what it received, and what it expected. The extra sentence costs nothing now and saves an hour later.

I treat the clean error state as the audit trail I'm choosing to have, rather than a thing I bolt on if there's time. In async work there's no other trail. Either the failure left evidence or it didn't, and that's decided when I write the handler, not when the incident happens.

And I stopped optimizing failure output for the demo. The version that looks good when you're watching it succeed is not the version that helps when it fails unattended. Those are different audiences, and the unattended one is the one that actually needs help.

The smallest version of the idea

If I compress all of it into one line, it's this: useful right now and useful in three months are different specs, and you usually only get to satisfy one of them, so pick the harder reader.

Pick the stranger. Write the record they'd need, not the message you'd understand. You won't be in the room when it's read, and the whole point of an error state is to work when you're not there.

I build WordPress plugins and write about AI tooling and security at https://raplsworks.com/.

Disclaimer: The experiences and decisions in this post are my own. English isn't my first language, so I use an AI assistant to help draft and edit the writing.

DEV Community: Rapls

My Claude Code auto mode config still said GITHUB_ACCOUNT_HERE. One command found it.

What the autoMode block is

Check 1: does every list you set still have "$defaults"?

Check 2: what is the classifier actually using?

Two more commands worth knowing

Why I missed it

The two-minute check

I thought Claude Code would make my work lighter. I became its checker instead. Here's every file I wrote to stop

What I wanted to hand off was checking, not writing

1. CLAUDE.md: write the reason next to the rule

Say what's banned, and what isn't

The release zip, and "empty means pass"

Keep the places that broke before

2. AGENTS.md: a find-and-replace copy that broke silently

3. settings.json: stop it with mechanisms, not requests

Sandbox: decide which roads are open

Auto mode: tell it what's normal here

4. A hook: never lose the folder twice

5. Handovers: make the new session start itself

6. Ask for evidence with "done"

Checklist

My Cursor state.vscdb was 8.9 GB. You can work out how much VACUUM will save before you run it

Deleting rows doesn't shrink the file

VACUUM needs about twice the final size in free space

Quit Cursor first

The .backup file

Checklist

Reproduce it

php -v over SSH doesn’t tell you which PHP your website runs

Same machine, two answers

Why they drift apart

It wasn't only the version

Checking the PHP your site actually runs

What I check now

Claude Code now blocks the git command that almost cost me a day's work. I'm keeping my deny rules anyway.

The guard is real, and it's a classifier, not a rule

Three reasons my hand-written lines stayed

Inference is not the only layer, and neither is the sandbox

What I actually changed

A note to my next self

I trusted my CLAUDE.md. WordPress.org rejected the exact thing it was supposed to prevent.

Written is not the same as in effect

Two ways it stops being followed, neither of them loud

What I do now instead of trusting it

A note to my next self

AI found 300 WordPress plugin zero-days in 72 hours. I build plugins. Here's what changed for me.

The numbers got loud in 2026

Why my own plugin had those 35 bugs

What I actually changed as a one-person shop

The uncomfortable part isn't the code

The deadline nobody's talking about enough

A note to my next self

GitHub Copilot is usage-based now. Here's what that changes for terminal users.

Requests out, tokens in

Autocomplete is untouched

The terminal is where it bites

What "heavy" costs

New guardrails, and a double charge

The open question

Connecting an MCP server gives your agent hands. It also gives a stranger a way in.

Two different fears, and people only have one

The output side: treat every tool return as a form field

The action side: walls, not manners

The third thing: don't connect what you don't trust, or don't need

What I actually check now

I Created a Gemini API Key and Got AQ. Instead of AIza

From AIza to AQ., what is actually happening

The trap I hit was compatibility, not the key itself

If you are still on an AIza key

One line of action

I automated everything except the code, and that's where Claude Code actually paid off

The chore that breaks releases silently

I stopped writing the prompt and made it a command

Turning developer noise into user-facing notes

Where I draw the line

The part I didn't expect

Write your error states for a stranger three months from now, not for yourself today

The reader you're not designing for

A message versus a record

What the `autoMode` block is

Check 1: does every list you set still have `"$defaults"`?