Code attached!

Unzip and copy this to your cli directory and change the variables $uid and $gid to something that makes sense in your environment. Run with php -f removeuserfromgroup.php

The result always reports success (because the helper function isn't written to report anything but true) and on 2 different test sites, the user is not removed from the group.

test.zip

Playing around with an extended JUserHelper, I've discovered that $user->save() within removeUserFromGroup returns false.

Per the method documentation, it returns true on success. So JUserHelper is unable to save the JUser object for an as-yet unknown reason.

I also attempted a workaround using JUserHelper::setUserGroups to set a modified group list and that failed as well.

I've attached the extended JUserHelper I used to test. Modifications from the original are marked.
myuserhelper.zip

Something is happening in either the onUserBeforeSave or onUserAfterSave events that's triggering an "Application Instantiation Error". I've disabled all user plugins except the User - Joomla plugin.

Continuing...

One final sanity check, I performed a fresh install, created a single user (ID 539), added that user to group 7 (Administrators) and used the CLI I attached above with the parameters $uid=539 and $gid=7

user 539 was not removed from group 7

For grins, I manually removed the user from group 7 and added them to group 3 (Authors) and performed the same test (after altering the $gid value to 3) and got the same result. User is not removed from the group.

The exception occurs during JPluginHelper::importPlugin('user'); in the save() method.

If you're running from a CLI script and the configuration isn't getting loaded then that would make sense. Make sure the CLI script's bootstrap is similar to https://github.com/joomla/joomla-cms/blob/staging/cli/update_cron.php

The provided CLI scripts are where I got the template for the test.zip I added above.

I've been tracing it back and I've dug down to line 255 of JPluginHelper, where the plugin class is instantiated.

If it's in the plugin's constructor, I'd say the next likely culprit is that the CLI script isn't mapping itself to JFactory::$application so when the constructor tries to initialize a plugin's $app class member var it calls JFactory::getApplication() and since the static container isn't set it's trying to instantiate a class and since an app name wasn't provided it can't instantiate so it fails out with the "Application Instantiation Error" message. A stack trace would probably help confirm that.

That's exactly where I just arrived. JPlugin::__construct, and I just traced it to line 104 - $this->app=JFactory::getApplication();

So, without an app name, the JApplication object isn't loading and causing all of my troubles.

It appears that if I instantiate JFactory::getApplication('cli') before I attempt any user account actions, my errors go away.

My last test confirms, the user is removed from the group.

So, in a JApplicationCli, the app name isn't set automatically? Is that an issue, or did I miss that memo?

JApplication* getInstance methods don't register objects to JFactory, only JFactory::getApplication() will directly assign JFactory::$application. The core CLI scripts really don't need JFactory to be set up to work right so they don't make this assignment, but if you're doing something that needs it, it's something you'll have to take care of (a simple JFactory::$application = $this as the first line in your execute method will suffice).

That strikes me as something that should be in the documentation. It would have saved a lot of effort.

You've been very helpful Mr Babker! I'll close the issue on that note.