be smarter

Schlagwort: tmux

  • tmux: Warum Remote-Entwickler ohne ihn nicht arbeiten können

    Wer einmal eine SSH-Verbindung verloren hat während ein langer Prozess lief — ein Test-Build, ein npm install, ein laufender Entwicklungsserver — kennt das Gefühl. Alles weg. Verbindung neu aufbauen, von vorne anfangen.

    tmux löst genau dieses Problem. Einmal eingerichtet, läuft jede Terminal-Session dauerhaft auf dem Server weiter — egal ob der Laptop zugeklappt, das WLAN gewechselt oder die VPN-Verbindung unterbrochen wurde. Man steigt einfach wieder ein, als wäre nichts gewesen.

    Das Problem mit normalen SSH-Terminals

    Wenn man sich per SSH mit einem Remote-Server verbindet, läuft alles in einem einzigen Prozess: dem SSH-Terminal. Bricht die Verbindung ab — durch Netzwerkprobleme, Sleep-Mode oder VPN-Timeout — sterben alle laufenden Prozesse mit. Entwicklungsserver tot. Lange Kompilierung weg. Claude-Session verloren.

    tmux trennt das Terminal vom SSH-Prozess. Die Session läuft auf dem Server, unabhängig davon ob gerade jemand verbunden ist.


    SSH ohne tmux vs. mit tmux — Vergleich bei Verbindungsabbruch
    Ohne tmux: alles verloren · Mit tmux: Session läuft weiter, Prozesse bleiben aktiv  ·  Klicken zum Vergrößern

    Schneller Überblick: Was läuft gerade?

    Bevor man eine neue Session anlegt, lohnt sich ein kurzer Blick ob schon eine existiert — besonders wenn man sich von einem anderen Rechner verbindet:

    tmux ls
# Ausgabe, wenn Sessions aktiv sind:
# partyplaner: 2 windows (created Wed Jun 18 09:12) [220x50]
# wsai: 1 windows (created Tue Jun 17 14:30) [220x50]

# Ausgabe, wenn keine Session läuft:
# no server running on /tmp/tmux-0/default

    Keine Ausgabe oder die Fehlermeldung oben bedeutet: tmux läuft noch nicht. Dann einfach eine neue Session anlegen.

    Sessions: das Herzstück

    Eine tmux-Session ist eine eigenständige Terminal-Umgebung auf dem Server. Sie hat einen Namen, merkt sich den Zustand und wartet auf Verbindungen.

    Sessions auflisten

    tmux ls
# partyplaner: 2 windows (created Wed Jun 18 09:12)
# wsai: 1 windows (created Tue Jun 17 14:30)

    Neue Session anlegen

    tmux new-session -s partyplaner
# Kurzform:
tmux new -s partyplaner

    Session anlegen oder anhängen

    tmux new-session -A -s partyplaner -c /root/projects/partyplaner

    Das -A-Flag ist entscheidend: existiert die Session bereits, wird sie geöffnet — existiert sie nicht, wird sie angelegt.

    An bestehende Session anhängen

    tmux attach -t partyplaner
# Kurzform:
tmux a -t partyplaner

    Detach: Session verlassen ohne sie zu beenden

    Ctrl+B  dann  D

    Die Session läuft weiter. Man kann sich von einem anderen Rechner wieder anhängen.

    Fenster und Panes: mehrere Terminals in einer Session

    Alle tmux-Tastenkombinationen beginnen mit Ctrl+B als Präfix:

    Tastenkombination Funktion
    Ctrl+B C Neues Fenster öffnen
    Ctrl+B N / P Nächstes / vorheriges Fenster
    Ctrl+B „ Horizontale Teilung (Pane unten)
    Ctrl+B % Vertikale Teilung (Pane rechts)
    Ctrl+B ←↑→↓ Zwischen Panes wechseln
    Ctrl+B Z Pane maximieren / zurücksetzen
    Ctrl+B X Aktuellen Pane schließen (Bestätigung: y/n)
    Ctrl+B & Aktuelles Fenster schließen (Bestätigung: y/n)
    Ctrl+B D Detach — Session bleibt aktiv
    Ctrl+B Ctrl+B Literales Ctrl+B ans Terminal senden

    Copy & Paste: die kleine Tücke

    Die Maus markiert standardmäßig Text auf dem lokalen Bildschirm — nicht im tmux-Buffer. Es gibt zwei Wege:

    Weg 1: tmux Copy Mode (Terminal-nativ)

    Ctrl+B [       → Copy Mode betreten
Pfeiltasten    → Cursor bewegen, scrollen
Page Up/Down   → schnell durch Output scrollen
Space          → Auswahl starten
Enter          → Auswahl kopieren, Copy Mode verlassen
Ctrl+B ]       → Einfügen (aus tmux-Buffer)

    Weg 2: Maus aktivieren (empfohlen)

    In ~/.tmux.conf auf dem Server:

    set -g mouse on

    Dann tmux source ~/.tmux.conf. Mit Maus-Modus:

    • Scrollen: Mausrad funktioniert direkt im Scrollback-Buffer
    • tmux-Buffer: Linke Maustaste gedrückt halten → Auswahl geht in den tmux-Buffer (Ctrl+B ] zum Einfügen)
    • System-Zwischenablage: Shift + Maustaste gedrückt halten → tmux wird umgangen, Text landet direkt in der Systemzwischenablage

    In VSCodium SSH Remote (integriertes Terminal) gilt zusätzlich:
    Ctrl+Shift+C kopiert die aktuelle Auswahl, Ctrl+Shift+V fügt ein — das sind die Standard-Shortcuts des Terminals, die auch mit tmux zuverlässig funktionieren.

    Claude Code in tmux: der wichtigste Anwendungsfall

    Claude Code läuft als interaktiver Prozess im Terminal. Ohne tmux bedeutet ein Verbindungsabbruch: Claude-Session verloren, laufende Aufgabe abgebrochen. Mit tmux:

    tmux new -s partyplaner   # Session starten
