Skip to content
KitploitKITPLOIT
ToolsBlog
Einreichen
ToolsBlog
Einreichen

Hacking-, PenTest- und Cybersicherheits-Tools für Ihr Sicherheitsarsenal!

Kitploit ist ein Verzeichnis von Hacking-, Cybersicherheits- und Pentesting-Tools. Entdecken Sie die neuesten Projekt-Updates, um Schwachstellen zu finden, Systeme zu analysieren, Tests zu automatisieren und Ihre Sicherheit zu stärken.

··Feeds·Kontakt·Datenschutz·© 2026 Kitploit

Tool-Verzeichnis

Kategorien

Alle Kategorien anzeigen
Loading categories
vibebox — Ultraschnelles CLI auf Apple Silicon macOS für schnelle, sandboxierte Entwicklung und LLM-Agenten. | Kitploit
Tools/GitHubGitHub/robcholz/vibebox
Allgemeine DienstprogrammeContainer-SicherheitDynamische Analyse (Sandboxing)SicherheitsvirtualisierungDevSecOpsKI-Sicherheit
GitHubrobcholz/vibebox

vibebox

Ultraschnelles CLI auf Apple Silicon macOS für schnelle, sandboxierte Entwicklung und LLM-Agenten.

Repository anzeigen
186155vor 6 MonatenVon Kitploit geprüft
Webseite

Beliebteste

Alle anzeigen →

Entdecken Sie die meistgenutzten Tools unserer Community.

Alle Tools erkunden

Durchsuchen Sie unsere Tool-Sammlung

Alle Tools anzeigen →
Teilen

VibeBox-Logo

eine ultraschnelle Open-Source-Sandbox für das sichere Ausführen von Coding-Agenten.

Crates.io MIT licensed Build Status

Englisch | 简体中文

VibeBox ist eine projektspezifische Micro-VM-Sandbox zum Ausführen von Coding-Agenten unter macOS (Apple Virtualization Framework). Es ist für einen Alltags-Workflow optimiert: schnelles Warm-Re-Entry, explizite Mounts und wiederverwendbare Sitzungen.

Für wen es gedacht ist: macOS-Nutzer, die Coding-Agenten ausführen und echte Isolation wünschen, ohne auf einen schnellen täglichen Workflow zu verzichten.

Kurze Fakten: Warm-Re-Entry liegt auf meinem M3 typischerweise bei <5s (variiert je nach Maschine/Cache); der erste Start lädt ein Debian-Basisimage herunter und richtet es ein (netzwerkabhängig).

Sicherheitsmodell: Linux-Gast-VM mit expliziten Mount-Allowlists aus vibebox.toml (Repo-first, alles andere per Opt-in).

  • In Sekunden starten/anhängen: vibebox bringt Sie in eine wiederverwendbare Sandbox für das aktuelle Repo
  • Standardmäßig projektspezifisch: explizite Mounts + auf das Repo beschränkte Änderungen (Repo-first, alles andere wird in die Allowlist aufgenommen)
  • Session-basiert: Multi-Instanz- und Sitzungsverwaltung (Wiederverwendung, mehrere Terminals, Bereinigung)

Quick Demo

root@kitploit:~
# from any repo
cd my-project
vibebox

Was Sie sehen sollten (ungefähr):

root@kitploit:~
vibebox: starting (session: my-project)
vibebox: attaching...
vibecoder@vibebox:~/my-project$

VibeBox Terminal UI

Warum ich VibeBox gebaut habe

Ich nutze täglich Coding-Agenten und wollte ihnen eine echte Shell geben, ohne ihnen meinen Host-Rechner zu überlassen. Wenn man alles absichert, hagelt es ununterbrochen Bestätigungen; lockert man es, macht man sich Sorgen um das Löschen von Dateien, den Zugriff auf Geheimnisse oder das Verlassen des Repos.

VibeBox ist der Mittelweg: eine pro-Repo-Sandbox mit einer harten VM-Grenze, schnellem Wiedereinstieg und expliziten Mounts. Es ist darauf ausgelegt, für Agentenarbeit „immer an“ zu sein, ohne die Sicherheit zur lästigen Pflicht zu machen.

