Ghostty and WezTerm as IDEs: Leaving VS Code's Integrated Terminal Behind

Ask a developer what their “IDE” is, and you’ll get two kinds of answer. The first is a product name: VS Code, IntelliJ, Cursor, Zed, Neovim with an IDE layer bolted on. The second is a workflow: “my editor plus a terminal plus a bunch of splits.” For a growing number of developers in 2026, the answer is drifting toward the second form — and the terminal emulator has become the host application, not a pane inside the editor.

This shift didn’t happen because VS Code got worse. It happened because terminals got much better. Ghostty shipped at the end of 2024 with native macOS and Linux builds, GPU-accelerated rendering, sub-millisecond input latency, and the Kitty graphics protocol. WezTerm has spent years accumulating features quietly and now has scripting in Lua, per-pane search, and image protocol support across platforms. Combine either of these with a modern TUI editor (Helix or Neovim) and a multiplexer (Zellij or tmux), and you have something that functions like an IDE without the weight.

This post walks through what that setup actually looks like, where it shines, and what it can’t do compared to a graphical IDE. If you’ve been terminal-curious but worried about giving up the “I can see my project structure on the left” experience, this is the honest account.

What it means to use a terminal as an IDE

The canonical IDE layout has a sidebar (file tree), a central editor pane, a bottom terminal panel, a status bar, and a tab strip. A tiled terminal workflow builds the same thing from composable pieces:

• Terminal tabs replace the VS Code window tabs.
• Split panes replace the editor / terminal / sidebar division.
• Multiplexer sessions replace “workspaces” — one session per project, detachable and reattachable.
• Editor panes (Helix, Neovim) handle code editing, with tree-sitter for syntax highlighting and LSP for intelligence.
• A file tree exists either inside the editor (Neovim’s nvim-tree, Helix’s file picker, yazi as a dedicated file manager) or is skipped entirely in favor of fuzzy-finder-based navigation (Telescope, Helix’s built-in picker, fzf).
• Debugging happens through LSP-based debug adapters (DAP in Neovim, limited in Helix) or by running the debugger directly in a pane.
• Version control happens through lazygit, gitui, or Neovim’s fugitive.

The key realization: once you have split panes, fast navigation between them, and a shared session model, “IDE” stops being a monolithic application and starts being a workflow. The terminal emulator becomes the window, not the widget.

Why Ghostty matters

Ghostty was released as open source in December 2024, after about two years of internal development by Mitchell Hashimoto (the HashiCorp co-founder) and a small team. It took the terminal emulator world seriously: native per-platform UI (AppKit on macOS, GTK on Linux), GPU-accelerated rendering via Metal and OpenGL, and a from-scratch codebase in Zig.

What makes Ghostty IDE-viable:

• Tabs and splits out of the box. Native, with keyboard shortcuts to create, navigate, and resize. You don’t need tmux for basic split panes (though you’ll still want a multiplexer for persistence).
• Kitty graphics protocol. Images, plots, and image-based previews work inside the terminal. Tools like yazi show image previews; matplotlib can be configured to render inline; kitten icat displays images directly.
• Very low input latency. Ghostty reports median keystroke-to-render under 2ms on modern hardware, which is close to the theoretical floor.
• Rock-solid shell integration. Prompt marks, per-command timing, clickable file paths, URL detection — all work with the standard ghostty +show-config --default setup plus a small shell hook.
• Config that’s actually readable. One flat config file with key = value lines. No Lua. No theme framework DSLs. Just keys, values, and comments.
• Quick-terminal mode. Press a global hotkey to drop a terminal overlay on any workspace — the closest thing to an IDE’s integrated terminal, from any application.

Example Ghostty config for an IDE-like setup:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

# General
font-family = "JetBrainsMono Nerd Font"
font-size = 14
theme = tokyonight_night
background-opacity = 0.95
window-padding-x = 8
window-padding-y = 8
window-decoration = true

