Working directory in daemon mode

[andresilva]

As I understand --working-directory is ignored when starting a new window in daemon mode (ghostty +new-window). I think it would be very useful to have this feature working even for new windows. As I launch new ghostty windows through my window manager (rather than from within ghostty itself), this makes it so that daemon mode is essentially unusable, since new windows will always default to ~ (or whatever path the systemd unit was started from).

[KorigamiK]

This is a huge pain point for me as well

[m-bartlett]

This also seems to be true for gtk-single-instance = true, makes the single instance mostly unusable

[rhodes-b]

That is the expected behavior

https://ghostty.org/docs/config/reference#working-directory

This setting is secondary to the window-inherit-working-directory setting. If a previous Ghostty terminal exists in the same process, window-inherit-working-directory will take precedence. Otherwise, this setting will be used. Typically, this setting is used only for the first window.

single instance is the same process

[KorigamiK]

That is the expected behavior

https://ghostty.org/docs/config/reference#working-directory

This setting is secondary to the window-inherit-working-directory setting. If a previous Ghostty terminal exists in the same process, window-inherit-working-directory will take precedence. Otherwise, this setting will be used. Typically, this setting is used only for the first window.

single instance is the same process

Calling it expected behaviour is crazy. When the expected behaviour is causing issues and makes the program unusable for everyday application it's not practical to call it expected. This is issue simply needs to address the state issue for he working directory on window initialisation. Not something that cannot be done right?

[00-kat]

That is the expected behavior

But this discussion is a feature request, so it doesn't matter if it's the expected behaviour since the point of the discussion is explicitly to change the expected behaviour.

[abenz1267]

i also just stumbled upon this behaviour and it's super weird. F.e. i dont use any GUI filemanager, just terminal. I have a few things where i want to open ghostty with a specified wd. Doesn't work with +new-window. And without +new-window ghostty is just unbearably slow.

[Syphdias]

I guess after #8862 is done, more arguments might be open to being passed via DBus…

This feature would be nice for opening certain applications in certain directories. I have a shortcut for opening my notes folder with my editor. Currently I just don't use +new-window for that — duh.

[…] since new windows will always default to ~ (or whatever path the systemd unit was started from).

Take a look at the Shell Integration Do you want this?

New terminals start in the working directory of the previously focused terminal.

Or do you want what I described above?

[andresilva]

I am already using shell integration and it works for most of what I do, but in some cases I also want to be able to specify a working directory to +new-window rather than having it be inherited.

[abenz1267]

I guess after #8862 is done, more arguments might be open to being passed via DBus…

this part confuses me, since GTK itself can pass flags between remote instances and service instance just fine. Like.. there's literally nothing that has to be done, other than handling the flags.

I have the "exact" usecase as andresilva: i use my terminal as a filemanager and therefore have a few commands that open a terminal with a certain wd.

[Syphdias]

As I understand this currently +window-new -e something sends a DBus message with something as parameter(s) to the main ghostty process. My thinking was, that this mechanism could also pass other parameters.
This might even be the mechanism you are talking about. Even so for just handling -e "just handling the flags" is exactly what has not been implemented yet.

[jcollie]

Yes, passing other flags is easy enough, mainly it'll just be a matter of redefining the DBus protocol. The hard part is getting the first flag to work.

[jakedane]

It would be great if the directory to open could be passed over DBus. Ptyxis for example supports that.

I had expected to be able to open a directory over DBus with Ghostty 1.2.0 #7433 but it's not implemented:

$ gdbus call --session --dest com.mitchellh.ghostty --object-path /com/mitchellh/ghostty --method org.freedesktop.Application.Open "['file:///home/']" {}
Error: GDBus.Error:org.freedesktop.DBus.Error.NotSupported: Application does not open files

[Ezall2001]

I think the --title flag would also be really helpful to be passed to the main ghostty process.

I currently use ghostty to lunch most of my temporary utility TUI's in Hyprland setup (but it's applicable to more cases):

• emoji selector (with fzf)
• command pallette (with fzf)
• clipse (clipboard manager TUI)
  ...

Each window is launched with a specific title that I can query later with hyprctl to manage the window (move, resize, etc)
The +new-window feature would dramatically decrease the startup time of these frequently opened windows (after the -e flag is implemented). The final missing piece would be the --title flag which would set a persistent title.