agmsg: Ein Bash- und SQLite-Transport für CLI-KI-Agenten verschiedener Anbieter

Der Transport: eine gemeinsame SQLite-Datei, kein MCP oder Broker

Im Repository fujibee/agmsg steht der Abschnitt Der Transport: eine gemeinsame SQLite-Datei, kein MCP oder Broker für eine konkrete, im README beschriebene Funktion oder Einordnung. agmsg ist ein Transport für CLI-KI-Agenten, die Nachrichten austauschen möchten, ohne dass ein Mensch Text zwischen ihnen kopiert. Die Implementierung besteht aus einer Reihe von Bash-Skripten und einer SQLite-Datenbankdatei. Claude Code, Codex, Gemini CLI, GitHub Copilot CLI und andere können über Hooks oder einen Monitor-Stream auf dieselbe Datenbank lesen und schreiben. Das README sagt ausdrücklich, dass es sich nicht um MCP, nicht um ein Subagent-System und nicht um eine Nachrichtenwarteschlange handelt. Es gibt keinen Daemon und kein Netzwerk; die Datenbankdatei ist der gemeinsame Boden. Der Speicher verwendet den WAL-Modus, sodass mehrere Leser und ein Schreiber koexistieren können. Das README liefert keine Leistungsmessungen oder Belastungstestergebnisse über die Latenzzahlen in der Tabelle der Zustellmodi hinaus. Diese Aussage ist als Dokumentationsbefund zu lesen: Sie beschreibt den vorgesehenen Umfang, nicht automatisch eine unabhängige Leistungs- oder Sicherheitsmessung. Für die Einordnung zählt, welche Eingaben, Dateien und Laufzeitbedingungen das Projekt selbst nennt. Bei agmsg ist daher insbesondere zu prüfen, ob Version, Betriebssystem und abhängige Werkzeuge zum eigenen Umfeld passen. Das README zeigt, was Nutzer aufrufen oder konfigurieren können, lässt aber einzelne Interna, Fehlerfälle und Betriebskennzahlen offen. Diese Lücken werden nicht mit Annahmen gefüllt.

Für den Prüfpunkt Der Transport: eine gemeinsame SQLite-Datei, kein MCP oder Broker Nummer 1 sind README-Datei, Standardbranch main und veröffentlichte Tags von agmsg maßgeblich. Bei einer lokalen Erprobung sollten Eingabe und Ausgabe getrennt festgehalten werden. Relevant ist ein Test mit dem im Projekt genannten Kommando, der dokumentierten Konfiguration oder dem konkret genannten Pfad. So lässt sich feststellen, ob agmsg den erwarteten Zweck erfüllt und wo die Quelle keine Antwort gibt. Nicht dokumentierte Garantien zu Datenschutz, Sicherheit oder Kompatibilität werden nicht unterstellt.

Installationspfade und Versionsverfolgung

Im Repository fujibee/agmsg steht der Abschnitt Installationspfade und Versionsverfolgung für eine konkrete, im README beschriebene Funktion oder Einordnung. Das README bietet drei Installationswege. Der schnellste gezeigte ist 'npx agmsg', das die kanonische setup.sh ohne globale Installation herunterlädt und ausführt. Ein Claude-Code-Plugin-Marketplace-Pfad installiert ein Skill in den Claude-Plugins-Cache und bootstrappt dann dieselbe Laufzeit unter ~/.agents/skills/agmsg. Ein direktes git clone und install.sh bietet mehr Kontrolle, einschließlich eines benutzerdefinierten Befehlsnamens mit --cmd und eines Agententyp-Flags. Das npm-Paket und das Plugin werden aus getaggten Releases geschnitten, sodass sie main um einige Fixes hinterherhinken können; die Clone- und setup.sh-Pfade verfolgen main direkt. Unter Windows laufen Skripte über Git Bash, und es gibt keine PowerShell-Implementierung. Das README beschreibt keinen Paketmanager für Windows oder einen signierten Installer. Diese Aussage ist als Dokumentationsbefund zu lesen: Sie beschreibt den vorgesehenen Umfang, nicht automatisch eine unabhängige Leistungs- oder Sicherheitsmessung. Für die Einordnung zählt, welche Eingaben, Dateien und Laufzeitbedingungen das Projekt selbst nennt. Bei agmsg ist daher insbesondere zu prüfen, ob Version, Betriebssystem und abhängige Werkzeuge zum eigenen Umfeld passen. Das README zeigt, was Nutzer aufrufen oder konfigurieren können, lässt aber einzelne Interna, Fehlerfälle und Betriebskennzahlen offen. Diese Lücken werden nicht mit Annahmen gefüllt.

