# TMUX + GNOME Terminal on Wayland: Fixing the Ctrl+W Freeze

You press Ctrl+W to close a terminal tab. The screen locks up. Your mouse is dead. Your keyboard does nothing. The only escape is mashing Alt+F2 or waiting for the compositor to recover. If you're running tmux inside GNOME Terminal on Ubuntu 24.04 with Wayland, this is a known multi-layer bug — and it's fixable.

## The Setup That Triggers It

My tmux config creates three panes automatically on session start using a session-created hook:

# ~/.tmux.conf
set-hook -g session-created 'split-window -h ; split-window -v'

This runs every time tmux launches. Three panes, ready to go. The problem isn't the panes themselves — it's what happens when the terminal dies while tmux is alive.

## The Chain of Failure

When you press Ctrl+W in GNOME Terminal, three things collide:

┌──────────────────────────────────────────────────────────────┐
│                    Ctrl+W pressed                            │
└──────────────┬───────────────────────────────────────────────┘
               │
               ▼
┌──────────────────────────────────────────────────────────────┐
│  GNOME Terminal: "A process is still running. Close tab?"    │
│  (confirm-close dialog appears)                              │
└──────────────┬───────────────────────────────────────────────┘
               │
               ▼
┌──────────────────────────────────────────────────────────────┐
│  Wayland Compositor: Dialog grabs input focus incorrectly    │
│  Keyboard/mouse events routed to wrong surface               │
│  Known bug: LP#1839136                                       │
└──────────────┬───────────────────────────────────────────────┘
               │
               ▼
┌──────────────────────────────────────────────────────────────┐
│  tmux: PTY killed mid-operation (splits still executing)     │
│  Session enters frozen state — stdin locked                  │
│  Known bug: tmux/tmux#2324                                   │
└──────────────────────────────────────────────────────────────┘

Three independent bugs, creating a perfect storm:

1. GNOME Terminal's confirmation dialog fires because tmux is a running child process
2. Wayland's dialog focus handling misroutes input events, especially on multi-monitor setups
3. tmux's PTY cleanup doesn't handle abrupt terminal death gracefully during split operations

## Why the session-created Hook Makes It Worse

The split-window -h ; split-window -v hook creates a race condition. If Ctrl+W is pressed while the splits are still executing, tmux is in a transitional state — panes are half-created, PTY allocations are in flight. When the terminal kills the connection mid-split, tmux can't clean up properly and the session locks.

Even after the session is fully created, the three-pane layout means tmux has three PTY file descriptors to manage during shutdown. If the terminal process dies abruptly (SIGKILL from the window manager), tmux may attempt to write to dead file descriptors, causing it to hang.

## The Fix

Three changes resolve it completely.

### 1. Disable the Confirmation Dialog

The root trigger is the "process still running" dialog. Disable it:

gsettings set org.gnome.Terminal.Legacy.Settings confirm-close false

Now Ctrl+W closes the tab immediately without the Wayland dialog focus bug entering the picture. You can still close tabs with Ctrl+Shift+W or the X button as a habit, but the freeze is gone.

### 2. Tell tmux to Detach Cleanly

Add these to ~/.tmux.conf:

# Detach cleanly when the terminal closes instead of freezing
set -g detach-on-destroy on

# Prevent tmux from holding onto a dead terminal
set -g exit-unattached off

detach-on-destroy on tells tmux to detach the client when the parent terminal is destroyed, rather than trying to hold onto a dead PTY. The session stays alive in the background — you can reattach later with tmux attach.

exit-unattached off keeps the tmux server running even when all clients disconnect, so your session and pane layout survive the terminal closing.

### 3. Stabilize the Hook

# Automatically create 3 panes on new session
set-hook -g session-created 'split-window -h ; split-window -v ; select-pane -t 0'

Adding select-pane -t 0 at the end ensures focus is deterministic after the splits complete. Without it, focus can land on a pane that's still initializing, which compounds the race condition during abrupt disconnects.

## The Complete tmux.conf

Here's the relevant section after the fix:

# Automatically create 3 panes on new session
set-hook -g session-created 'split-window -h ; split-window -v ; select-pane -t 0'

# Detach cleanly when the terminal closes instead of freezing
set -g detach-on-destroy on

# Prevent tmux from holding onto a dead terminal
set -g exit-unattached off

## Verifying the Fix

# Kill any existing tmux sessions
tmux kill-server

# Start fresh
tmux

# Press Ctrl+W — tab should close instantly, no freeze
# Verify tmux session survived:
tmux ls

If tmux ls shows your session, the detach worked. Reattach with tmux attach.

## The Nuclear Option: Switch to X11

If you still experience compositor-level freezes after these changes, the issue may be deeper in the Wayland stack. You can switch GNOME to X11:

sudo nano /etc/gdm3/custom.conf

Uncomment or add:

WaylandEnable=false

Reboot. X11 doesn't have the dialog focus bug that Wayland exhibits. This is a last resort — the tmux and gsettings fixes above should be sufficient for most setups.

## Affected Versions

## Key Takeaways

• >Ctrl+W in GNOME Terminal = close tab, which triggers a confirmation dialog when processes are running
• >Wayland's dialog focus handling can grab keyboard/mouse input incorrectly, causing apparent freezes
• >tmux doesn't handle abrupt disconnects cleanly during split operations — detach-on-destroy fixes this
• >The fix is three lines in ~/.tmux.conf and one gsettings command
• >When debugging "frozen screen" bugs, check for layered interactions between the compositor, terminal emulator, and multiplexer — the bug is rarely in just one component