# Tabs and splits
window-save-state = always
keybind = cmd+t=new_tab
keybind = cmd+w=close_surface
keybind = cmd+d=new_split:right
keybind = cmd+shift+d=new_split:down
keybind = cmd+h=goto_split:left
keybind = cmd+l=goto_split:right
keybind = cmd+j=goto_split:bottom
keybind = cmd+k=goto_split:top

# Shell integration + clickable links
shell-integration = detect
shell-integration-features = cursor,sudo,title

# Quick terminal (global overlay)
keybind = global:ctrl+grave_accent=toggle_quick_terminal

That’s a functioning IDE shell: tabs for long-running projects, splits for editor + terminal + logs, a global hotkey for quick command-running, and clickable file paths so error messages jump straight to the editor.

Why WezTerm matters

WezTerm has been around longer than Ghostty (since 2019) and has a different personality. It’s written in Rust, cross-platform from day one (macOS, Linux, Windows, FreeBSD), and configured in Lua. That last part is a feature or a footgun depending on who you ask.

Where WezTerm wins:

• Truly cross-platform, including Windows. If you switch between platforms, WezTerm behaves identically. Ghostty on Windows doesn’t exist (yet); WezTerm on Windows works beautifully, including with WSL2 integration.
• Lua configuration is powerful. You can script anything — dynamic tab titles based on cwd, per-host config switching, generated keybindings. For power users, this beats a static config file. For casual users, it’s more than they need.
• Multiple image protocols. Sixel (for older tools), iTerm2’s protocol, and Kitty graphics — all work. Maximum compatibility with terminal image tools.
• Built-in multiplexer. WezTerm can do what tmux does (detachable sessions, multiplexing) natively, including remote multiplexing over SSH. You don’t need a separate tmux or Zellij install if you commit to WezTerm’s model.
• Scrollback and search. Extensive scrollback with regex search, pattern-based navigation, per-pane search.

A WezTerm config, showing the Lua approach:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

local wezterm = require 'wezterm'
local config = wezterm.config_builder()

config.font = wezterm.font('JetBrainsMono Nerd Font')
config.font_size = 14
config.color_scheme = 'Tokyo Night'
config.window_background_opacity = 0.95
config.window_decorations = "RESIZE"
config.hide_tab_bar_if_only_one_tab = true

config.keys = {
  { key = 'd', mods = 'CMD', action = wezterm.action.SplitHorizontal { domain = 'CurrentPaneDomain' } },
  { key = 'D', mods = 'CMD|SHIFT', action = wezterm.action.SplitVertical { domain = 'CurrentPaneDomain' } },
  { key = 'h', mods = 'CMD', action = wezterm.action.ActivatePaneDirection 'Left' },
  { key = 'l', mods = 'CMD', action = wezterm.action.ActivatePaneDirection 'Right' },
  { key = 'j', mods = 'CMD', action = wezterm.action.ActivatePaneDirection 'Down' },
  { key = 'k', mods = 'CMD', action = wezterm.action.ActivatePaneDirection 'Up' },
}

-- Dynamic tab title showing current dir
wezterm.on('format-tab-title', function(tab)
  local cwd = tab.active_pane.current_working_dir
  local basename = cwd and cwd.path:match("([^/]+)/?$") or "~"
  return string.format(" %s ", basename)
end)

return config

The Lua gives you hooks: format-tab-title there is one of dozens of events you can subscribe to. Sophisticated users build complete session managers this way. The tradeoff is that simple things (change a color) take more syntax than Ghostty’s one-liner.

The multiplexer question

Both Ghostty and WezTerm have built-in splits and tabs. Do you still need tmux or Zellij?

Answer: yes, if you want session persistence — the ability to detach from a session (close the terminal, SSH out, reboot) and reattach with everything exactly where you left it. Neither terminal’s built-in splits survive a terminal process exit by default. WezTerm has some multiplexing support here but it’s less battle-tested than tmux.

Practical advice:

• Local-only workflow, no SSH: the terminal’s native splits are enough. Skip tmux.
• SSH-heavy workflow: use tmux or Zellij on the remote boxes. You’ll want the session persistence on the server side regardless of your local terminal.
• Switch machines frequently: Zellij or tmux everywhere gives you a uniform experience. You can have a tmux session on your laptop that behaves identically to a tmux session on a remote box.