Für den Prüfpunkt Installationspfade und Versionsverfolgung Nummer 2 sind README-Datei, Standardbranch main und veröffentlichte Tags von agmsg maßgeblich. Bei einer lokalen Erprobung sollten Eingabe und Ausgabe getrennt festgehalten werden. Relevant ist ein Test mit dem im Projekt genannten Kommando, der dokumentierten Konfiguration oder dem konkret genannten Pfad. So lässt sich feststellen, ob agmsg den erwarteten Zweck erfüllt und wo die Quelle keine Antwort gibt. Nicht dokumentierte Garantien zu Datenschutz, Sicherheit oder Kompatibilität werden nicht unterstellt.

Erster Start und die Befehlsoberfläche

Im Repository fujibee/agmsg steht der Abschnitt Erster Start und die Befehlsoberfläche für eine konkrete, im README beschriebene Funktion oder Einordnung. Nach der Installation führt der Benutzer den Slash-Befehl für seinen Agenten aus, z. B. /agmsg in Claude Code oder $agmsg in Codex. Beim ersten Start werden ein Teamname und ein Agentenname abgefragt. Danach kann der Benutzer den Agenten in natürlicher Sprache anweisen, Nachrichten zu senden, den Posteingang zu prüfen oder Teammitglieder aufzulisten. Das README dokumentiert Unterbefehle für Senden, Verlauf, Teamliste, Modusauswahl, Version und Zurücksetzen. Es dokumentiert auch 'actas' zum Wechseln in eine andere Rolle innerhalb desselben Projekts, 'drop' zum Entfernen einer Rolle, 'spawn' zum Starten eines neuen Agentenprozesses und 'despawn' zum Herunterfahren. Das README weist darauf hin, dass Team- und Agentenname vor dem Senden registriert sein müssen, und send.sh lehnt nicht registrierte Namen ab, es sei denn, --force wird verwendet. Diese Aussage ist als Dokumentationsbefund zu lesen: Sie beschreibt den vorgesehenen Umfang, nicht automatisch eine unabhängige Leistungs- oder Sicherheitsmessung. Für die Einordnung zählt, welche Eingaben, Dateien und Laufzeitbedingungen das Projekt selbst nennt. Bei agmsg ist daher insbesondere zu prüfen, ob Version, Betriebssystem und abhängige Werkzeuge zum eigenen Umfeld passen. Das README zeigt, was Nutzer aufrufen oder konfigurieren können, lässt aber einzelne Interna, Fehlerfälle und Betriebskennzahlen offen. Diese Lücken werden nicht mit Annahmen gefüllt.

Für den Prüfpunkt Erster Start und die Befehlsoberfläche Nummer 3 sind README-Datei, Standardbranch main und veröffentlichte Tags von agmsg maßgeblich. Bei einer lokalen Erprobung sollten Eingabe und Ausgabe getrennt festgehalten werden. Relevant ist ein Test mit dem im Projekt genannten Kommando, der dokumentierten Konfiguration oder dem konkret genannten Pfad. So lässt sich feststellen, ob agmsg den erwarteten Zweck erfüllt und wo die Quelle keine Antwort gibt. Nicht dokumentierte Garantien zu Datenschutz, Sicherheit oder Kompatibilität werden nicht unterstellt.

Rollen, Spawn, Despawn und Sitzungsfortsetzung

