The advice you usually read about running coding agents at the same time is all about attention: keep an overview screen, get an alert when an agent needs input, read a recap before you pick a thread back up. Eivind Kjosbakken makes that case in his post about parallel Claude Code sessions on Towards Data Science, and the techniques are real. I use most of them.
But attention is the easy part. On WordPress client work, parallel sessions break somewhere else first: two agents in the same checkout, or two agents against the same database. No overview screen fixes either of those.
What the overview tools solve
The agents view in Claude Code, opened with claude agents, gives you one line per running session instead of one full screen per session, and it marks which ones are waiting on you. That alone replaces a lot of tab switching. Warp does something similar by putting a star on a tab when the session in it needs input, which is the same idea with less surface. Recaps, the short summary above the input field, help when you have been away from a thread for ten minutes and forgot what you asked for.
Notifications are the part a WordPress developer can wire up quickly, because Claude Code hooks work like actions and filters with different names. You register a command against an event, and the event fires regardless of what the model decides, the same way wp_head runs whether or not your code is clever. The hooks guide ships a ready-made example that pops a desktop notification whenever a session needs input. It goes in ~/.claude/settings.json:
{
"hooks": {
"Notification": [
{
"matcher": "",
"hooks": [
{
"type": "command",
"command": "osascript -e 'display notification \"Claude Code needs your attention\" with title \"Claude Code\"'"
}
]
}
]
}
}Recaps I am more lukewarm on. A summary tells you what you asked for, but most context problems are better solved before the session starts, with a CLAUDE.md that states the conventions. I have written about keeping that context in one place before, and it beats reconstructing intent from a recap every time.
Where parallel Claude Code sessions collide
The source is honest about the precondition: tasks running in parallel need to be disconnected from each other. On a WordPress site that is rarely true. The child theme, the custom plugin and the mu-plugin all ship to the same site, so even disconnected tasks end up merged into the same release, and the only question is whether you find out before the work starts or at review time.
The common setup is one checkout with tabs or split panes per agent. It works until two sessions both run npm run build and the second build overwrites the output of the first, or both land edits on the same branch and your git status becomes two agents interleaved. Then you review one diff that contains two tasks, and that is what eats the afternoon.
A worktree per session is the other option. git worktree add creates a second checkout of the same repository, with its own branch and index but a shared object database, so each session works in its own directory and produces its own diff. The git documentation calls these linked working trees:
git worktree add ../shop-checkout-fix -b agent/checkout-fix
cd ../shop-checkout-fix
composer install && npm install && npm run buildThe costs are real but small. Untracked directories like node_modules and vendor do not come along, so each worktree gets its own install and its own build, which costs disk and a few minutes of waiting per session. On client repos with heavy builds, that wait adds up. You pay it in reverse too: git worktree remove when the branch merges, plus the occasional git worktree prune to clean up stale metadata.
So the rule I use: keep the same checkout with split panes when the tasks are small and don’t overlap (a block style in one file, a WP-CLI data fix that touches no code), and switch to one worktree per session the moment two tasks will each touch functions.php or templates and need separately reviewed diffs. I default to worktrees because the review is what I am protecting.
The database doesn’t know about worktrees
Worktrees isolate files but not state. Every worktree that carries the same wp-config.php points at the same database, the same uploads directory, and, if you run Redis locally, the same object cache. Two agents against one database get in each other’s way: one renames an option while another imports orders, and tests that pass for the wrong reasons.
The cheap fix is per-worktree configuration. wp-config.php is untracked on most projects anyway, so each worktree can point at its own database name, or at least its own table prefix. Sessions that only read can share the main database. Sessions that write (migrations, order imports, WooCommerce settings changes) run one at a time against their own copy. That limit comes from the data model.
There is also the review problem, which overview posts tend to skip. Five parallel sessions, the example the source uses, still hand you five diffs you read serially. The bottleneck moves from writing code to judging it. The setup that pays off is the one where each branch can check itself: tests or at least a scripted smoke check per worktree, so by the time I open the diff the boring questions are already answered. I have argued before that the test loop is what decides agent performance, and parallel work only sharpens that. I read diffs one at a time and merge in dependency order, which sounds slow and is still faster than writing all five myself.
One thing I am not sure about is multisite, where one database backs several sites and per-worktree prefixes get awkward. I would treat that as one more reason to keep anything touching site options in a single session.
Which setup for which kind of site
For a plugin or any standalone code repository, worktrees are close to free. No database, tests run per branch, and you can run as many sessions as your plan allows and your attention deserves. This is where the advice about managing agents like a team holds up.
A theme or child theme engagement sits in between: worktrees for the code and one shared dev database is usually enough, as long as the tasks stay away from data. Most template and block work reads the database more than it writes it.
For a full WooCommerce build, treat the database as the shared resource it is. Put code tasks in worktrees, run data tasks one at a time, and take a staging snapshot before any session touches settings. WooCommerce keeps a lot of state in options and postmeta as serialized PHP, and an agent that fixes that with raw SQL is how a quiet bug ships to a live store.
If you want this kind of setup on a project, it’s the work I do: I wire worktrees and notification hooks into an existing WordPress or WooCommerce repo and split the local databases so agents stop stepping on each other.
On a client site this week I’d start with the unglamorous half: one worktree per remaining task, the notification hook so I stop polling tabs, and a database snapshot before the first session runs. The overview screen comes after all three.
