Because capabilities and roles persist, some one time code to set this up could be run. Or install one of several role and capability management plugins and use their UI to do the same. You can deactivate the plugin when you are finished.

But then NO ONE will be able to add more plugins unless you have some custom role somewhere. Add the capability to your or someones WP_User object.

But that’s exactly what I’m looking for – a way to outright block *anyone* from adding new plug-ins while still allowing plug-ins to be updated. When a new plug-in is needed, we can comment out the blocking mechanism and add the plug-in ourselves. This is for site’s we are contracted to host, manage, maintain, update and Webmaster. There are clients who will want/need admin privileges for other reasons, and we don’t want them adding plug-ins unless we’ve vetted them first to ensure they’re being actively supported and won’t conflict with other plug-ins we’ve installed into the sites (almost all of them are sites we’ve built). A role editor plug-in seemed like more overhead than necessary and more trouble to configure than just dropping a couple lines of code into our themes.

So if NO ONE can add a plug-in, and we can manually turn this on and off by editing the theme functions file directly (or a child theme functions.php page for the occasional site where we use something off-the-shelf), that’s golden! Thanks for pointing me in the right direction ??

You could (and should) comment out the code as soon as it is run once and the change will persist. This is why you needn’t worry about a role management plugin overhead. Once you’ve set what you want, you can deactivate it. AFAIK there are no configuration or setup procedures for such plugins. Naturally there’s a small learning curve, like less than 5 minutes of poking around. The advantage of such a plugin is sometimes you need to try different capabilities until you get the correct behavior, they are not always as intuitive as they seem. The plugin UI makes this easy. But if you know for sure what you need, custom code is just as effective. I’m pretty sure we’ve got this one right ??

I learned something new here – thank you! I thought this was a check done with each page load. It makes sense that it would be build into the database, now that you mention it. But I thought altering permissions was handled in real-time against the default user role capabilities, and not a stored variable. This is very good to know.