Please choose an approach which works from inside the macOS sandbox. So that we can ship tools to the App Store which can interact with ghostty (as we can with iTerm2).

Yeah, iTerm2 has a couple VT sequences for this: #4391

In iTerm2, I often manually run:

echo -e "\033]1337;SetColors=preset=Grass\a"

(varying the scheme) to make a particular window stand out.

I like this approach because it allows any program (even outside of ghostty) to write escape codes to the tty of a given terminal.

I use this feature with wezterm and aerospace to integrate my terminal and window manager keybinds.

Wezterm has a custom escape sequence to set user vars, which you can use to trigger event handlers in the config. If my window manager detects that wezterm is focused, it uses the wezterm cli to query the active tty and then write escape sequences to it.

That said, I think this works nicely alongside a more robust api/cli rather than instead of as it's a bit of a one way system without hacks.

systemd folks are liking https://varlink.org/ over dbus and I believe I've seen some other projects start to use it too. Not sure if it makes sense here but wanted to give a dbus alternative that I think we will see more of in Linux.

Please keep this on topic about the scripting API only. Session management was previously discussed in #3358, although we had to lock that post because too many people were getting off topic. I don't want to lock this one too.

I agree with the separation of concerns (the three use cases) you defined.

Re: Escape Sequences

For the escape sequence side, I'd like to add that another issue is security. Escape sequences can be sent by lots of sources (including just... cat-ing a file!) and allowing it do arbitrary things to Ghostty's config or windowing is very, very scary. So, let me add that the escape sequence approach for me personally has always stalled on figuring out the security story. That's a blocker.

I say we shelf this for now. It's a lot of design work. People are free to share ideas, but it's not something I'm ready to work on in earnest.

Re: D-bus

100% on board with exposing an IPC API that is Linux-specific with D-bus. This is similar to what we're already doing with Apple Shortcuts. And this is how we already enable ghostty +new-window on Linux.

For security on this side, the IPC mechanism usually handles that for us, which is nice.

I think the downside as you noted is its platform-specific, and D-bus on its own is pretty nasty to script against the API level (probably easier to shell out to gdbus or some other CLI). So this will limit the utility of plugins such as the Neovim native split plugin. Exact same problem with Apple Shortcuts.

API Surface Area (kind of Re: "broad")

We shouldn't boil the ocean. Maintaining an API that can do anything with Ghostty is a design and maintenance nightmare. I think scoping down to specific use cases and introducing the IPC necessary to do that is the way to go, similar to what we did with ghostty +new-window.

So, I'd say, we should aim future discussions at introducing specific, platform-specific IPC capabilities.

Future Cross-platform API

I'd still like to do a future cross-platform API, likely via something like Unix domain sockets (but who knows). But, there's enough of a barrier to entry there that I'd feel more comfortable addressing this via the platform-specific IPC mechanisms for now.

I initially had a whole tirade about security that I cut out for the sake of time, but I think it should be done via both cutting down the exploitable surface (e.g. don't allow apps to send the crash action to the terminal in any circumstance) and also having a much more developed permission model for actions that originated from something that wasn't the result of a user's direct intent (e.g. popping up a dialog asking the user if they truly want to paste rm -rf --no-preserve-root / into their shell). I agree though that the control sequence approach seems like too much of a security nightmare for now — maybe we could revisit it later after implementing tmux control mode first.

For what it's worth I looked at how Kitty did it, and it's simultaneously too over- and underengineered at the same time. It's a bit shocking. I think if we want to do this we want to do this correctly from the outset. (Kitty only introduced granular control permissions after the initial protocol came out IIRC.) Maybe we can experiment with a token-based authentication system where apps can request certain permissions which would be presented to the user, the user could opt out of some or all of them, and then we could return the set of allowed permissions for the app. That seems a bit too involved, though.

On the "API Surface Area"

You mention that we should not create an API which can do anything, due to the load that puts on maintanance and design.
First off, I wholeheartedly agree with this, but it got me thinking, and would an API really need to be that large to give end users the ability to implement "everything"?

A lot of complex functionality can often be compiled from few simpler interfacing points.
I might be mistaken in the effort needed to create such an API, or the scope that API would need to take, so it might also be useful to compose a list of different potential interface actions and the things you can do with sets of them.

e.g.
If we implemented:

• Reading window&pane info (location and size in the ghostty multiplexer, current run command+PID, potentially logged in user, window name)
• Modifying window&pane info (Change location, size, name, active window)
• Creating new window/pane

It feels like this (relatively small) subset of potential interface options would already open up a large amount of scripting potential.

Kitty solves this by using Unix sockets, which, as the name implies, aren't available on Windows

Windows actually supports AF_UNIX sockets, now, though there's not much documentation for it.

Actually I ended up looking into this a bit, and you can do this without AppleScript, by just using the standard OSX window controls and the accessibility stuff that ghostty exposes.

I ended up using hammerspoon https://github.com/dlants/dotfiles/blob/main/hammerspoon/init.lua

This:

• on shift+cmd+t, uses hs to launch a new ghostty terminal which runs this script https://github.com/dlants/dotfiles/blob/main/scripts/ghostty-tab-switcher
• that script pulls all ghostty windows and tabs into a text file using hs, with one line per tab, then feeds it into fzf
• when fzf returns, we invoke https://github.com/dlants/dotfiles/blob/main/hammerspoon/init.lua#L187 to get hammerspoon to select that tab

So now you can have several windows open, one per project, and switch between the various tabs.

I think in macOS it's a bit difficult to set up since you can only set tab titles and not window titles #1026 (comment) so this becomes a lot more useful when you configure the title to always contain the cwd. I ended up spending a lot of time being confused about this, since several places were trying to control the terminal title. I had two zsh plugins trying to control it, and ghostty itself https://github.com/dlants/dotfiles/blob/main/ghostty/config#L20 Once I disabled all of those, my manual title controls worked (and eventually I ended up swapping to fish's default title behavior which includes an abbreviated cwd in the title for both directories and commands).