Warum eine Micro-VM (vs. Container)?

Container sind großartig. VibeBox versucht nicht, Docker/Devcontainer zum Erstellen von Diensten zu ersetzen.

Ich wollte speziell eine VM-förmige Standardeinstellung für Agent-Workflows unter macOS:

  • Standardmäßige Gast-Kernel-Isolationsgrenze: Wenn ich einen Agenten beliebige Befehle ausführen lasse, möchte ich, dass der „Sichere Modus“ ein Linux-Gast ist, nicht mein Host.
  • Sitzungen als erstklassiger Workflow: Anhängen/Wiederverwenden pro Repo, mehrere Terminals in derselben Sandbox, zuverlässige Bereinigung, um verwaiste Umgebungen zu vermeiden.
  • Explizite Mount-Allowlists als primäre Benutzererfahrung: standardmäßig auf das Repo beschränkt; alles andere ist eine explizite Entscheidung.
  • Minimale Einrichtung pro Repo: Sie können Teile davon mit Compose/Devcontainern nachbilden, aber ich wollte einen einzelnen Befehl, der von Repo zu Repo funktioniert, ohne dass Container-Konfigurationen für den grundlegenden „Sichere Shell“-Workflow verwaltet werden müssen.

Vergleich

Hier ist, warum ich nicht einfach vorhandene Optionen genutzt habe:

  • vibe: super praktisch und trifft den Nagel auf den Kopf mit „Null-Konfiguration, einfach loslegen“. VibeBox ist bewusst auf einer anderen Achse: pro-Repo-Konfiguration + Sitzungen + Multi-Instanz-Lebenszyklus.
  • QEMU: leistungsstark, aber die Konfigurationsfläche ist riesig. Für den täglichen Sandbox-Einsatz ist es nicht „Repo öffnen und loslegen“ – es ist ein eigenes Projekt.
  • Docker / Devcontainer / Devpods: großartiges Ökosystem. Mein Reibungspunkt war nicht die rohe Startzeit, sondern der tägliche Aufwand, pro-Repo-Agenten-Sandboxes standardmäßig sicher zu halten (Mount-Allowlists, Offenlegung von Geheimnissen, Anhängen/Wiederverwenden, Bereinigen), ohne pro Repo Container-Konfigurationen für den grundlegenden Workflow zu verwalten.

Das hat mich dazu bewegt, VibeBox zu bauen: Ich wollte eine projektbezogene Sandbox, die schnell betreten werden kann (einfach vibebox), echte Konfiguration + Sitzungen unterstützt und eine harte Isolationsgrenze beibehält.

Installation

root@kitploit:~
# install script
curl -fsSL https://raw.githubusercontent.com/robcholz/vibebox/main/install | bash

# package managers
cargo install vibebox

# manual install
curl -LO https://github.com/robcholz/vibebox/releases/download/latest/vibebox-macos-arm64.zip
unzip vibebox-macos-arm64.zip
mkdir -p ~/.local/bin
mv vibebox ~/.local/bin
export PATH="$HOME/.local/bin:$PATH"

Anforderungen

  • macOS auf Apple Silicon (VibeBox verwendet die Virtualisierungs-APIs von Apple).

Erster Start

Der erste vibebox-Lauf lädt ein Debian-Basisimage herunter und richtet es ein. Danach verwenden projektbezogene Instanzen das zwischengespeicherte Basisimage für viel schnellere Starts.

Dokumentation

Schnellstart

root@kitploit:~
cd /path/to/your/project
vibebox

Beim ersten Start erstellt VibeBox vibebox.toml in Ihrem Projekt (falls nicht vorhanden) und ein .vibebox/-Verzeichnis für Instanzdaten.

Konfiguration (vibebox.toml)

