If you are the author/maintainer of chatbot/chatbot.php then it’s much easier to skip deactivating the plugin and put something like this at the top of the plugins PHP file:
if ( ! is_user_logged_in() ) {
// remove_action, etc...
return;
}
Similarly using remove_action or remove_filter is much safer. In your case it may be as simple as dequeuing the script/css assets of the plugin if the user is not logged in, or unhooking the function it uses to add them:
if ( ! is_user_logged_in() ) {
// remove_action, etc...
}
This could be placed in a plugin or set up on the init hook in an MU plugin.
When Should I Intercept To Disable Plugins?
You shouldn’t!
In general, conditionally enabling and disabling a theme or plugin like this is an anti-pattern that will cause issues and have unintended consequences that will be difficult to work around that depend enormously on the plugin. Most of all, it’s just not necessary to achieve the goal. It’s highly unlikely your end goal is disabling the plugin, it’s more likely to be a means to an end such as improving performance, not showing things to logged out users etc, which all have superior solutions without unexpected weirdness.
For example, if the code in your question worked, it would break all cron jobs for that plugin, and have other consequences elsewhere. Not all requests have a logged in state even if the user is logged in.
The only time you would do something like this is to force load plugins, either to always load them, or to load them based on server level variables such as wp-config.php constants or environment variables. E.g. force load the CDN plugin in production as it’s required. But never based on user input/sessions/cookies/GET/POST, and to enable not disable things.