wez
failed to connect to Socket("gui-sock-...")
What Operating System(s) are you seeing this problem on?
Windows
Which Wayland compositor or X11 Window manager(s) are you using?
No response
WezTerm version
20231004-113117-11dec45f
Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?
Yes, and I updated the version box above to show the version of the nightly that I tried
Describe the bug
I would like to be able to control a running GUI instance with the default local domain from wezterm cli on Windows. I first launch wezterm-gui.exe. This creates a GUI window for me as expected. Then I execute wezterm cli list for examplefrom apwsh.exeorcmd.exe` instance running outside of WezTerm. This, after some 5 seconds, gives me an error:
ERROR wezterm > failed to connect to Socket("gui-sock-14616"): connecting to gui-sock-14616; terminating
Providing --class param for the original GUI launch and the wezterm cli call does not help. I feel like the GUI instance has been found though.
Interestingly, when I call wezterm cli list from the shell running inside WezTerm, the result is as expected.
Used the release build and nightly build.
What am I missing here?
To Reproduce
No response
Configuration
no config
Expected Behavior
As described in Targeting the correct instance, a running GUI instance is found and used for any of the wezterm cli commands.
Logs
No response
Anything else?
No response
same issue here in mac os, run wezterm cli spawn return as below:
23:04:55.593 ERROR wezterm > failed to connect to Socket("/Users/rekidunois/.local/share/wezterm/gui-sock-10494"): connecting to /Users/rekidunois/.local/share/wezterm/gui-sock-10494; terminating
i was able to get wezterm cli list to work in a separate terminal window in Windows by checking what the WEZTERM_UNIX_SOCKET env var is set to in the wezterm terminal, then manually setting the env var that in the other terminal window, then wezterm cli list outputs correctly.
so i'm wondering if this isn't actually a bug, but expected behavior when that environment var isn't set.
there's some further discussion here: #1208, that is specific to Mac but seems relevant to this as well.
edit: it is strange, however, that it does reference the correct filename of the socket in the error. if i have some time i might dive into the code to see if i can figure out what's causing this.
edit2: running wezterm cli list from the directory where the gui-sock-* file exists appears to work as expected too. so for some reason it looks like it's not looking in the correct directory?
I'm new to wizterm, but I haven't been able to understand if this is someway the correct behavior, or some misunderstanding on how it should work.
But after all, it seems rather strange that if you launch a wizterm instance, and in another Powershell (I'm on Windows) you issue wezterm cli list, the returned error is: 02:05:47.573 ERROR wezterm > failed to connect to Socket("gui-sock-21260"): connecting to gui-sock-21260; terminating where gui-sock-21260 actually is the socket name of the other instance.
So, the new instance being launched is able to identify the correct socket name of the already running instance, but, the same time, is not able to open it? uhm..
This is issue is has been opened in October, 2023. @wez could you please take a moment to shed some light on this? It would be much appreciated and it shouldn't take too long, as this is just a thing regarding the base core behavior. Is it normal? And as I said, what looks weird if that the new instance shows the existing socket identifier, but refuses to open it.
Update: ok, I went ahead :) and briefly tried to analyze the code. Here what I found, although please consider that this is the first time I have been looking at WezTerm source code, so I can't guarantee I'm 100% correct on this.
Anyways, the issue seems to be related to how the gui socket path is published (on Windows), where only the socket file name is published (the path is lost). This also explains the various behaviors described in this issue (for example the fact that it works in the directory where the socket files are located).
https://github.com/wez/wezterm/blob/8e9cf912e66f704f300fac6107206a75036de1e7/wezterm-client/src/discovery.rs#L187
@wez hope it helps. @smorks don't know if you went ahead and checked the source code as well, anyway, in case you are still interested, I'm tagging you :)
Hi @wez I've seen that lately you have been very active on the repo, and we're all very glad about that! I'd like to bring this issue to your attention because I believe it's a big one on Windows, but at the same time, I believe that it could be very quick to address. Unfortunately I can't provide a PR, because I don't have a Rust dev environment available, and I haven't enough confidence with the Wezterm codebase, however I took several hours trying to pinpoint the issue in the source code, and if you could check that my analysis is correct maybe you could fix that bug very quickly and with little effort. Thank you!
Certain environment variables are created inside each instance of WezTerm (to view these variables enter the command get-childitem env: inside wezterm and look for the variables beginning with WEZTERM_).
One of these environment variables is WEZTERM_UNIX_SOCKET, which is unique to each instance of WezTerm open on your machine.
To be able to use wezterm cli inside another environment, such as a PowerShell script or another terminal, the WEZTERM_UNIX_SOCKET environment variable in that environment must be equal to the one inside the WezTerm instance you want to control.
The WEZTERM_UNIX_SOCKET environment variable must be in the form "$HOME/.local/share/wezterm/gui-sock-<pid>", where <pid> is the process ID for that instance of WezTerm.
You can view all open instances of WezTerm and their process IDs using the command get-process wezterm-gui.
To take the original issue as an example, where you have an instance of WezTerm open and want to control it from another terminal, simply enter the following command:
$env:WEZTERM_UNIX_SOCKET = "$HOME/.local/share/wezterm/gui-sock-$((Get-Process wezterm-gui).Id)"
This command sets the WEZTERM_UNIX_SOCKET environment variable, allowing you to use commands such as wezterm cli list.
Hi, I got the same problem in linux, where from wezterm itself wezterm cli list just works, but from konsole (where wezterm was launched) throws the socket error.
12:56:26.720 ERROR wezterm > failed to connect to Socket("/run/user/1000/wezterm/gui-sock-15034"): connecting to /run/user/1000/wezterm/gui-sock-15034; terminating
But if I set, currently empty at this point, socket variable, it works:
export WEZTERM_UNIX_SOCKET=/run/user/1000/wezterm/gui-sock-16372
In my scenario, I got two sockets to choose from, using any of the two seems to work and return correct wezterm info, I only got one of wezterm instance with one tab open.
I fix my problem just setting the environment variable like @ostromia suggested, I throw this here, because maybe is not just a windows problem.
Im running on:
- wayland
- manjaro linux + plasma up to date at the time of writing (2025-07-12)
- wezterm 20240203-110809-5046fc22
If anyone needs more information, ping me!
It seems that wezterm already get the correct socket-name but forgets the prefix:
╰─ wezterm cli list ─╯
10:43:39.965 ERROR wezterm > failed to connect to Socket("gui-sock-620"): connecting to gui-sock-620; terminating
wheras the full name is
WEZTERM_UNIX_SOCKET=C:\Users\username\.local/share/wezterm\gui-sock-620
