Bauke Conijn

I'm having this issue as well on Linux and very frequently. Removing the account and then re-adding it seems to be functional workaround. However, it would be great if the root-cause could be addressed. The launcher, during startup, not having access to were the login tokens are stored for some reason causes those tokens to become invalid.

For me this is a frequent issue as I use KDE as desktop environment and because of that use keepassxc instead of GNOME keyring, which I have to start and unlock manually, as unlike GNOME keyring, does not start and unlock automatically during desktop log-in.

For details and reproduction steps, see: https://bugs.mojang.com/browse/MCL-21202

The launcher is using the Freedesktop.org secrets service integration, which is a D-bus protocol that allows applications to communicate with password managers. Applications that implement this protocol include gnome-keyring, seahorse, kwallet and keepassxc.

I personally use keepassxc, which required me to install it through the PPA (the snap package does not work due to sandboxing). Enable secret service integration in Tools > Settings.  Create and configure a group where the secrets can be stored. Once that is done, open the launcher and log in as usual. You should see 6 or 7 new keys being added for every account you use to login.

Once you've set this up you can log-in or switch accounts without providing a username or password and without any popups, as long as you have your password manager/keyring unlocked.

So basically the issue isn't so much that the launcher does not remember log in information, because it does as long as the Freedesktop.org secrets service is available, but that when it is not available, there is no feedback to the user that log in information could not be remembered due to this service being unavailable.

This is also an issue in Minecraft 1.16.5 on Linux and in Minecraft 1.17.1 on Linux with a single monitor set-up.

Furthermore, setting the GLFW_AUTO_ICONIFY flag to false does not prevent Minecraft from being minimized either. This is regardless of whether the compositor is enabled or disabled and regardless of whether GLFW is allowed to bypass the compositor.

Using a borderless fullscreen window has the issue that it seems impossible to resize the window such that it overlaps the OS's taskbar. Additionally when switching back to windowed mode, GLFW seems to be unable to restore the window borders.

As a workaround I can ask my window manager (plasma) to make Minecraft fullscreen and this works almost flawlessly. With the exception that pressing F11 to toggle fullscreen mode in-game can cause my computer to hang.

P.S. GLFW is the backend that LWJGL uses to provide OpenGL support.

I ran into this issue on a spigot server with the multiverse-core plugin. When running a summon command for an animal/hostile mob in a world that has animals/hostile mobs disabled, will yield this error message. It's extremely confusing, as it has nothing to do with UUID's, but that's a bug in that plugin, not in vanilla minecraft.