claude                     # Claude starten
# Aufgabe beschreiben, Laptop zuklappen — Claude arbeitet weiter

# Stunden später, von beliebigem Rechner:
tmux attach -t partyplaner # → Claude ist noch da, Output im Buffer

    Claude in tmux — Workflow: Session starten, Aufgabe geben, weggehen, zurückkommen
    Schritt-für-Schritt: tmux + Claude · Session bleibt · Output wartet im Buffer  ·  Klicken zum Vergrößern

    Besonders wertvoll für längere Aufgaben: Refactorings, Migrations, umfangreiche Feature-Implementierungen. Claude arbeitet weiter, auch wenn man nicht am Rechner sitzt.

    Minimale .tmux.conf für den Einstieg

    # ~/.tmux.conf auf dem Server

set -g mouse on               # Maus-Scrollen + Markieren
set -g history-limit 10000    # Längerer Scrollback-Buffer
set -g status-right '%H:%M %d.%m.%Y'  # Uhrzeit in Statusleiste
set -g base-index 1           # Fenster-Nummerierung bei 1 beginnen

    Laden: tmux source ~/.tmux.conf

    Fazit

    tmux ist kein optionales Extra für Remote-Entwicklung — es ist die Grundlage. Sessions überleben Verbindungsabbrüche, mehrere Rechner können dieselbe Session beobachten, Claude Code läuft weiter wenn man weg ist.

    Der Einstieg ist in 5 Minuten erledigt: tmux new -s meinprojekt, loslegen, Ctrl+B D zum Verlassen. Der Rest kommt mit der Zeit.

    Dieser Beitrag ist Teil der Reihe „KI in der Praxis“ — echte Setups, keine Theorie.

  • Ein Befehl, eine IDE, eine Session: VSCodium + tmux + Proxmox auf Linux

    Ich entwickle auf drei verschiedenen Linux-Rechnern: einem Desktop zuhause, einem zweiten Arbeitsplatz und einem Notebook unterwegs. Alle drei laufen unter Linux Mint. Das Problem: Ich möchte überall am gleichen Projekt weiterarbeiten können — ohne Setup-Overhead, ohne offene Dateien nachzuziehen, ohne mich zu fragen, wo ich gestern aufgehört habe.

    Die Lösung ist ein einzelner Befehl. Ich tippe partyplaner ins Terminal — und VSCodium öffnet sich, die richtige tmux-Session auf dem Entwicklungsserver ist aktiv, alle Dateien sind da. Egal an welchem der drei Rechner ich sitze.

    Das Fundament: Proxmox und ein LXC-Container

    Der Kern des Setups ist ein Proxmox-Server im lokalen Netz. Proxmox ist ein Hypervisor — ein System, das virtuelle Maschinen und Container verwaltet. Ich nutze keinen Cloud-Anbieter, kein gemietetes VPS, kein Kubernetes. Alles läuft auf eigener Hardware, unter meiner Kontrolle.

    Auf diesem Proxmox-Host läuft ein einziger LXC-Container (Linux Containers) mit Debian — das ist dockerdev. Darin laufen alle meine Entwicklungsprojekte, jedes in seinem eigenen Unterordner unter /root/projects/. Der Container läuft rund um die Uhr, braucht wenig Ressourcen, ist schnell gestartet und einfach zu sichern.

    Der entscheidende Vorteil gegenüber Cloud-Entwicklung: keine Latenz, keine Abhängigkeit von Drittanbietern, volle Datenkontrolle. Die Dateien verlassen das lokale Netz nicht.


    Architektur-Diagramm: Linux-Clients verbinden sich per SSH auf LXC-Container
    Setup-Übersicht: Clients → SSH → LXC-Container  ·  Klicken zum Vergrößern

    SSH-Zugang einrichten: Public Key Auth

    Damit der Alias-Trick reibungslos funktioniert, muss jeder Client-Rechner seinen SSH-Public-Key auf dockerdev hinterlegt haben.

    Schritt 1: Key generieren

    ssh-keygen -t ed25519 -C "mein-rechner"