For folks running into trouble controlling ghostty's title from zsh (like here #4113), look into which plugins you have installed and look into precmd_functions, as it's likely overriding whatever title setting you're trying to do.

Bless you for breaking this down and creating a usable and elegant solution given the constraints between the various tools invoked. Another plus one for hammerspoon and shell scripting to create something useful and repeatable rather quickly.

Thinking more on this, you can also use hammerspoon's built in fuzzy picker to do it all within the hammerspoon context; could also go so far as to create a seal plugin for it to be used with the Seal spoon.

Having something like Kitty's kitten to remote control the active ghostty window would be amazing - especially for editors like kakoune that have no native windowing support and rely on integrations with the hosting terminal or tmux and friends.

on macOS the ghostty command can't open new terminals and doesn't interact with an already open terminal either :(

You can create a new instance with open -na Ghostty.app --args --title=example --working-directory=/path -e zsh or whatever. You currently can't create a new window in the existing Ghostty instance from the ghostty command though.

sadly not cross-platform though - on macOS the ghostty command can't open new terminals and doesn't interact with an already open terminal either :(

Do you know if this is possible with other terminals on macos?

sadly not cross-platform though - on macOS the ghostty command can't open new terminals and doesn't interact with an already open terminal either :(

Do you know if this is possible with other terminals on macos?

Iterm2 with osascript yes

Also Wezterm can do this.

I built ghostty-workspace — a YAML-driven workspace launcher that does exactly this. Define tabs, splits, working directories, and startup commands in a config file, launch with one command. Uses Ghostty's AppleScript API (1.3+), no multiplexer needed.

I took a quick glance at this and there is definitely required feedback.

for example the list surfaces includes the title, this is a security concern as programs are generally not allowed to get the terminal title
https://ghostty.org/docs/config/reference#title-report

You also have the ability to read the entire scrollback and read the current screen. I would never let any program do this there is no reason those are considered in the same category of security as some of the less invasive options, I also think every program should request access to each individual action (it can request access to multiple actions on startup) with some sort of authorization token or something (this is a pretty common mechanism although probably not super secure over plain text)

If at any point something can read/write the contents of your screen remotely there needs to be considerable thought of the security before that is implemented. If the initial implementation supported stuff like new window / new split etc that isn't really dangerous besides something spamming new windows so there is much less concern for security

I understand the AI lovers want something like that but I don't think the scripting API is the correct place to just let anything read your entire terminal something like a session manager / plugins is probably a slightly better place for that. (im pretty sure ghostty already exposes stuff to accessibility API on macos so if AI tools use that they can already read ghostty contents, or at least plans to) in that case the proper security interfaces that API exposes are applied automatically by macos

I also don't see anywhere the security stuff is actually implemented.
I also don't see any need for the screenshot capture that should be handled by external screen capture software

The PR will also be 100% rejected if you don't split it up into core components like just opening and maintaining a socket (using libxev to handle it as its own task is likely the best idea I didn't see how its running besides there is a 100ms poll somewhere, zig 0.16 is also doing a massive rework to how IO works in general so that should also highly be considered). Each IPC handler should also be its own PR (ie list_surfaces is 1 PR, focus_surface is 1 PR etc. That way each individual type is accepted)

Your video shows you use a mac machine if you don't own a linux machine dont touch the GTK runtime at all, many AI submissions do this and never check that it even compiles it shouldn't be on the burden of the maintainers to even review a PR that has compile errors.

I also don't understand why you have the version already at 2 (because of existing dbus stuff etc? that doesn't seem right to me)

+1 — See discussion (and proposed implementation) on this specific feature here: #10603

@oschrenk, glad it helps! sorry i do not have such automated setup, did not go far except open some dir in a split etc kinda stuff.

@oschrenk As you noted, Ghostty doesn't have event hooks like tmux - there's no way to react to tab/split changes natively. ghostty-workspace is strictly a launcher (sets up layout, exits).

For your sketchybar use case, you could map a hotkey to a script that queries Ghostty's current state and diffs it against a saved snapshot. boo already does the state introspection part (boo list dumps the full window/tab/terminal hierarchy). You could use it directly in a shell script, or fork it to add the diff/notification logic natively.

Not as seamless as tmux hooks, but workable until Ghostty adds event callbacks.

Can you map hotkeys within Ghostty to trigger scripts?

I tried mapping a hotkey in Karabiner Elements to boo to trigger actions. This doesn''t work because the permission chain in macOS is breaking. Karabiner fails because it doesn't have permission to send Apple Events :(

Sorry, you are right. Correction to my earlier reply - Ghostty keybinds can't actually launch external scripts. They're limited to sending text/escape sequences to the terminal.

I think the easiest workaround is to bind the key in your shell instead. For example, in bash (alt+s):

bind -x '"\es":"boo list | your-diff-script"'

How do you manage window/tab changes and reacting to them

@oschrenk What is your use case for reacting to new tabs? I assume you have some kind of UI that lists Ghostty windows and tabs? Can you post an image of what this looks like?

This is helpful, I'm working on a multi-agent orchestrator tool for my workflow, I'll use it in my project orca, thanks.

The problem is that there is no scripting environment for Linux that's like AppleScript. The big benefit of AppleScript is that it's supported by the base OS as well as almost every other application that supports scripting. There's really no comparison on Linux.