failed to connect to Socket("gui-sock-...")

[GrzegorzKozub]

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

[RekiDunois]

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

[smorks]

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?

[krskrs]

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.

[krskrs]

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).

wezterm/wezterm-client/src/discovery.rs

Line 187 in 8e9cf91

pub fn new(path: &Path, class_name: &str) -> anyhow::Result<Self> {

@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 :)

[daf-code]

So, where are the socket files, then?