YES that worked for me, thank you

On macOS Sonoma, I had this annoying error. GOG Galaxy starts up fine, but after a little while: "GOG Galaxy - Error / Connection blablabla / Galaxy will now shutdown" (modal window)

Running /Users/Shared/GOG.com/Galaxy/redists/GalaxyCommunication in a terminal beforehand will help, but that's a bad way to solve the problem. Seems just sloppy programming.

LoL same situation, remote desktop and this error occurs, not yet a work around?

P.D I've to open parsec and then Remote Desktop, so I confirm, it's something with remote desktop

above didn't work for me
this did https://www.gog.com/forum/general_beta_gog_galaxy_2.0/connection_to_communication_service_was_lost_and_could_not_be_restored_gog_galaxy_will_now_shutdown_/post101

Thank you! That helped.

Additional detail.
Start in terminal first and see if it the process is not quitting.

1st time I run, it worked about 30 seconds and shutdown.
2nd time it shutdown in 5 second.
3rd time - started the GalaxyCommunication and right after (till GalaxyCommunication is up and running) it launched the GOG Galaxy.

I spent a lot of time trying to bypass the problem.

macOS Ventura 13.6.7
Apple M1

I tested @bmeerdink's suggestion on my system, and was successful in getting GOG Galaxy to run.

Here's what I found:
The 'GalaxyCommunication' program will exit after about 30 seconds when nothing is connected to it, but will run indefinitely while a connection is established.
The 'GOG Galaxy' program takes several seconds to start up before attempting to connect to 'GalaxyCommunication'. The amount of time varies, but on my system it's somewhere around 10 seconds.

Taking the above information into account (with some trial and error) I wrote a bash script to launch and synchronize the two programs:
$ cat /Applications/gogGalaxyLauncher.app/Contents/MacOS/gog_galaxy_launcher.sh
---
#!/bin/bash

open /Applications/GOG\ Galaxy.app &
sleep 10
/Users/Shared/GOG.com/Galaxy/redists/GalaxyCommunication &

---
You may need to adjust the 'sleep 10' amount (I use 10 seconds) if GOG Galaxy is slower to start on your system.

I made the script executable (current user only) using the 'chmod' command in a terminal:
$ chmod u+x /Applications/gogGalaxyLauncher.app/Contents/MacOS/gog_galaxy_launcher.sh

And packaged it as a macOS app:
$ tree /Applications/gogGalaxyLauncher.app
---
/Applications/gogGalaxyLauncher.app
└── Contents
.......├── MacOS
.......|.......└── gog_galaxy_launcher.sh
.......├── Resources
.......│......└── AppIcon.icns
.......└── info.plist

4 directories, 3 files
---

Here is the info.plist file I used:
$ cat /Applications/gogGalaxyLauncher.app/Contents/info.plist
---
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN">
<plist version="1.0">
<dict>
<key>CFBundleExecutable</key>
<string>gog_galaxy_launcher.sh</string>
<key>CFBundleIconFile</key>
<string>AppIcon.icns</string>
</dict>
</plist>
---

For more information on creating macOS apps from shell scripts, you can search stackoverflow with this search term (keep the quotes): "Converting a Shell Script Into a .app File"

You can also run the script by itself if you don't want to construct an entire macOS app, or even just run the commands in a terminal like so:
---
open /Applications/GOG\ Galaxy.app &
sleep 10
/Users/Shared/GOG.com/Galaxy/redists/GalaxyCommunication &
---

When GOG Galaxy is closed, it will terminate its connection to GalaxyCommunication, and about 30 seconds later GalaxyCommunication will exit, so nothing gets left running in the background unnecessarily.

Thanks @bmeerdink for identifying what GOG Galaxy was failing to establish a connection to, your solution works well for me.

Also, when I open the app as installed, the GalaxyCommunication program never runs at all, and I don't see anything in the GOG Galaxy logs indicating that an attempt has been made to open it ¯\_(ツ)_/¯

Note: I don't know if it's possible to format posts in this forum as code blocks or even just monospaced, so some of the formatting is a bit wonky, be cautious if you attempt to replicate what I've done, if you don't understand something do some searches until you find an explanation that makes sense to you. Thanks!

One other thing, for completeness: I have the "GOG Galaxy.app" and "GOG Sp. z o.o." entries enabled in my system settings (Settings -> General -> Login Items -> Allow in the Background). [update: I have since disabled these and the app still seems to run ok] [further update: 'GOG Sp. z o.o.' seems to be required, I have re-enabled it]

Thank you!

But just ... WHY?
I have no respect for this excuse for a client. Of all the available game clients I know this in is the worst in my opinion.

Thanks as well.

Just wanted to add, login through Parsec also gets around this issue if for some reason you can't physically log in.

They still didn't fix this?
I don't understand why the app simply refuses to work if you are using remote desktop.
No other launcher has this issue.

I have most of my games running in a VM and I just remote in from a thin client at home. Sure, at home I can work around it by using Steam remote share (the correct name for it escapes my mind at the moment).

But when I am at the night shift at work, I am allowed to play if no work comes up, so I use my own VPN to connect to my server at home and RDP to the VM (my laptop itself is not strong enough to play games).


Sure, it's a special case and certainly no issue the majority of users have, but I still find it irritating that only GOG Galaxy has this issue with RDP.
I mean, even the really bad launcher of EA and Ubisoft don't have issues with RDP.

This has been a constant issue on mac. Nothing fixes it. Completely inexcusable. I'm sorry I ever spent money on GOG.

Back to steam I go.

I had a loot of problems with connection on Windows 10.
After every update there was a connection problem and after some time it started to work by itself, until the next update.

I have solved my problems by removing virtual network interfaces, so maybe there is something with application trying to connect via wrong network interfaces.

It won't fix the problem with running it on VMs but removing or stopping all unnecessary interfaces (Hyper-V, VirtualBox, etc.) should help.