vibebox.toml befindet sich standardmäßig im Projektstammverzeichnis. Sie können es mit vibebox -c path/to/vibebox.toml oder der Umgebungsvariablen VIBEBOX_CONFIG_PATH überschreiben, aber der Pfad muss innerhalb des Projektverzeichnisses bleiben.

Standardkonfiguration (automatisch erstellt, wenn nicht vorhanden):

root@kitploit:~
[box]
cpu_count = 2
ram_mb = 2048
disk_gb = 5
mounts = [
    "~/.codex:~/.codex:read-write",
    "~/.claude:~/.claude:read-write",
]

[supervisor]
auto_shutdown_ms = 20000

disk_gb wird nur angewendet, wenn der Instanzdatenträger zum ersten Mal erstellt wird. Wenn Sie ihn später ändern, führen Sie vibebox reset aus, um den Datenträger neu zu erstellen.

Mounts

  • Ihr Projekt wird mit Lese-/Schreibzugriff unter ~/<Projektname> eingehängt, und die Shell startet dort.
  • Falls ein .git-Verzeichnis vorhanden ist, wird es mit einem tmpfs-Mount innerhalb der VM maskiert, um versehentliche Änderungen vom Gast aus zu verhindern.
  • Zusätzliche Mounts stammen aus box.mounts im Format host:guest[:read-only|read-write].
  • Host-Pfade unterstützen die ~-Erweiterung. Relative Gast-Pfade werden als /root/<Pfad> behandelt.
  • Gast-Pfade, die ~ verwenden, werden der Einfachheit halber nach /home/<ssh-user> verlinkt. Führen Sie vibebox explain aus, um die aufgelösten Host/Gast-Zuordnungen zu sehen.

CLI-Befehle

root@kitploit:~
vibebox             # start or attach to the current project VM
vibebox list        # list known project sessions
vibebox reset       # delete .vibebox for this project and recreate on next run
vibebox purge-cache # delete the global cache (~/.cache/vibebox)
vibebox explain     # show mounts and network info

In der VM

  • Standard-SSH-Benutzer: vibecoder
  • Hostname: vibebox
  • Die Bereitstellung des Basisimages installiert: Build-Tools, git, curl, ripgrep, openssh-server und sudo.
  • Beim ersten Login installiert VibeBox mise und konfiguriert Tools wie uv, node, @openai/codex und @anthropic-ai/claude-code (nach bestem Bemühen).
  • Shell-Alias: :help und :exit.

Zustand & Cache

  • Der Projektstatus befindet sich in .vibebox/ (Instanzdatenträger, SSH-Schlüssel, Logs, Manager-Socket/PID). vibebox reset entfernt ihn.
  • Der globale Cache befindet sich in ~/.cache/vibebox (Basisimage + gemeinsamer Gast-Cache). vibebox purge-cache löscht ihn.
  • Der Sitzungsindex befindet sich in ~/.vibebox/sessions und wird von vibebox list angezeigt.

Mitwirken

Wenn Sie daran interessiert sind, zu VibeBox beizutragen, lesen Sie bitte unsere Beitragsdokumentation, bevor Sie einen Pull-Request einreichen.

FAQ

Wie unterscheidet sich dies von anderen Sandboxes?

VibeBox ist für schnelle, wiederholbare lokale Sandboxes mit minimalem Aufwand gebaut. Was hier anders ist:

  • Warm-Re-Entry liegt auf meinem M3 typischerweise bei <5s (variiert je nach Maschine/Cache), sodass Sie schnell zurückkehren können.
  • Ein einfacher Befehl – vibebox – bringt Sie von Ihrem Projekt aus in die Sandbox.
  • Die Konfiguration befindet sich in vibebox.toml, wo Sie CPU, RAM, Datenträgergröße und Mounts festlegen können.
  • Sitzungen sind erstklassig: Wiederverwendung, mehrere Terminals, Bereinigung.

Besonderer Dank

vibe von lynaghk.

Und die großartige Rust-Community – ohne das Ökosystem und die Toolchain wie crates.io wäre das nicht möglich!

Folge mir auf X x.com/robcholz

Tool herunterladen