Repository navigation
wp user list not paginated by default #616
Description
Bug Report
- Yes, I reviewed the contribution guidelines.
- Yes, more specifically, I reviewed the guidelines on how to write clear bug reports.
Summary
While running wp user list on a production database with ~740k users, the process consumed 20+ GB of RAM, filled swap entirely, and had to be manually killed. The command never completed.
Steps to reproduce
- Have a WordPress database with 500k+ users (common with WooCommerce or membership plugins).
- Run
wp user list. - Observe RAM usage climbing continuously until the system becomes unresponsive or the OOM killer fires.
Environment
OS: Linux 7.0.6-1-cachyos #1 SMP PREEMPT_DYNAMIC Mon, 11 May 2026 15:10:22 +0000 x86_64
Shell:
PHP binary: /usr/bin/php8.4
PHP version: 8.4.21
php.ini used: /etc/php/8.4/cli/php.ini
MySQL binary:
MySQL version:
SQL modes:
WP-CLI root dir: phar://wp-cli.phar/vendor/wp-cli/wp-cli
WP-CLI vendor dir: phar://wp-cli.phar/vendor
WP_CLI phar path: phar:///usr/local/bin/wp
WP-CLI packages dir: /root/.wp-cli/packages/
WP-CLI cache dir: /root/.wp-cli/cache
WP-CLI global config:
WP-CLI project config:
WP-CLI version: 2.12.0
Results and impacts
Severity: High
Expected results: wp user list completes and outputs the user list, or fails gracefully with an error if the dataset is too large.
Actual results: PHP allocates 20+ GB of RAM (the entire system memory + swap), the machine freezes, and the process must be killed manually with kill -9.
Workaround
Pass --number=100 explicitly to limit results, or query the database directly with SQL:
SELECT ID, user_login FROM wp_users LIMIT 100;Relevant diagnostics
Running with --debug is not practical as the process consumes all system memory before producing useful output.
From ps aux before killing the process:
root 3808631 5.4 21.3 27706340 6818676 ? Ds May18 9:43 php /usr/local/bin/wp --path=/var/www/html/wordpress user list --fields=ID,user_login --allow-root
VSZ: 27 GB, RSS: 6.5 GB, the rest in swap.
Possible solution
Add a default limit to the get_users() call in User_Command::list_(), or paginate internally in batches.
Activity
[-]wp user list consumes 20+ GB RAM on 740k users, never completes[/-][+]`wp user list` not paginated by default[/+]swissspidy commentedon May 20, 2026
As you've noticed, all the list commands aren't paginated by default.
Previously:
Related:
MaximeMichaud commentedon May 25, 2026
@swissspidy What's changed since #4746 / #81 / #91 is the usage pattern. LLM-based coding agents now run
wp user listand friends autonomously, without--number, with no operator instinct to Ctrl+C when the host starts thrashing. The 2018 assumption ("useposts_per_pageyourself") relied on a human reading the docs first. That assumption doesn't hold in agent-driven workflows.Streaming is blocked on the
Formattertable buffer, fair. But a stderr warning when the result count crosses a threshold and--numberis absent doesn't touch the Formatter, doesn't break scripted callers, and would have stopped my host from going into uninterruptible disk sleep, SIGKILL-only, on one command. That kind of guard should already exist in 2026, the gap costs real outages now, not slow scripts.swissspidy commentedon May 25, 2026
That's true, it's one of the ideas I listed at wp-cli/wp-cli#6161
swissspidy commentedon Aug 9, 2026
Closing in favor of wp-cli/wp-cli#6161
Last time I discussed with schlessera, we both felt that this isn't really an issue with SOTA models. They all know WP-CLI really well and automatically add pagination everywhere. No handholding or BC break necessary.
MaximeMichaud commentedon Aug 10, 2026
I created this issue based on experience. If you are unable to see the problem, then this comes down to either a lack of understanding or incompetence. And not all models are trained the same way, nor are they all frontier models.
Thanks.
swissspidy commentedon Aug 10, 2026
Huh, no need for such a harsh tone.
The discussion can continue in wp-cli/wp-cli#6161. In the meantime I recommend using AGENTS.md or skills to steer your agents, or a wp-cli.yml config file with default arguments.
MaximeMichaud commentedon Aug 10, 2026
I can be wrong about many things, but this issue was not theoretical, nor was it the result of me misunderstanding how WP-CLI should be used.
I was using WP-CLI in production on a very large WooCommerce store, and a frontier Anthropic model ran
wp user listwithout pagination. The command exhausted the available memory and swap and effectively brought the host to its knees. That is an actual failure mode I experienced, not a hypothetical concern or a hallucination on my part.Now that I know about this behavior, I can obviously add more explicit instructions to my agent through
AGENTS.md, skills, or configuration. That may mitigate the problem for me going forward. But it does not really address the underlying issue.There is no guarantee that an agent will follow every Markdown instruction perfectly, even a frontier model, and not everyone using WP-CLI for the first time will know that an unbounded list command can consume tens of gigabytes of memory on a sufficiently large installation.
My concern is that a relatively simple architectural footgun remains exposed by default, while the proposed mitigation is essentially to make every caller aware of it in advance.
So I was not trying to be harsh for the sake of it. I was frustrated and disappointed because I reported a real production incident, with concrete diagnostics, and the response seemed to dismiss the failure mode on the assumption that SOTA models already know better. In my case, demonstrably, one did not.