The modern combined setup:

• Terminal: Ghostty or WezTerm, with native tabs for top-level project separation.
• Multiplexer: Zellij (or tmux) inside each tab, for splits and session persistence.
• Editor: Helix or Neovim inside one of the multiplexer panes.

This is three layers deep — which sounds heavy but each layer has a clear job. Tabs for projects, multiplexer panes for project-internal layout, editor inside the main pane for code.

File tree or not

The biggest “how do I do this without a GUI” concern for IDE refugees is the file tree. VS Code’s left sidebar showing your project structure is genuinely useful. The terminal-native answers are:

Option 1: Fuzzy finders, no tree. Use fzf, Telescope (Neovim), Helix’s built-in picker, or zoxide for directory jumping. Instead of “click through the folder structure,” you type two or three letters and open the file. This is faster for most navigation — and once you internalize it, going back to a file tree feels slow.

Option 2: Yazi or nnn alongside the editor. Yazi (Rust, image previews via Kitty protocol, plugin system) and nnn (C, extremely fast, minimalist) are terminal file managers. Run one in a side split. Navigate with hjkl, open files by pressing Enter, and they show up in your editor pane via a shell hook.

Option 3: Editor-integrated tree. Neovim has nvim-tree.lua and neo-tree.nvim. Helix doesn’t (yet) but the file picker covers most cases.

The honest take: most experienced terminal-IDE users drift toward Option 1 (fuzzy find for files, no tree) plus occasional yazi for exploration. The file tree is comforting but not actually necessary once your fingers know :find or ff as reflexes.

LSP and IDE intelligence

The IDE experience isn’t just layout — it’s also jump-to-definition, find-references, autocomplete, inline diagnostics, formatting, and refactoring. In 2026, all of these are available in the terminal through Language Server Protocol.

Both Helix and Neovim support LSP natively (Helix out of the box, Neovim via nvim-lspconfig). Point them at a language server binary (rust-analyzer, gopls, pyright, tsserver, clangd), and you get:

• Completion as you type (via nvim-cmp or Helix’s built-in)
• Inline diagnostics — errors and warnings shown on the line
• Hover — documentation on a symbol under cursor
• Go-to-definition / go-to-implementation / find-references
• Rename symbol across the project
• Code actions (quick fixes, imports, extract function)
• Formatting on save

This is not a degraded IDE experience. It’s the same LSP running underneath VS Code, IntelliJ’s language plugins, and Zed. The UI is different — diagnostic popups, not a squiggly line plus a hover tooltip — but the intelligence is identical.

Debugging is where the terminal stack is weakest. Neovim has DAP (Debug Adapter Protocol) support via nvim-dap, which works for breakpoints, step-through, and variable inspection. Helix does not yet have DAP. For heavy debugging workflows, you’ll still sometimes drop into VS Code or a platform-specific debugger. For most bug-hunting — tests, print debugging, targeted log inspection — the terminal is enough.

What the terminal IDE still can’t do

Honest accounting of what you give up versus VS Code or JetBrains:

• Integrated debugger UI (in most configs). VS Code’s debugger is genuinely excellent. Neovim with DAP gets you 80% there; Helix doesn’t at all yet.
• Visual diff tools. git diff in the terminal is fine, but lazygit / gitui / Neovim’s diffview plus mergetool are as good as VS Code’s diff view in most cases. But a three-way merge conflict UI in VS Code is still superior.
• Remote development via GUI. VS Code’s remote containers and SSH dev modes are very polished. The terminal equivalent is… SSH plus tmux, which is fine but not as seamless for some workflows (especially Docker devcontainers).
• Extensions and marketplace. VS Code has 50,000 extensions. Neovim has a rich plugin ecosystem but it’s smaller; Helix has no plugin system yet.
• AI pair programming. Copilot in VS Code is tightly integrated. The terminal equivalents — Aider running in a split, or Copilot CLI, or Claude Code — are getting very good but feel less integrated.
• Collaborative editing. VS Code Live Share has no terminal-native equivalent yet.

