Nice. I should add notifications to https://github.com/rcarmo/webterm - I already have sparklines as a CPU usage indicator and live thumbnails, but a visual highlight should be easy to add.
I like what you did here and with your direction with the stack. We have some common overlap. Last week I started clauding up something to manage my Claude sessions. It is built on Tauri 2 using xterm.js. It has is project-based and each project has resumable sessions. I borrowed inspiration from Happy coder and clauded an Expo app so I can claude remotely on-the-go. It has been a force multiplier in my clauding with developing new features and addressing bugs and defects. It was a pretty amazing feeling when I started using it to further its own development. There's a slew of other features as I adapt it to my development style.
Mobile interface is definitely nice. Planning on adding iOS app since libghostty works there too! And I imagine that having your main terminal app be synced directly to your phone must be nice, though it doesn't solve the problem of closing my laptop.
Would love to hear what other features have been particularly beneficial to your dev style too. Some directions I'm interested in is having everything be programmable; so my coding agent can set up workspaces for me, click through browsers to test things, etc. And having a main Claude Code manage subagents that have their own easily visible terminal windows.
Wow! That would be incredible! I don't have the agents control the browsers like you are doing. I'm watching to see what you do though because that is incredible. The performance hit is real though -- I may look at libghostty.
I went the similar path of going vertical tabs after having worked that way in iTerm2 for months. Here's what I currently have:
Project-based organization -- Group sessions by working directory with a visual icon strip sidebar.
Multiple session types -- Claude Code sessions, standalone terminal shells, and embedded browser tabs.
Session persistence -- Terminal output is logged and replayed on relaunch so you never lose context.
Session resume -- Claude Code sessions detect their session ID automatically and resume where you left off.
Planning mode -- Draft and refine plans in a built-in text editor, then send them to Claude with one click.
Planning templates -- Start plans from structured templates for bug reports, feature requests, code reviews, refactors, and more.
Auto-titling -- Generic session names are replaced with descriptive titles generated by Claude after the first exchange.
Theming -- Light and dark themes with full CSS variable control.
Native menus and keyboard shortcuts -- macOS-native menu bar with comprehensive shortcut coverage.
Resizable layout -- Adjustable sessions sidebar width with state persistence across restarts.
Dock badge -- macOS dock icon shows the number of actively working Claude sessions.
Pin and archive -- Pin important sessions to the top or archive completed ones to keep the list clean.
Session card view -- See all sessions in a sortable grid with activity stats, token counts, and quick actions.
File tracker -- See which files Claude creates, modifies, and deletes in a live sidebar panel.
Macros -- One-click buttons for frequently used commands like /clear or commit this work.
Remote mode -- Monitor and control sessions from your phone via an encrypted WebSocket relay.
It has become my development hub where I can iterate very quickly.
Just took it for a spin, thought it was pretty nice. Some quirks with the tab dragging, you never really know what it's going to do on mouseup, a drop-target indicator would help.
Ah, I regret training myself into Caps Lock to Escape. Well, a personal problem then. It doesn't seem to have copy-paste support that I have in my Ghostty but I bet that's a config somewhere.
This solves a real pain point. I run multiple AI coding agents in parallel and the biggest UX problem isn't the agents — it's knowing which one needs attention without context-switching into every pane.
The notification-per-pane with blue ring indicator is exactly right. The failure mode of most orchestrators is they abstract away the terminal entirely and then you lose the escape hatch when the agent does something unexpected. Keeping it terminal-native with Ghostty rendering is the correct tradeoff.
Question: how does the in-app browser handle state across agent sessions? If two agents are working on the same local dev server, do they share the browser context or get isolated profiles? That's been one of the harder problems in multi-agent setups — shared browser state leads to agents stepping on each other's cookies/localStorage.
> If two agents are working on the same local dev server, do they share the browser context or get isolated profiles
Currently they share browser context. Adding isolated profiles is a good idea. Do you often use multiple agents in a single project and have them both work on different pages? I personally use multiple checkouts, and the problem for me is that agents working in the same project want to spin up the same dev server. And the dev servers will conflict unless I make different instances of the same project listen in their own port ranges (perhaps via a PORT env var).
We want to solve the latter by bringing better SSH support where the WebView will proxy directly to a remote machine or Docker container, so different workspaces in the vertical tabs can talk to their corresponding dev servers. But I want to hear more about your use case.
Ah! Thanks for explaining that. I totally keep forgetting, to my own detriment, libghostty exists. It’s mighty cool to see it being used more and more to build cool new terminals (like yours and the mobile terminal that showed up here the other day).
Nice. I should add notifications to https://github.com/rcarmo/webterm - I already have sparklines as a CPU usage indicator and live thumbnails, but a visual highlight should be easy to add.
I like what you did here and with your direction with the stack. We have some common overlap. Last week I started clauding up something to manage my Claude sessions. It is built on Tauri 2 using xterm.js. It has is project-based and each project has resumable sessions. I borrowed inspiration from Happy coder and clauded an Expo app so I can claude remotely on-the-go. It has been a force multiplier in my clauding with developing new features and addressing bugs and defects. It was a pretty amazing feeling when I started using it to further its own development. There's a slew of other features as I adapt it to my development style.
Mobile interface is definitely nice. Planning on adding iOS app since libghostty works there too! And I imagine that having your main terminal app be synced directly to your phone must be nice, though it doesn't solve the problem of closing my laptop.
Would love to hear what other features have been particularly beneficial to your dev style too. Some directions I'm interested in is having everything be programmable; so my coding agent can set up workspaces for me, click through browsers to test things, etc. And having a main Claude Code manage subagents that have their own easily visible terminal windows.
Wow! That would be incredible! I don't have the agents control the browsers like you are doing. I'm watching to see what you do though because that is incredible. The performance hit is real though -- I may look at libghostty.
I went the similar path of going vertical tabs after having worked that way in iTerm2 for months. Here's what I currently have:
Project-based organization -- Group sessions by working directory with a visual icon strip sidebar.
Multiple session types -- Claude Code sessions, standalone terminal shells, and embedded browser tabs.
Session persistence -- Terminal output is logged and replayed on relaunch so you never lose context.
Session resume -- Claude Code sessions detect their session ID automatically and resume where you left off.
Planning mode -- Draft and refine plans in a built-in text editor, then send them to Claude with one click.
Planning templates -- Start plans from structured templates for bug reports, feature requests, code reviews, refactors, and more.
Auto-titling -- Generic session names are replaced with descriptive titles generated by Claude after the first exchange.
Theming -- Light and dark themes with full CSS variable control.
Native menus and keyboard shortcuts -- macOS-native menu bar with comprehensive shortcut coverage.
Resizable layout -- Adjustable sessions sidebar width with state persistence across restarts.
Dock badge -- macOS dock icon shows the number of actively working Claude sessions.
Pin and archive -- Pin important sessions to the top or archive completed ones to keep the list clean.
Session card view -- See all sessions in a sortable grid with activity stats, token counts, and quick actions.
File tracker -- See which files Claude creates, modifies, and deletes in a live sidebar panel.
Macros -- One-click buttons for frequently used commands like /clear or commit this work.
Remote mode -- Monitor and control sessions from your phone via an encrypted WebSocket relay.
It has become my development hub where I can iterate very quickly.
With this one, small tweak it is perfect:
osascript << 'EOF' use framework "Foundation" use framework "AppKit"
set ghosttyIconPath to "/Applications/Ghostty.app/Contents/Resources/Ghostty.icns" set cmuxAppPath to "/Applications/cmux.app"
-- Read the icon file set iconImage to current application's NSImage's alloc()'s initWithContentsOfFile:ghosttyIconPath
-- Set it as the custom icon for cmux.app current application's NSWorkspace's sharedWorkspace()'s setIcon:iconImage forFile:cmuxAppPath options:0 EOF
((The ghost pairs well with Kiro, what can I say?))
:ghost:
Just took it for a spin, thought it was pretty nice. Some quirks with the tab dragging, you never really know what it's going to do on mouseup, a drop-target indicator would help.
Would love to be able to color the sidebar tab.
Nice work!
Thanks! Will add drop target and sidebar coloring.
Awesome work, keen to try it out tomorrow. Can I make the notifications work with Gemini CLI and Kiro CLI too?
Thanks! Yup, notifications can be triggered via cli:
And afaik, both Gemini/Kiro should have stop hooks. If they send OSC notifications, then notifications will "just work" as well.Docs: https://www.cmux.dev/docs/notifications
This is pretty slick, man. The only thing is that the Ctrl-Cmd-] is too hard to press but I'll just use the number thing.
Thank! I personally have caps lock mapped ctrl... but open to suggestions! Since it's hard to handle both horizontal and vertical tabs.
Ah, I regret training myself into Caps Lock to Escape. Well, a personal problem then. It doesn't seem to have copy-paste support that I have in my Ghostty but I bet that's a config somewhere.
Get the best of both worlds by having it be Ctrl when held down + pressed with another key and Esc when you press and release it by itself.
> copy-paste support that I have in my Ghostty
Want to fix this, how do I reproduce? Select with mouse and cmd+c seems to work for me.
Oh thank you. Perhaps it's something in my Ghostty. Here's a gist to work with:
https://gist.github.com/roshan/b2a073e2377f370ce83cf7c4ea6d8...
I'm on MacOS 15.7.4 on an M4 Max Macbook
Thanks for repro, taking a look!
This solves a real pain point. I run multiple AI coding agents in parallel and the biggest UX problem isn't the agents — it's knowing which one needs attention without context-switching into every pane.
The notification-per-pane with blue ring indicator is exactly right. The failure mode of most orchestrators is they abstract away the terminal entirely and then you lose the escape hatch when the agent does something unexpected. Keeping it terminal-native with Ghostty rendering is the correct tradeoff.
Question: how does the in-app browser handle state across agent sessions? If two agents are working on the same local dev server, do they share the browser context or get isolated profiles? That's been one of the harder problems in multi-agent setups — shared browser state leads to agents stepping on each other's cookies/localStorage.
> If two agents are working on the same local dev server, do they share the browser context or get isolated profiles
Currently they share browser context. Adding isolated profiles is a good idea. Do you often use multiple agents in a single project and have them both work on different pages? I personally use multiple checkouts, and the problem for me is that agents working in the same project want to spin up the same dev server. And the dev servers will conflict unless I make different instances of the same project listen in their own port ranges (perhaps via a PORT env var).
We want to solve the latter by bringing better SSH support where the WebView will proxy directly to a remote machine or Docker container, so different workspaces in the vertical tabs can talk to their corresponding dev servers. But I want to hear more about your use case.
18 (!) releases in two days. This is some really fast coding.
Lots of stuff to iron out pre-launch!
Good idea, but I don't want to move to another terminal now, will stick with Ghossty
Fair enough! I like Ghostty a lot too, and the only reason I built this was because I wanted vertical tabs and nicer notifications.
This looks cool. I honestly haven’t ever thought about using vertical tabs in a terminal window but that seems nice.
One question though, have you thought about trying to upstream any of this into Ghostty instead of making an entirely different app?
Upstreaming into Ghostty would be very difficult as it's not actually a fork, I just used libghostty under the hood.
Ah! Thanks for explaining that. I totally keep forgetting, to my own detriment, libghostty exists. It’s mighty cool to see it being used more and more to build cool new terminals (like yours and the mobile terminal that showed up here the other day).
VSCode has vertical tabs for it's terminals like this, but on the right side.