I manage close to 3,000 WordPress sites. Every one of them generates email messages. Password changes. Registration alerts. Uptime monitors. Plugin mismatch warnings. Kinsta error notifications. WordPress recovery mode alerts. Domain renewal notices. Google Workspace billing.
It adds up fast. On a typical week, hundreds of these pile up. Most are noise. But buried in the noise are real problems. A site throwing PHP fatals. A plugin install that corrupted during update. A theme that started breaking on PHP 8.3.
The challenge isn’t reading the emails. It’s triaging at scale without missing the signal.
Give AI a CLI to your inbox
I’ve been using Claude Code to process my inbox. Not as a summarizer or a chatbot. As an operator. It searches my email, categorizes what it finds, SSHs into servers, reads error logs, diagnoses root causes, applies fixes, and logs the work. All from short conversational prompts.
The key ingredient is giving AI access to your email through a CLI. I built a WP-CLI plugin called Missive CLI that lets me search, read, close, and draft emails from the command line. Once Claude Code can run those commands, email becomes just another data source it can operate on.
Search for a subject. Pipe the IDs to a close command. Read a conversation thread to understand context. It’s the same pattern as giving it SSH access to servers. The more tools the AI can reach, the more useful each conversation becomes.
I’ll admit I overthought this at first. I built a dedicated /email-triage skill with priority tiers, granularity rules, Kanban board integration, and a four-phase pipeline that synced, exported, analyzed, and populated cards. It was clever. It was also completely unnecessary.
I threw it away. The conversational approach is better. Instead of pre-defining categories and priority rules, I just tell Claude what to look for and make decisions as we go. “Pull up the monitor alerts.” “Group these by site.” “SSH into the ones from this week.” “Close the rest.” Each prompt builds on the last.
I’m the triage master. Claude is the operator. No skill file needed.
Here’s what a single session looked like.
Starting with the noise
I started by asking Claude to search for open emails by category. The first pass was purely about clearing noise. Automated notifications that don’t need human attention.
Each category takes one sentence to clear. Claude searches, confirms the count, and closes them in bulk. No scripting required. I moved through ThemeForest update notifications, Missive receipts, WooCommerce order confirmations, and Google Workspace billing alerts the same way.
Before closing the Google Workspace batch, Claude flagged that 4 out of 26 emails were actual conversations with people, not automated notices. It kept those open. That’s the kind of judgment call that matters when you’re bulk-processing.
The numbers
Across two sessions on the same day, here’s what got processed:
The largest category was uptime monitor alerts. Over 900 of them. Most were the same 15 sites appearing in every alert for months. Some were decommissioned sites, some were customer sites on other hosts that we monitor but don’t control. Clearing those alone freed up the inbox significantly.
When noise becomes signal
The interesting part isn’t the bulk closing. It’s what happens when you pause on a category and look closer.
I asked Claude to pull up all 50 “We’ve detected an error” emails from Kinsta and group them by site. Then I asked it to SSH into every one and check the server logs.
Out of 50 error emails covering 15 sites, only 4 had real problems. Claude SSHed into all sites simultaneously, read the error logs, and produced a diagnostic summary. The whole review took about 2 minutes.
Fixing what we found
One of the errors turned into a proper investigation. A site running a custom theme was throwing a PHP Fatal on author archive URLs. The error pointed to a function in our CaptainCore Helper mu-plugin.
I asked Claude to check the deployed version against the latest source. It compared both and initially suggested the fix was already in the newer version. I pushed back. The guard it pointed to existed in both versions. Something else was going on.
Claude was wrong the first time. I corrected it. It then re-examined the code, and it found the real root cause. The theme had no 404.php template. On PHP 8.3, calling include ” throws a ValueError instead of silently failing as it did on PHP 7.x. A one-line guard fixed it.
On another site, a custom WooCommerce theme called Redwood was generating hundreds of PHP warnings per day. Four files, all with the same pattern: accessing array offsets and variables without null checks. Code that worked fine on PHP 7 but is noisy on PHP 8.3. Claude SSHed in, read each file, and patched all four.
$rows[0]['title'] without checking if $rows was a non-empty array. 8 warnings per product page.$offset and $exclude expected from parent template but not always passed.$thisID in the is_search() branch. Added default.A third fix involved a corrupted WP Migrate Pro install on a different site. The plugin’s auto-updater was broken, so Claude sourced version 2.7.7 from another managed site, transferred it via SCP, and replaced the plugin directory. Site came back clean.
The 182 recovery mode emails
WordPress sends “Your Site is Experiencing a Technical Issue” emails when it catches a PHP fatal and enters recovery mode. I had 182 of them open. Before closing, I asked Claude to group them by the offending plugin.
Rank Math SEO PRO was causing fatal errors on 5 sites. CleanTalk’s anti-spam plugin was hitting 8 sites. The Events Calendar was firing on 2 sites, but generated 12 emails between them. Role-Based Pricing for WooCommerce was crashing on a single site repeatedly.
For the two that appeared this week, Claude SSHed in and investigated. One was the WP Migrate Pro fix described above. The other was a version mismatch between All-in-One WP Migration and its Unlimited Extension. That one needs a manual download from the vendor.
The rest were older, and the sites had self-recovered. All 182 closed.
Monitor alert analysis
The 900+ monitor alerts were the biggest batch. Before closing, I asked Claude to read through them and tell me which sites were actually down this week versus which ones had been appearing in alerts for months.
Eight sites had been in every alert for 6+ months. Decommissioned sites, cancelled hosting, domains that expired. Those should be removed from monitoring entirely.
Five sites went down this week. Three recovered on their own. Two are still down. Six more were flapping briefly throughout the day but came back.
That’s the value of reviewing before closing. Closing 900 emails takes one command. Knowing that two sites are still down, and which eight should be removed from monitoring, takes a conversation.
The workflow
The pattern that emerged across the session is simple. Search a category. Review what’s there. Close the noise. Investigate the signal. Fix what you can. Log the work. Move on.
Claude handles the mechanical parts: searching Missive, resolving SSH connections via the CaptainCore API, connecting to servers in parallel, reading logs, and comparing file versions. I handle the judgment calls: is this noise or a signal? Should we fix this now or flag it for later? Is Claude’s diagnosis right, or should it look again?
Corrections carry forward. When I corrected Claude’s initial diagnosis of the 404 template error, it re-examined the code and found the real issue. When I pointed out in a previous session that it should always curl the actual script URLs during security reviews (not just check if the script tag exists on the page), it saved that as a persistent memory. Future sessions apply the correction automatically.
What this means at scale
Managing 3,000 WordPress sites means dealing with a constant stream of automated notifications. Most of them are informational. Some are actionable. A few are urgent. The hard part has always been sorting them efficiently without letting real problems sit unnoticed in a sea of noise.
With Claude Code, I processed over 1,600 emails in a single afternoon. Not by blindly closing them. By reviewing categories, investigating the ones that mattered, fixing four sites, patching six files, and logging everything to our process tracking system.
At the end of each session, I ask Claude to generate a report. It produces a styled HTML page with stat cards, bar charts, and a breakdown of every action taken. Categories cleared, sites investigated, fixes applied, follow-up items flagged. It turns email triage into a game with a scoreboard at the end. You start the session staring at 1,000+ open emails, and you finish with a clean inbox and a report that proves the work happened.
That changes the psychology of the task completely. The inbox isn’t something I dread anymore. It’s a conversation with a score to beat.