If any of these are core to your workflow, the terminal IDE is a compromise. If none of them are, you won’t miss them.

The productivity claim, examined

Does using the terminal as an IDE actually make you more productive? Here’s what’s true and what’s dogma:

True:

• Keyboard-driven workflows reduce small-motion context switches. Over a day, that compounds.
• Fewer background processes (no Electron) means less RAM and better laptop battery life.
• Configuration is portable — a repo of dotfiles sets up an identical workflow on any machine in 10 minutes.
• LSP in a TUI editor responds faster than in Electron for most operations.
• The terminal’s consistency across machines (local, remote via SSH, containers) is a real workflow advantage over VS Code Remote.

Overstated:

• “Vim/Helix is inherently faster than a GUI editor for editing text.” For small edits it is. For large navigation and structural changes, a good IDE with mouse support can be as fast or faster.
• “You’ll be more productive immediately.” You won’t. The first month is slower. Productivity gains show up in month two and later.

Dogma:

• “Real developers use the terminal.” No, real developers use the tools that make them productive. The terminal IDE is one option; VS Code, JetBrains, and Zed are also valid for plenty of brilliant engineers. Tool choice is about fit, not virtue.

If you’re thinking about switching, the case for it is real, but the case against is also real. Try it on a side project first.

A concrete first setup

If this has convinced you to try, here’s a minimal starter:

macOS:

1
2

brew install --cask ghostty
brew install zellij helix lazygit fzf ripgrep fd

Linux (Arch / Hyprland setup):

1

sudo pacman -S ghostty zellij helix lazygit fzf ripgrep fd

Config files to create:

• ~/Library/Application Support/com.mitchellh.ghostty/config (macOS) or ~/.config/ghostty/config (Linux) — paste the Ghostty config above.
• ~/.config/zellij/config.kdl — default is fine; tweak later.
• ~/.config/helix/config.toml:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

theme = "tokyonight"

[editor]
line-number = "relative"
cursorline = true
auto-save = true
bufferline = "multiple"

[editor.file-picker]
hidden = false

• ~/.config/helix/languages.toml (optional, auto-detection works for common languages).

Open Ghostty, run zellij, inside Zellij run hx . in your project directory. You now have a tiled editor-terminal workspace inside a multiplexer inside a native terminal emulator. Add panes with Zellij’s Ctrl+p menu. Open files in Helix with space + f. Run tests in a split pane. Commit with lazygit in another split.

That’s the full setup. No Electron, no IDE licenses, no plugin marketplaces. Just text, splits, and the tools doing what they’re each good at.

Why this works in 2026 when it didn’t in 2018

Terminal IDEs were always possible. What’s changed is the polish:

• Terminals got fast and pretty. Ghostty and WezTerm look and perform better than iTerm2 or gnome-terminal did five years ago.
• TUI editors matured. Helix ships good defaults; Neovim’s plugin ecosystem is best-in-class.
• LSP standardized the IDE features. You don’t have to write editor-specific intelligence plugins anymore.
• Tree-sitter made syntax highlighting real. Not regex-based — actual parsers running in the editor.
• AI tools got terminal-native. Aider, Claude Code, and Copilot CLI all work in a tmux pane.
• Graphics protocols grew up. Kitty graphics and Sixel mean image previews and even plots work inside the terminal, eliminating one of the last reasons to leave.

The terminal IDE is no longer a compromise workflow for people who hate GUIs. It’s a first-class alternative that happens to be keyboard-driven, highly portable, and very fast. Whether it’s right for you depends on what you’re trying to optimize for — but the option is genuinely there, and with Ghostty and WezTerm as the shell, it looks and feels like a 2026 tool, not a relic.

If you try it for a month and hate it, you haven’t lost much; most of the pieces (Helix, ripgrep, fzf, lazygit, zellij) are useful even if you end up running them from inside VS Code’s integrated terminal. The worst case is you learn a better terminal workflow and go back to the IDE anyway. The best case is you leave the IDE behind entirely and don’t miss it.