CLI commands do not work within shell started with wezterm start -- <SHELL>

[SilverMira]

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

wezterm 20230501-084619-d0e9a034

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

When starting a one off program using wezterm start -- <program> as described here, wezterm cli commands within this shell fails with failed to connect to Socket("gui-sock-XXXXX").

However, if a pane is split from the problematic shell, cli commands work in the split pane as expected, albeit with an error ( EDIT: It looks like this error happens regardless of this issue, IE: when just using wezterm start) in the logs on the first cli command.

To Reproduce

1. Start a Nushell using wezterm start -- nu or any shell for that matter
2. Within this shell, issue wezterm cli list --format json
3. Notice the failed to connect to Socket error
4. Split a pane from this shell
5. Issue wezterm cli list --format json in the new pane
6. Notice the command is executed successfully

Configuration

Curiously, the bug do not reproduce with wezterm -n start -- nu, yet reproduce with wezterm start -- nu with an empty config such as below

return {}

Expected Behavior

wezterm cli commands should work

Logs

16:42:47.552 ERROR wezterm_mux_server_impl::local > encoding PDU to client: writing pdu data buffer: An existing connection was forcibly closed by the remote host. (os error 10054) (EDIT: It looks like this error happens regardless of this issue, IE: when just using wezterm start)

Anything else?

CLI commands do not work with empty config

CLI commands works with skip config

CLI commands works in a split pane from the problematic shell

[wez]

See https://wezfurlong.org/wezterm/cli/cli/index.html#targeting-the-correct-instance for how the CLI resolves the wezterm instance.

There are certain wezterm specific environment variables that should be set and that are maybe not set in this scenario.
Perhaps nu is manipulating the environment?

Can you share a list of all of the environment variables starting with WEZTERM in that shell?

In a regular posix shell, you'd run env | grep WEZTERM. I don't know the equivalent in nushell.

[SilverMira]

nu wasn't the problem here since I could repro on other shells too
Looking at the env vars of the one-off shell, I found that WEZTERM_UNIX_SOCK is not set, tested on commit 7e2b7ca

One-off shell

Working shell

Something else I found, from an existing Wezterm GUI instance, wezterm start -- <SHELL> is spawning a shell that inherits the WEZTERM_UNIX_SOCK from the existing GUI instance, which can only be the case if the WEZTERM_UNIX_SOCK was not set for the spawned shell. By extension, if wezterm start -- <SHELL> is not used within an existing Wezterm GUI instance (ie: in another terminal emulator), WEZTERM_UNIX_SOCK is empty (not set / not inherited). Though, looks like splitting a pane in the spawned GUI instance sets the WEZTERM_UNIX_SOCK correctly.

incorrect WEZTERM_UNIX_SOCK

[wez]

I've pushed a commit that should be more consistent about setting WEZTERM_UNIX_SOCKET. I don't know if that will totally resolve the issue you're facing, but it should at least clarify something.

It typically takes about an hour before commits are available as nightly builds for all platforms.

Please take a few moments to try out the change and let me know how that works out.

[SilverMira]

Yup that did it, can confirm wezterm start -- <SHELL> now sets the correct WEZTERM_UNIX_SOCKET be it from another terminal emulator, or an existing GUI.

[wez]

Thanks for confirming!

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.