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

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

[SpriteOvO]

The issue here seems to be that in single-instance mode, the window-inherit-working-directory option cannot express "always inherit the working directory of the launching process". It can only inherit the working directory of the previous focused Ghostty, unless there was no previous focused instance.

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

[SpriteOvO]

This causes Dolphin's Open Terminal Here shortcut or context menu button to break. If an existing Ghostty is already running and gtk-single-instance = true, Dolphin will always open a new Ghostty window with $HOME as working directory, instead of the current Dolphin directory. Because Dolphin only launches the terminal without any parameters (It can't select parameters for different terminals, I guess), plus the working-directory = inherit in Ghostty's configuration isn't respected due to gtk-single-instance = true.

However, the Open Ghostty Here context menu button works, because it is specialized for Ghostty, which explicitly passes --working-directory=<current-dolphin-directory> --gtk-single-instance=false. But this button cannot be assigned a keyboard shortcut.

[marek-saji]

Ghostty currently ships with .desktop file that specifies:

Exec=/usr/bin/ghostty --gtk-single-instance=true
(…)
X-TerminalArgDir=--working-directory=

Which does not work. If you add com.mitchellh.ghostty.desktop to ~/.config/xdg-terminals.list, then running xdg-terminal-exec --dir=DIR will work as expected only if there’s no ghostty instance already running.

Unfortunately we can’t specify multiple params in X-TerminalArgDir, so adding --gtk-single-instance=false only there will not work, xdg-terminal-exec, would try to execute:

ghostty "--gtk-single-instance=false --working-directory=DIR"

Maybe --gtk-single-instance=true should be dropped from that .desktop file until a better solution is found? Or introduce a wrapper script that adds --gtk-single-instance=false if --working-directory is passed.

[pluiedev]

Hey y'all, apologies for the delay. Many of us on the team have been busy over the last two months due to personal or professional reasons (it has been holiday season for quite a while), but this has now been accepted as #10716.

I'd like to remind everyone that issues are strictly for tracking progress and NOT for discussing additions — if you have some other need unrelated to --working-directory, please create a separate discussion and elaborate your needs there.

As a personal anecdote, I was partially pressured by one of my friends into fixing this, so peer pressure might be the right solution sometimes ;)

[ryanheise]

since new windows will always default to ~

That's actually what I expect a new terminal window to do, even when the terminals are using shared memory under a single instance. I would prefer single instance mode to behave this way unless explicitly overridden with an option.

[rhodes-b]

https://ghostty.org/docs/config/reference#window-inherit-working-directory the option does exist, the default is that its true though you can easily configure your ghostty to make that false

[jcollie]

Try:

working-directory = home
window-inherit-working-directory = false

Tabs and splits will inherit the current directory but a new window will always start in your home directory.

[ryanheise]

Try:

working-directory = home
window-inherit-working-directory = false

That's what I have.

[jcollie]

So are you saying that it doesn't work, or that you think that it should be the default?

[ryanheise]

I'm not saying that it doesn't work. I was just saying that "since new windows will always default to ~" is what I would expect to happen by default (and I was surprised by the change in default).