I Ditched tmux and Wrote My Own Tool

Chapter 1: The Screen Era

GNU Screen, around since 1987, offered the initial promise of persistent terminal sessions. But it quickly revealed its limitations:

• Mouse scrolling required complex key sequences (Ctrl+A, Esc, arrow keys)
• True color support was inadequate for modern terminals
• Color escape sequences were frequently mishandled
• Configuration accumulated into a "cargo cult" of tweaks from forums and outdated blog posts

Chapter 2: The tmux Era — Different Problems, Same Suffering

While tmux objectively improved upon Screen with cleaner architecture and better defaults, mouse handling remained problematic. Adding set -g mouse on felt victorious for five minutes, then reality set in.

Core architectural issue: tmux implements its own terminal emulator, intercepting program output, parsing it, and recoding it. This causes mouse reporting escape sequences to behave unpredictably across different interactive tools (fzf, vim, htop).

Scrollback problems:

• Stored only in process memory
• Lost upon crash or reboot
• Logging required workarounds via plugins

Configuration challenges:

• Option ordering matters
• Typos silently break behavior
• An extensive configuration ecosystem developed just to make tmux behave "normally"

Chapter 3: Exploring Alternatives — abduco and dvtm

Marc Andre Tanner's tools embraced Unix philosophy: "do one thing well."

• abduco: Session management only (detach/reattach)
• dvtm: Terminal window management only (tiled panes)

The author realized: splitting windows was used from habit, not necessity. Their actual workflow involved one session, one process — SSH in, verify, exit.

Chapter 4: dtach and the Moment of Clarity

dtach embodied pure simplicity: a small C program allowing session detachment and reattachment. The key insight was its transparency — dtach doesn't interpret output, doesn't implement virtual terminals, just passes bytes through.

Result: mouse worked, colors worked, everything worked — because dtach didn't interfere.

Limitations of dtach:

• No persistent logging (lost output when session ended)
• No list command for viewing sessions
• Manual socket naming
• No way to send input to running sessions

Chapter 5: atch — What Was Actually Needed

The author began patching dtach, eventually building atch with one core philosophy: no terminal emulation. Raw byte streams flow directly from pseudo-terminal to user terminal without parsing or recoding.

Key Features

Mouse just works — atch never intercepts mouse sequences.

Scrolling just works — alternate screen programs (vim, htop, fzf) behave identically inside and outside atch sessions.

True color and graphics pass through — $TERM remains untouched; programs see the same terminal as in a normal shell.

Zero configuration — no ~/.atchrc, no prefix keys, no plugins, no set -g directives.

The Killer Feature: Persistent Disk Logging

Every byte written to the terminal is appended to a log file in ~/.cache/atch/. When reattaching, atch replays the full history from disk, then switches to live streaming.

Scenario: "Started a build in atch, the machine rebooted, SSH back in, run atch work — you see the complete build output from before the reboot, then a fresh shell."

Default 1 MB log limit (configurable at compile time); atch clear resets history as needed.

Usage

# Enter or create session
atch work

# Run command in named session
atch new build -- make -j4

# Detach
Ctrl+\

# List sessions
atch list

# Start in background
atch start daemon myserver

# Send input to session
printf 'ls -la\n' | atch push work

# Kill session
atch kill work

# Clear history
atch clear work

Sessions are simply named sockets in ~/.cache/atch/. Paths containing / are used directly. The atch current command returns 0 with the session name if inside a session, 1 otherwise — useful for prompts and automation.

CI/CD and AI Agents

The combination of transparent proxying, persistent disk logs, push stdin capability, detached launching, and script-accessible sessions creates powerful automation primitives:

• CI/CD pipelines: Launch long deployments via atch start deploy ./deploy.sh from webhooks; deployment completes before checking output, complete logs always available
• AI agents: Long-running processes can be disconnected and reconnected; persistent audit trail survives crashes; atch list shows active sessions; printf 'continue\n' | atch push agent injects instructions
• Server processes: Multiple clients attach simultaneously to one session, seeing a unified output stream
• Post-crash debugging: Full output persists on disk after machine reboot

Comparison

• vs. tmux: No window splitting, status bar, plugins, or window management — atch is simpler for persistent sessions without terminal breakage
• vs. screen: Monolithic with decades of complexity; atch is readable C code with working mouse support
• vs. abduco: Shares the transparency philosophy; atch adds persistent disk history, push stdin, and built-in session listing
• vs. dtach: Spiritual successor with disk history, session listing, push stdin, and quality-of-life improvements; backward compatible with dtach syntax

Honest Assessment

atch doesn't replace tmux for users who heavily rely on window layouts. If your workflow depends on constant splitting, pane jumping, and plugins — atch isn't a substitute.

However, for those who've googled "tmux mouse scrolling not working" at 11 PM, who struggle with tmux.conf lines copied machine-to-machine without understanding, or who've lost session history at a critical moment — "this might be what you're looking for."

The code is small enough to read in an evening. It builds via make with no dependencies beyond a C compiler and POSIX environment. No post-installation configuration is required.

The tool does one thing: keeps your program running and connected to the terminal across disconnects. Every byte goes to logs. Every session is accessible by name. Mouse, scrolling, and colors are the terminal's responsibility, not atch's. Everything else stays out of the way.

Available at: https://github.com/mobydeck/atch (builds in seconds). Run atch work to evaluate within five minutes.

The author has used it daily for some time and never once missed tmux's mouse configuration.