Make current_user_can() Always Return true in WP-CLI Context

[tyrann0us]

Proposal:
In WP-CLI, the function current_user_can() currently returns false by default because there is no authenticated user during command execution. This causes issues when using functions like wp_insert_post() with tax_input in custom WP-CLI commands, as the capability check fails, preventing terms from being assigned.

I propose that current_user_can() should always return true in WP-CLI context, given that using WP-CLI already implies full administrative control over the WordPress installation.

Rationale:

1. Full System Control Already Exists – A user with WP-CLI access can create (super) administrators, modify database entries, and override any permissions manually. Since WP-CLI is an inherently privileged tool, enforcing capability checks does not add security but creates unnecessary roadblocks.

2. Inconsistent Behavior – Many WordPress functions rely on current_user_can() for capability checks. Contrary to running certain actions via the UI, when running them with WP-CLI, these checks fail unexpectedly, requiring developers to set the current user for the command manually. This adds extra complexity without clear benefits.

3. Enhancing Developer Experience – WP-CLI is meant to streamline administrative tasks. Making current_user_can() always return true would eliminate the need for workarounds, improving the efficiency of developers and system administrators.

Alternative Approaches:

• A new WP_CLI-specific filter (e.g., wp_cli_always_allow_caps) could be introduced to optionally override capability checks when WP-CLI is in use.
• Instead of a global override, current_user_can() could return true only for critical capabilities like assign_terms, edit_posts, and manage_options.
• Setting a privileged user with --user could be used to work around the issue, but it has drawbacks:
  • It requires knowledge of a privileged user on the system where the command is executed, which is not always practical.
  • Developers would need to hardcode user IDs, which introduces fragility, as user IDs can differ between environments (e.g., local vs. staging vs. production), making scripts less portable, or implement logic to retrieve an administrator ID dynamically, adding unnecessary complexity.

I would love to hear your thoughts on whether this change would be beneficial. Are there any edge cases or unintended consequences that should be considered?

Thank you!

[tyrann0us]

CC @swissspidy, as I don't know if maintainers get notified about new discussions. 🙂 ✌🏽

[swissspidy]

Thanks! Yeah we actually not get notified and I can't seem to find a way to subscribe to new topics here... That's probably why we don't really advertise this Discussions feature for the org.

Given that this is a clear feature request it's probably easier to just create an issue for this instead of a discussion topic.

This must have come up before too but I can't find any prior issue for it right now. cc @schlessera maybe you know more?

[tyrann0us]

Thanks for getting back to me!

This must have come up before too but I can't find any prior issue for it right now.

This was exactly my thought, too. Given that this would probably be a rather significant behavior change, I thought that discussing this "freely" outside of a GitHub issue would make more sense and only make it an issue once the maintainers agree. 🙂

I'll await @schlessera's comment and, if positive, will happily make this an issue (although I can't seem to find a button for it; maybe only maintainers have permission for it).