Explanation: That comes up when you try to run an X11 application (like, pre-Wayland) that doesn't have the proper credentials to authenticate to the X11 display server.

X11 was designed to have a display server (the software that slaps the window on a display) that might live on a machine other than the one running the graphical program. Historically, this was intended so that the display server could run on a very limited "thin client" computer.

Since you don't want arbitrary software on other computers on the network to be able to display things on your display server (and see what's on your screen, and see your keystrokes, which having access to your display server would also permit), some mechanism of saying which machines have access to your machismo was required. Originally, this was done by restricting the IP address, but because there are some potential ways to attack this, what was settled on was the display server and the machine running the application instead having a shared secret, a "cookie" (this particular approach was developed at MIT, hence the "MIT magic cookie" that you see). I'd expect that to show up if the application and display server don't have the same cookie.

In practice, today, most people just display their windows on their local machine.

If, in a bash shell (if you're not familiar with bash, it's the piece of software probably running when you open a terminal window), you type echo $DISPLAY, you'll probably see ":0". This means "display 0 on localhost". Something like displayserver.foobar.com:1 would be on display 1 on the X11 display served running on displayserver.foobar.com.

Okay, enough explanation. How to fix it?

I've never seen this happen when switching WiFi networks, and I'm a little surprised that it shows up for you. The "localhost" hostname should map to 127.0.0.1, which should not be affected by you moving WiFi networks. And I wouldn't expect you to be using something other than localhost -- if you do that transport when not necessary, I think that it might even degrade performance, prevent use of the X11 SHM shared memory extension, which uses shared memory to do rapid data movement between the application and the display server).

The main time I have seen this in the past, it was when I was trying to run software as root after I had run su to open a shell run by root on a display that I was running as a non-root user. Usually I could resolve that by running, the command xauth merge ~/.Xauthority as root. This merges the current user's cookies (in ~username/.Xauthority) into root's cookies file (in ~root/.Xauthority). If that's what you're seeing, the same command should also resolve the issue.

If not...well, the software that you are trying to run is reaching an X11 server, or the message would be different. It's either reaching yours or another one, but it lacks the cookie to authenticate itself. I think I'd run echo $DISPLAY in the shell that I'm trying to run that program from, see what it's trying to talk to.

EDIT: Sorry, looked at your message again. The X11 software package that you're trying to run is trying to reach ":0", so it's not a matter of that being mis-set. Is there any chance that you're just coincidentally trying to run the program as another user, probably root, and that the WiFi is in fact not related?