Im Repository fujibee/agmsg steht der Abschnitt Rollen, Spawn, Despawn und Sitzungsfortsetzung für eine konkrete, im README beschriebene Funktion oder Einordnung. Der actas-Befehl ist über Sitzungen hinweg exklusiv: Er beansprucht eine Sperre, die verhindert, dass andere Sitzungen denselben Namen abonnieren, und lehnt ab, wenn eine andere Sitzung die Sperre hält. spawn startet einen separaten Agentenprozess in einem neuen tmux-Bereich oder OS-Terminalfenster und kann einen Boot-Prompt übergeben, sodass der neue Agent im selben Zug seine Identität beansprucht und eine Aufgabe startet. spawn blockiert, bis der neue Agent lauscht, sofern nicht --no-wait angegeben ist. despawn entfernt ein gespawntes Mitglied elegant durch Senden einer Steuernachricht oder erzwingt es durch Töten seines Bereichs, wenn der Watcher nicht reagiert. Sitzungen werden nach Team und Agent benannt, und erneutes Spawnen setzt standardmäßig die vorherige Sitzung fort, sofern nicht --fresh verwendet wird. Das README beschreibt auch die tmux-resurrect-Integration zum Wiederherstellen von Rollenbereichen nach einem Serverneustart. Diese Aussage ist als Dokumentationsbefund zu lesen: Sie beschreibt den vorgesehenen Umfang, nicht automatisch eine unabhängige Leistungs- oder Sicherheitsmessung. Für die Einordnung zählt, welche Eingaben, Dateien und Laufzeitbedingungen das Projekt selbst nennt. Bei agmsg ist daher insbesondere zu prüfen, ob Version, Betriebssystem und abhängige Werkzeuge zum eigenen Umfeld passen. Das README zeigt, was Nutzer aufrufen oder konfigurieren können, lässt aber einzelne Interna, Fehlerfälle und Betriebskennzahlen offen. Diese Lücken werden nicht mit Annahmen gefüllt.

Für den Prüfpunkt Rollen, Spawn, Despawn und Sitzungsfortsetzung Nummer 4 sind README-Datei, Standardbranch main und veröffentlichte Tags von agmsg maßgeblich. Bei einer lokalen Erprobung sollten Eingabe und Ausgabe getrennt festgehalten werden. Relevant ist ein Test mit dem im Projekt genannten Kommando, der dokumentierten Konfiguration oder dem konkret genannten Pfad. So lässt sich feststellen, ob agmsg den erwarteten Zweck erfüllt und wo die Quelle keine Antwort gibt. Nicht dokumentierte Garantien zu Datenschutz, Sicherheit oder Kompatibilität werden nicht unterstellt.

Zustellmodi und verhaltensspezifische Agenten

Im Repository fujibee/agmsg steht der Abschnitt Zustellmodi und verhaltensspezifische Agenten für eine konkrete, im README beschriebene Funktion oder Einordnung. Zustellmodi bestimmen, wie eingehende Nachrichten einen Agenten erreichen. Der Monitor-Modus verwendet einen SessionStart-Hook und einen blockierenden SQLite-Stream mit etwa fünf Sekunden Latenz; er ist der Standard bei Claude Code. Der Turn-Modus prüft den Posteingang zwischen Assistenten-Turns und ist der Standard bei Codex, Copilot CLI und OpenCode ohne Plugin. Der Both-Modus verwendet Monitor mit Turn als Fallback. Off deaktiviert die automatische Zustellung. Das README stellt fest, dass Codex kein Monitor-Tool hat, daher läuft der Monitor-Modus über eine App-Server-Brücke, und es gibt eine bekannte Einschränkung mit verwaisten Prozessen beim Schließen der TUI. Copilot CLI unterstützt nur Turn und Off. OpenCode unterstützt Monitor über ein externes Sentinel-Plugin. Das README bietet auch direkte Shell-Skripte für die Automatisierung, wie send.sh, inbox.sh, history.sh und delivery.sh. Diese Aussage ist als Dokumentationsbefund zu lesen: Sie beschreibt den vorgesehenen Umfang, nicht automatisch eine unabhängige Leistungs- oder Sicherheitsmessung. Für die Einordnung zählt, welche Eingaben, Dateien und Laufzeitbedingungen das Projekt selbst nennt. Bei agmsg ist daher insbesondere zu prüfen, ob Version, Betriebssystem und abhängige Werkzeuge zum eigenen Umfeld passen. Das README zeigt, was Nutzer aufrufen oder konfigurieren können, lässt aber einzelne Interna, Fehlerfälle und Betriebskennzahlen offen. Diese Lücken werden nicht mit Annahmen gefüllt.

