Guides

Getting the same terminal setup on Windows and Linux

If you work on a Windows laptop and a Linux machine, the problem is rarely the shell. It is that everything around the shell differs: the copy-paste keys, where the tabs are, whether Ctrl+W closes a pane or deletes a word, how the font renders, and which config file you are supposed to edit this time. Four approaches actually work. They are not equally good, and which one wins depends on how much of your week is spent on each machine.

1. Sync dotfiles and accept two front ends

The cheapest option: keep your shell config in a git repository, symlink it into place on both machines, and let each OS use whatever terminal it likes. A chezmoi or bare-repo setup gets you there in an afternoon.

This fixes the shell and nothing else. Your prompt, aliases and functions follow you; your window chrome and keybindings do not. If you mostly live inside Neovim or tmux, that may be enough, because the part you touch is already inside the terminal rather than around it.

2. Use WSL and make Windows pretend to be Linux

WSL2 gives you a real Linux userspace on Windows, and Windows Terminal integrates with it properly. Run the same shell, the same tools and the same dotfiles on both machines, and the difference mostly disappears.

The catch is everything that crosses the boundary. Filesystem performance across /mnt/c is poor enough to be noticeable in a large repository, native Windows toolchains are awkward to reach from inside WSL, and anything that wants a GUI, a USB device or a specific driver becomes a research project. WSL is excellent when your work is entirely inside Linux and Windows is just the hardware you were issued.

3. Run one cross-platform emulator on both

Several terminals build for both platforms, so you can carry one config across. WezTerm is the strongest of these: Lua config, a built-in multiplexer, and native builds for Linux, macOS, Windows and the BSDs. Alacritty does the same job with a single TOML file if you want less. Both are free and open source.

This is the right answer for a lot of people, and it costs nothing. What you are signing up for is assembling the workspace yourself — the emulator gives you a fast grid, and tabs, splits, persistence and layout come from tmux, a window manager, and a config file you maintain.

4. One application, shipped identically for both

The last option is a workspace that is the same program on both platforms rather than the same config on two programs. That is what Cross Platform Terminal is: the same shortcuts, the same dockable layout, the same settings screens, from one build per OS.

  • Extract and run. No installer on Windows, an AppImage or tarball on Linux.
  • Dockable panels, edge rails and pinned panes, so the layout is part of the app rather than something you rebuild in tmux on each machine.
  • Per-view layouts: each view keeps its own arrangement, and the arrangement is the same on both machines.
  • Quirks that differ between platforms — escape sequences, input edge cases, rendering glitches — are handled inside the app rather than by you.

CPT is a paid subscription with no free tier, and macOS is still in progress. If either of those is a blocker, options 1 to 3 are genuinely good and free — start there.

Which to pick

  • Mostly one OS, occasionally the other: sync dotfiles and stop there.
  • Windows hardware, Linux work: WSL2 plus Windows Terminal.
  • Both machines daily, happy to assemble the stack: WezTerm or Alacritty plus tmux.
  • Both machines daily, want it to already be assembled: that is the gap CPT is built for.