# Erzeugt ~/.ssh/id_ed25519 (privat) und ~/.ssh/id_ed25519.pub (öffentlich)

    Schritt 2: Public Key eintragen

    ssh-copy-id root@dockerdev
# Oder manuell: Inhalt von ~/.ssh/id_ed25519.pub
# in /root/.ssh/authorized_keys auf dockerdev einfügen

    Schritt 3: Berechtigungen setzen

    chmod 700 /root/.ssh
chmod 600 /root/.ssh/authorized_keys

    Diese Berechtigungen sind nicht optional — SSH verweigert den Key-Zugang, wenn authorized_keys zu offen ist.

    Schritt 4: Root-Login erlauben

    In /etc/ssh/sshd_config auf dockerdev:

    PermitRootLogin yes
PubkeyAuthentication yes

    Danach: systemctl restart sshd

    Der Alias-Trick: _proj und VSCodium SSH Remote

    VSCodium (die Open-Source-Variante von VS Code, ohne Microsoft-Telemetrie) hat eine SSH Remote Extension. Mit ihr öffnet sich die IDE direkt im Dateisystem des Remote-Hosts — als wäre der Entwicklungsserver der lokale Rechner.

    function _proj() {
    local name="$1" host="$2" path="$3"
    ssh -o ConnectTimeout=5 root@"$host" \
        "tmux new-session -A -d -s '$name' -c '$path' 2>/dev/null; true"
    codium --folder-uri "vscode-remote://ssh-remote+root@${host}${path}"
}

function partyplaner() { _proj partyplaner dockerdev /root/projects/partyplaner; }
function wsai()        { _proj wsai        dockerdev /root/projects/wsai; }
function hermesagent() { _proj hermesagent dockerdev /root/projects/hermesagent; }

    tmux: der stille Held

    tmux ist ein Terminal-Multiplexer: Er erzeugt Sessions, die auf dem Server weiterläufen, auch wenn der Client getrennt wird. Das -A-Flag (attach if exists) sorgt dafür, dass man am zweiten Arbeitsplatz in exakt der gleichen Session weitermacht, die man am Desktop verlassen hat.

    tmux new-session -A -d -s 'partyplaner' -c '/root/projects/partyplaner'

    tmux Session-Konzept: Persistente Session, mehrere Clients
    tmux hält die Session — von jedem Client einsteigen  ·  Klicken zum Vergrößern

    Dotfiles und Gitea: alle Rechner synchron

    Die _proj-Funktion und alle Projekt-Aliases leben in ~/dotfiles/bashrc_shared — einem Bash-Skript, das per Symlink als ~/.bashrc eingebunden wird. Das Dotfiles-Repo liegt auf einem eigenen Gitea-Server im lokalen Netz.

    Wenn ich auf einem Rechner einen neuen Alias anlege, sind alle anderen mit zwei Befehlen auf dem Stand:

    git -C ~/dotfiles pull && source ~/.bashrc

    Gitea ist der einzige Ort, an dem die Aliases gepflegt werden — kein rsync, kein manuelles Verteilen.

    Neues Projekt anlegen: Claude übernimmt

    Wenn ich ein neues Projekt anlegen will, sage ich Claude einfach: „Lege ein neues Projekt mit dem Namen X an.“

    1. Gitea-Repo erstellen (via Gitea API)
    2. Git auf dockerdev initialisieren (per SSH, mit Initial Commit)
    3. VSCodium tmux-Integration anlegen (.vscode/settings.json)
    4. Alias in bashrc_shared eintragen
    5. Dotfiles committen und pushen — alle anderen Rechner haben den Alias beim nächsten Pull
    function neuprojekt() { _proj neuprojekt dockerdev /root/projects/neuprojekt; }

    tmux Schnellreferenz


    tmux Schnellreferenz: Sessions, Fenster, Copy&Paste, Claude in tmux
    Alle wichtigen tmux-Befehle auf einen Blick  ·  Klicken zum Vergrößern

    Fazit: Einmal denken, überall arbeiten

    Ein LXC-Container der immer läuft. Ein tmux der die Session hält. Ein Alias der alles zusammenbringt. Gitea als Synchronisationsschicht. Claude als Assistent der neue Projekte auf Zuruf anlegt. Kein Cloud-Anbieter, keine monatliche Rechnung, keine Daten bei Dritten.

    Einmal aufgesetzt, ist es unsichtbar. Und das ist genau der Punkt.

    Dieser Beitrag ist Teil der Reihe „KI in der Praxis“ — echte Setups, keine Theorie.