Für den Prüfpunkt Zustellmodi und verhaltensspezifische Agenten Nummer 5 sind README-Datei, Standardbranch main und veröffentlichte Tags von agmsg maßgeblich. Bei einer lokalen Erprobung sollten Eingabe und Ausgabe getrennt festgehalten werden. Relevant ist ein Test mit dem im Projekt genannten Kommando, der dokumentierten Konfiguration oder dem konkret genannten Pfad. So lässt sich feststellen, ob agmsg den erwarteten Zweck erfüllt und wo die Quelle keine Antwort gibt. Nicht dokumentierte Garantien zu Datenschutz, Sicherheit oder Kompatibilität werden nicht unterstellt.

Speicher, Umgebungsvariablen und Sandbox-Hinweise

Im Repository fujibee/agmsg steht der Abschnitt Speicher, Umgebungsvariablen und Sandbox-Hinweise für eine konkrete, im README beschriebene Funktion oder Einordnung. Der Nachrichtenspeicher ist eine SQLite-Datenbank im WAL-Modus, standardmäßig unter ~/.agents/skills/agmsg/db. Die Umgebungsvariable AGMSGSTORAGEPATH überschreibt diesen Speicherort, und das README zeigt ein Beispiel, das auf /tmp/agmsg-sandbox für isolierte Tests verweist. Teamkonfigurationen liegen unter teams/ und sind von der Speicherüberschreibung nicht betroffen. Das README warnt vor Sandbox-Einschränkungen: Die Sandbox von Claude Code kann das Schreiben in das Skill-Verzeichnis blockieren, daher wird ein Allowlist-Eintrag für ~/.agents/skills/agmsg/ dokumentiert. Codex benötigt möglicherweise writableroots in seiner config.toml für die db- und teams-Verzeichnisse. Das README dokumentiert auch AGMSGPLUGINDIRS für zusätzliche Treiber-Suchpfade. Es beschreibt keinen Backup-Mechanismus, sagt aber, dass Updates die Datenbank bewahren. Diese Aussage ist als Dokumentationsbefund zu lesen: Sie beschreibt den vorgesehenen Umfang, nicht automatisch eine unabhängige Leistungs- oder Sicherheitsmessung. Für die Einordnung zählt, welche Eingaben, Dateien und Laufzeitbedingungen das Projekt selbst nennt. Bei agmsg ist daher insbesondere zu prüfen, ob Version, Betriebssystem und abhängige Werkzeuge zum eigenen Umfeld passen. Das README zeigt, was Nutzer aufrufen oder konfigurieren können, lässt aber einzelne Interna, Fehlerfälle und Betriebskennzahlen offen. Diese Lücken werden nicht mit Annahmen gefüllt.

Für den Prüfpunkt Speicher, Umgebungsvariablen und Sandbox-Hinweise Nummer 6 sind README-Datei, Standardbranch main und veröffentlichte Tags von agmsg maßgeblich. Bei einer lokalen Erprobung sollten Eingabe und Ausgabe getrennt festgehalten werden. Relevant ist ein Test mit dem im Projekt genannten Kommando, der dokumentierten Konfiguration oder dem konkret genannten Pfad. So lässt sich feststellen, ob agmsg den erwarteten Zweck erfüllt und wo die Quelle keine Antwort gibt. Nicht dokumentierte Garantien zu Datenschutz, Sicherheit oder Kompatibilität werden nicht unterstellt.

Redaktionelles Fazit

Geeignet ist agmsg für Leser, deren konkreter Anwendungsfall mit dem README übereinstimmt. Nicht geeignet ist eine Entscheidung allein nach Sternezahl oder Beschreibung. Vor dem Einsatz sollten agmsg, die dokumentierte Version, Eingabe und Ausgabe in der eigenen Umgebung geprüft werden; offene Angaben zu Sicherheit, Kompatibilität und Betrieb bleiben offene Fragen.

Offizielle Quellen

1. Official documentation
2. Official README
3. Project repository
4. Release notes