Einrichten

1. Installieren. Das Skript legt das Binary nach ~/.local/bin, Node ist nicht nötig:

   curl -fsSL https://workban.de/cli/install.sh | sh
   

   Meldet es, dass der Ordner nicht im PATH liegt (auf macOS der Normalfall), trag die angezeigte export-Zeile in ~/.zshrc ein (unter Linux meist ~/.bashrc) und öffne ein neues Terminal.
2. Anmelden:

   workban auth login --token wb_p_…
   

3. Repository verbinden. Liegt im Repo schon eine .workban.toml, ist nichts zu tun. Sonst im Repo einmal workban init ausführen und die neuen Dateien committen.
4. Prüfen: workban doctor im Repo. Jede Zeile sollte einen Haken haben.
5. Loslegen: Claude Code im Repo starten, im Terminal oder in der Desktop-App im Bereich Code. Beim Start erscheint eine Zeile mit dem Workban-Projekt.

1. Git for Windows installieren (git-scm.com), falls es fehlt. Claude Code führt die Workban-Hooks in Git Bash aus, ohne Git Bash greift der Riegel nicht.
2. Installieren in PowerShell. Das Skript legt workban.exe nach %LOCALAPPDATA%\workban\bin, trägt den Ordner in den PATH ein und wählt selbst zwischen x64 und ARM64:

   irm https://workban.de/cli/install.ps1 | iex
   

3. Anmelden:

   workban auth login --token wb_p_…
   

4. Neu starten. Terminals und die Claude-Desktop-App einmal ganz schließen und neu öffnen. Erst dann kennen sie den neuen PATH.
5. Repository verbinden. Liegt im Repo schon eine .workban.toml, ist nichts zu tun. Sonst im Repo einmal workban init ausführen und die neuen Dateien committen.
6. Prüfen: workban doctor im Repo. Jede Zeile sollte einen Haken haben.
7. Loslegen: Claude Code im Repo starten, im Terminal oder in der Desktop-App im Bereich Code als lokale Sitzung.

Mit WSL gilt unter Windows alles wie unter Linux.

Ab 0.49 geschieht das von selbst beim Start einer Claude-Code-Sitzung (Automatisches Update). Von Hand, auf allen Systemen gleich:

workban update          # holt die Version, die der Server ausliefert
workban init --update   # danach je Repo: Regel, Skill und Hooks auf den neuen Stand heben, dann committen

Was dabei genau passiert, steht bei workban update. Sessionstart und workban doctor erinnern daran, wenn ein Repo noch alte Dateien hat.

Die CLI wird nicht auf npm veröffentlicht. Der Standardweg ist ein eigenständiges Binary ohne Node. Es entsteht mit bun build --compile je Plattform (macOS arm64 und x64, Linux x64 und arm64, Windows x64 und arm64) und ist 60 bis 90 MB groß, weil die Laufzeit drin steckt.

# 1. Binary vom Workban-Server (Standard, kein Node nötig)
curl -fsSL https://workban.de/cli/install.sh | sh        # macOS, Linux → ~/.local/bin/workban
irm https://workban.de/cli/install.ps1 | iex             # Windows (PowerShell) → %LOCALAPPDATA%\workban\bin

# 2. npm-Tarball vom Server (Node 22 oder neuer; hängt an der aktiven Node-Version, bei nvm je Version)
npm install -g https://workban.de/cli/workban-0.8.0.tgz   # versioniert, npm cacht Tarballs nach URL
npm install -g https://workban.de/cli/workban.tgz         # immer die neueste, ggf. npm cache clean --force

# 3. Aus dem GitHub-Release zum Tag: Binaries und Tarball hängen dort an

# 4. Aus dem Checkout (Entwicklung): einmal bauen, dann global verlinken
pnpm --filter workban build && (cd packages/cli && npm link)

WORKBAN_INSTALL_DIR wählt ein anderes Zielverzeichnis, WORKBAN_BASE einen anderen Server. Die Quelle liegt in packages/cli, pnpm --filter workban build erzeugt dist/index.js.

• Ort: ~/.local/bin/workban. macOS nimmt diesen Ordner nicht von sich aus in den PATH, das Skript nennt dann die fehlende export-Zeile.
• Signatur: Das Binary ist nicht mit einem Entwicklerzertifikat signiert. Per curl geladen setzt macOS kein Quarantäne-Merkmal, es startet ohne Nachfrage. Ein im Browser geladenes Binary würde Gatekeeper blockieren, deshalb immer das Skript.
• Programme ohne Login-Shell: Die Claude-Desktop-App und IDEs lesen ~/.zshrc nicht. Die Hooks hängen deshalb ~/.local/bin, /usr/local/bin und /opt/homebrew/bin an ihren PATH an. workban doctor meldet unter „Hooks", ob workban so gefunden wird.
• Config: ~/.config/workban/config.toml, angelegt mit Rechten 0600.
• Shell-Completion: zsh und bash, einmal workban completion install.

Empfohlen ist Windows nativ mit Git for Windows: Claude Code braucht es dort ohnehin, sein Bash-Tool und die Hooks laufen in Git Bash. Alternativ WSL, dann verhält sich alles wie unter Linux.

• Installer: läuft in Windows PowerShell 5.1 und PowerShell 7. Er liest die Architektur aus PROCESSOR_ARCHITECTURE und lädt windows-x64 oder windows-arm64, etwa für eine VM auf einem Mac mit Apple Silicon. Das Skript ist reines ASCII, und der Server liefert es mit charset=utf-8 aus, sonst zeigt Windows PowerShell 5.1 Umlaute verstümmelt.
• PATH: Der Installer trägt %LOCALAPPDATA%\workban\bin in den Benutzer-PATH ein. Jedes Programm, das danach startet, kennt ihn. Schon laufende (Terminals, die Claude-Desktop-App) erst nach einem Neustart.
• Aktualisieren: workban update in PowerShell oder Git Bash. Der npm-Weg geht weiterhin, update ruft dann npm.cmd über die Shell auf.
• Config: %APPDATA%\workban\config.toml. WORKBAN_CONFIG_DIR und XDG_CONFIG_HOME gelten weiterhin. Die Rechte 0600 gibt es auf NTFS nicht, der Ordner ist nur für das eigene Profil sichtbar.
• Hooks: workban init trägt workban hook gate und workban hook session ein und hängt davor die üblichen Installationsorte an den PATH. Ohne Git Bash nimmt Claude Code PowerShell, und dort ist ein vorangestelltes PATH="…" keine gültige Zuweisung. Workban setzt deshalb Git Bash voraus.
• Bash- und PowerShell-Tool: Claude Code hat unter Windows neben Bash ein eigenes PowerShell-Tool. Der Riegel prüft beide und kennt Cmdlets wie Set-Content, Out-File und Remove-Item. Pfade vergleicht er unabhängig von Schreibweise (C:\work\app, C:/work/app, /c/work/app) und Groß- und Kleinschreibung.
• Shell-Completion: nur für zsh und bash, also in Git Bash. PowerShell hat keine.
• Getestet am 2026-09-30 in einer Windows-VM mit Claude Desktop (Bereich Code): Installation, Anmeldung, workban update, workban doctor und der Riegel für Write und das PowerShell-Tool.