`wp user list` not paginated by default

[MaximeMichaud]

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

1. Have a WordPress database with 500k+ users (common with WooCommerce or membership plugins).
2. Run wp user list.
3. 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.

[swissspidy]

As you've noticed, all the list commands aren't paginated by default.

Previously:

• wp post list pagination wp-cli#4746

Related:

• Use PHP generators to get around some memory limitations ideas#81
• Make large queries scalable ideas#91

[MaximeMichaud]

@swissspidy What's changed since #4746 / #81 / #91 is the usage pattern. LLM-based coding agents now run wp user list and friends autonomously, without --number, with no operator instinct to Ctrl+C when the host starts thrashing. The 2018 assumption ("use posts_per_page yourself") relied on a human reading the docs first. That assumption doesn't hold in agent-driven workflows.

Streaming is blocked on the Formatter table buffer, fair. But a stderr warning when the result count crosses a threshold and --number is 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]

That's true, it's one of the ideas I listed at wp-cli/wp-cli#6161