MOLTamp + tmux: a power user setup

A common question I get is whether MOLTamp replaces tmux, or whether you should use one or the other. Short answer: they solve different problems and they work well together. Here is the setup I actually run, what each tool is doing, and where the line between them lives.

What each tool is for

tmux is for session persistence and multiplexing across remote machines. The killer feature is that you can SSH into a server, attach to a tmux session, do work, detach, lose your network connection, come back tomorrow, reattach, and find everything exactly where you left it. It is also the right answer for pane splitting on remote hosts where you cannot run a graphical app.

MOLTamp is for the local visual layer of your terminal. Skins, widgets, vibes, agent integration, window chrome. None of which tmux does (it lives below the visual layer entirely).

The two are complementary. tmux is invisible at the visual layer. MOLTamp is invisible at the multiplexing layer. They stack.

My setup

Here is what runs on my machine on any given workday:

1. MOLTamp is the outer shell. The window I look at all day.
2. Inside MOLTamp, I have two sessions: one for local work, one for remote work.
3. The local session runs Claude Code in the current project directory. No tmux needed because the session is local and MOLTamp persists it for me.
4. The remote session runs an SSH connection to my dev server, which immediately attaches to a tmux session on that server.
5. The remote tmux session has two panes: a shell on the left, and htop (or whatever monitoring tool I am using) on the right.
6. Both sessions can be running simultaneously and I switch between them with Cmd+1 and Cmd+2.

This gives me: local agent work in a beautifully skinned terminal, plus remote multiplexed shells that survive disconnection, plus the ability to flip between them without losing context.

Why MOLTamp + Claude Code does not need tmux locally

Locally, MOLTamp itself is the persistence layer. If I close the laptop and come back tomorrow, my MOLTamp session is still there with all its state — current directory, tab structure, layout, everything. There is no scenario where I would lose my local Claude Code session unexpectedly, because there is no remote network in the picture. Tmux's killer feature does not apply.

This is why people who switch from "iTerm + tmux" to "MOLTamp + Claude Code" often find they stop using tmux at all on local machines. The use case evaporated.

Why tmux is still essential remotely

Remotely, the network is the problem. SSH connections drop. Wifi blips. Coffee shop networks die at the worst possible moment. If your remote work is running raw inside an SSH session and the connection dies, your work dies with it. tmux exists specifically to solve this — your shell stays alive on the server, the SSH session is just a window into it, and reconnecting is a single tmux attach away.

The right rule of thumb is: every SSH connection you make should immediately attach to a tmux (or screen) session on the remote side. Even if you do not think you need persistence right now. The cost of attaching to tmux when you do not need it is zero. The cost of NOT attaching when you do need it is losing an hour of work.

How they coexist visually

This is the part that trips people up. Both MOLTamp and tmux have status bars / chrome / visual indicators. If you run them together naively you can end up with two layers of status bars stacked on top of each other.

The fix is to make tmux's status bar minimal (just session name and clock) and let MOLTamp's chrome handle the rest. Here is the relevant slice of my ~/.tmux.conf:

set -g status-bg colour234
set -g status-fg colour250
set -g status-left "#[bold]#S "
set -g status-right "%H:%M"
set -g status-left-length 30
set -g status-right-length 30
set -g pane-border-style fg=colour237
set -g pane-active-border-style fg=colour33

That gives you a thin tmux status bar inside the remote session that does not fight MOLTamp's chrome. The visual effect is "remote tmux session living inside a MOLTamp tab," which is exactly the mental model.

When to NOT use both

If you are doing 95% local work in MOLTamp with Claude Code, do not start using tmux just because. The added complexity is not worth it for a use case that does not exist. The "MOLTamp + tmux" setup makes sense when you have real remote work that needs persistence. If you do not, skip tmux entirely and let MOLTamp be your only terminal layer.

The wrong move is to use tmux locally as a habit. tmux locally adds friction (extra keybindings, an extra layer of state to manage, panes that conflict with MOLTamp's widgets) without solving any problem you actually have.

A note on tmux key prefixes

If you do run tmux, change the prefix from the default Ctrl+B to Ctrl+A. Not because Ctrl+A is universally better — because Ctrl+B conflicts with a bunch of MOLTamp shortcuts and you will be in pain. Ctrl+A has its own conflicts (it is also screen's default and bash's "go to start of line"), but the conflicts are easier to live with.

unbind C-b
set -g prefix C-a
bind C-a send-prefix

Add to ~/.tmux.conf, reload with tmux source ~/.tmux.conf, done.

The summary

• Local work in MOLTamp: no tmux. MOLTamp is the persistence layer.
• Remote work over SSH: tmux always. Network is your enemy.
• Visual chrome: let MOLTamp do the heavy lifting, keep tmux's status bar minimal.
• Key prefix: rebind tmux to Ctrl+A to avoid MOLTamp conflicts.

If you set this up once, it just works forever. The two tools genuinely solve different problems and stacking them gives you the best of both. Try it for a week and you will not go back.