Verbinde deinen Agent

AWR führt deinen Agent nicht aus. Der Agent-Client (Codex, Claude Code, Kimi, Cursor, Grok) erledigt die Arbeit mit seinen eigenen Werkzeugen; AWR liefert aktuelle Projektfakten, Arbeitskontext, Claims und wiederherstellbares Session-Gedächtnis für dasselbe initialisierte Projekt. Provider- und Modell-Labels in AWR-Session-Aufzeichnungen sind nur Metadaten — sie starten oder konfigurieren den Client niemals.

Jeder unterstützte Client folgt demselben Muster:

Baue beide ausführbaren Dateien aus einem AWR-Checkout:

cargo build --locked -p awr-cli -p awr-mcp

Initialisiere das Zielprojekt aus seinem geprüften Quellenmanifest (siehe Schnellstart), dann registriere den awr-mcp-Server beim Client, wobei --project auf den absoluten Pfad des Projekts zeigt. Jeder Server bindet an einen kanonischen Projektstamm; gib Servern für verschiedene Projekte unterschiedliche Namen.
Verifiziere die Verbindung — eine Konfigurationsdatei auf der Festplatte ist keine aktive Verbindung — und bestätige die Projektidentität mit einem Status-Lesevorgang vor jeder Arbeit.
Arbeite den gemeinsamen Session-Lebenszyklus ab: eine Session starten oder fortsetzen, Kontext lesen, vor der Übergabe checkpointen, beim Aufhören beenden. Siehe CLI und MCP-Tools.

Die folgenden Abschnitte geben Merge-Pfade, Konfiguration und Vorbehalte jedes Clients. Wo ein Client automatische Lebenszyklus-Hooks dokumentiert, behandle sie als unverifiziert, bis du einen echten Trigger und Beleg gesehen hast; der manuelle Checkpoint/Resume-Ablauf funktioniert immer.

Codex

Codex lädt Projektkonfiguration nur für vertrauenswürdige Projekte; seine CLI-, Desktop- und IDE-Clients teilen die MCP-Konfiguration auf demselben Host. Wähle eine von zwei Optionen: Führe die MCP-Konfigurationsvorlage in die .codex/config.toml des Projekts ein (ersetze ihre beiden Pfade, behalte vorhandene Konfiguration), oder registriere auf Benutzerebene:

codex mcp add awr -- /absolute/path/to/awr-mcp \
  --project /absolute/path/to/initialized/project
codex mcp get awr --json

Bestätige in der /mcp-Ansicht des Clients einen verbundenen awr-Server und verifiziere die Projektidentität vor der Arbeit; ein konfigurierter Server ist kein Beweis für eine aktive Verbindung. Erwartete Lesetools: awr_project_status, awr_work_ready, awr_work_get, awr_context_compile, awr_search. Mutationstools: awr_work_transition, awr_event_append, awr_evidence_record. Der Server erfordert keinen Modell-API-Schlüssel.

Codex ist der eine Client mit einem Installer für automatische Lebenszyklus-Hooks: Nutze awr client install, um die exakte Konfiguration vor --accept in der Vorschau zu sehen. Die Installation erhält vorhandene Hooks und genehmigt deren Vertrauen niemals automatisch. Codex dokumentiert SessionStart (startup|resume|clear|compact), PreCompact (manual|auto) und SessionEnd (empfehlend, kurzes Timeout). Verifiziere die tatsächliche Trigger-Zustellung im Client — bis dahin checke vor Übergabe oder Kompaktierung manuell ein.

Claude Code

Claude Code verbindet sich über einen benannten kontrollierten Adapter (Adapter-ID claude_code). Er ist nicht automatisch startbar: AWR wird Claude Code nicht für dich starten und auch nicht eigenständig stoppen — diese Schritte bleiben bei dir. Was der Adapter unterstützt, ist Status lesen, Reconnect/Resume und Ergebnis-Forensik.

Ablauf für den Operator:

Starte Claude Code selbst.
Binde es mit dem generischen Client und der nativen Konversations-ID an AWR:

awrj client bind --client generic --external-session claude:<native-id> \
  --work "$AWR_WORK" --session "$AWR_SESSION"

Wenn du AWR-Beobachtungen brauchst, melde Phasen über den externen Ausführungsbericht der gemeinsamen CLI.
Bei einem erneuten Versuch verbinde dieselbe Ausführungsidentität erneut, bevor du etwas Neues beginnst.

Kimi

Dieser Leitfaden zielt auf Kimi Code 0.41.0 (geprüft 2026-09-08); ältere kimi-cli-Releases verwenden andere Konfigurationspfade und Flags, also prüfe zuerst kimi --version und kimi --help. Nutze Kimis Terminal-Tool, um die AWR-CLI aufzurufen, und verbinde optional dasselbe Projekt über stdio-MCP, indem du diesen Server in die .kimi-code/mcp.json des Projekts einfügst (Benutzerebene: ~/.kimi-code/mcp.json) und andere Einträge beibehältst:

{
  "mcpServers": {
    "awr": { "command": "/absolute/path/to/awr-mcp",
      "args": ["--project", "/absolute/path/to/initialized/project"],
      "cwd": "/absolute/path/to/initialized/project" }
  }
}

Projektkonfiguration erfordert Workspace-Vertrauen. Nutze /mcp-config für die Konfiguration und /mcp, um den Verbindungsstatus einzusehen; Server, die durch Bearbeiten der Konfiguration hinzugefügt wurden, treten neu erstellten Sessions bei. Bestätige die Projektidentität mit awr_project_status. Das Provider-Label für Kimi-Session-Metadaten ist moonshot.

Kimis eigene kimi --continue, kimi --session <kimi-conversation-id> und /compact wirken auf seine Konversation; ihre IDs sind von AWR-IDs getrennt. Kompiliere nach einer Kompaktierung Kontext für dieselbe aktive AWR-Session — ein explizites AWR-Resume ist nur für eine echte Übergabe. Kimi dokumentiert SessionStart-, SessionEnd-, PreCompact- und PostCompact-Hooks, aber diese Integration installiert keinen automatischen Adapter; nutze den manuellen Checkpoint-Prozess.

Cursor

Geprüft gegen Cursor 3.18.9 (2026-09-17). Führe awr client install nicht für Cursor aus (Unsupported), und übergib bei bind nicht --client cursor (InvalidInput) — verwende die unten gezeigte generische Client-Identität. Führe die stdio-Vorlage in die .cursor/mcp.json des Projekts oder die Benutzerdatei ~/.cursor/mcp.json ein:

{
  "mcpServers": {
    "awr": { "type": "stdio", "command": "/absolute/path/to/awr-mcp",
      "args": ["--project", "/absolute/path/to/initialized/project"] }
  }
}

Cursors stdio-Feldtabelle erfordert "type": "stdio" und akzeptiert kein cwd. AWR braucht nur ein absolutes command plus --project. Lade das Fenster neu und prüfe Output → MCP Logs bei Startfehlern; wenn beide Konfigurationsdateien existieren, bestätige in Customize, welche das Agent-Fenster angehängt hat. Zwei Vorbehalte:

Gruppierte Tools. Im aktuellen Quellbaum gibt das Standard-tools/list acht Domänen-Tools zurück (awr_query, awr_context, awr_work, awr_evidence, awr_session, awr_continuity, awr_change, awr_compaction) statt flacher Tool-Namen. Prüfe den Status über awr_query:

{"child_tool": "awr_project_status", "arguments": {}}

Flache Namen bleiben aufrufbar, sind aber nicht im Standardkatalog; setze AWR_MCP_TOOL_EXPOSURE_MODE=flat nur, wenn dein Cursor-Build nicht über Domänen routen kann. Die paketierten Releases stellen das gruppierte awr_query nicht bereit — baue aus dem Quellbaum für diesen Weg und prüfe zuerst den Tool-Katalog deines Builds.

Cloud Agents können ein Laptop-awr-mcp oder 127.0.0.1 nicht erreichen; sie brauchen eine erreichbare HTTPS-Eingangstür mit serverseitigen Projektstämmen. AWRs gemeinsamer HTTP-Dienst nutzt ein Bearer-Token (nicht Cursor OAuth):

{
  "mcpServers": {
    "awr": { "url": "http://127.0.0.1:8080/mcp",
      "headers": { "Authorization": "Bearer ${env:AWR_ENGINEERING_TOKEN}" } }
  }
}

Für die Identität binde den generischen Client mit der nativen Konversations-ID und lasse es fehlschlagen, wenn sie leer ist, damit du niemals das Literal cursor: bindest:

: "${HOST_CONVERSATION_ID:?set the native host conversation ID first}"
AWR_EXTERNAL="cursor:${HOST_CONVERSATION_ID}"
awrj client bind --client generic --external-session "$AWR_EXTERNAL" \
  --work "$AWR_WORK" --session "$AWR_SESSION"

Cursor dokumentiert sessionStart-, sessionEnd- und preCompact-Hooks in .cursor/hooks.json, aber es gibt keinen Installer für diesen Dialekt — checke manuell ein, bis du einen echten Hook-Trigger und einen Checkpoint-Beleg hast.

Grok

Geprüft gegen Grok Build 1.0.13 (2026-09-08). Nutze Groks Terminal-Tool, um die AWR-CLI aufzurufen, oder verbinde seinen stdio-MCP-Client aus dem Projektverzeichnis:

cd /absolute/path/to/initialized/project
grok mcp add --scope project awr -- /absolute/path/to/awr-mcp \
  --project /absolute/path/to/initialized/project
grok mcp doctor awr --json

add --scope project schreibt oder aktualisiert .grok/config.toml (Benutzerbereich ist der Standard, wenn das Flag weggelassen wird); verwende einen eigenen Servernamen, wenn awr bereits auf ein anderes Projekt verweist. Die entsprechende Tabelle ist:

[mcp_servers.awr]
command = "/absolute/path/to/awr-mcp"
args = ["--project", "/absolute/path/to/initialized/project"]

Nutze /mcps in Grok Build, um Verbindungen einzusehen und zu aktualisieren, rufe dann awr_project_status auf und verifiziere die Projektidentität. Projektvertrauen ist eine separate Voraussetzung: Ein nicht vertrauenswürdiger Ordner lässt den Server ungestartet, also prüfe das Projekt zuerst im normalen Vertrauens-Workflow des Clients. Das Provider-Label für Grok-Session-Metadaten ist xai.

Groks native Konversationsfortsetzung ist von der AWR-Session-Wiederherstellung getrennt:

grok --cwd "$AWR_PROJECT" --continue
grok --cwd "$AWR_PROJECT" --resume <grok-conversation-id>

Groks --session-id erstellt eine neue Konversation — es ist weder eine AWR-ID noch ein Resume-Flag. Kompiliere nach nativer Kompaktierung Kontext für dieselbe aktive AWR-Session; nutze den expliziten AWR-Resume-Ablauf nur für eine echte Übergabe.

Grok Build dokumentiert Session- und Kompaktierungsereignisse in seinem Hook-System, aber hier wird kein automatischer Adapter installiert; nutze den manuellen Checkpoint-Prozess, bis du einen tatsächlichen Trigger und Beleg verifiziert hast. Grok Webs benutzerdefinierte Konnektoren erfordern eine erreichbare MCP-URL — ein lokaler ausführbarer Pfad kann nicht als diese URL eingegeben werden; AWRs gemeinsamer HTTP-Dienst kann diese Rolle übernehmen, aber ihn bereitzustellen und die Authentifizierungsanforderungen des Konnektors zu erfüllen ist ein separater Schritt, den dieser Leitfaden nicht verifiziert.

Nächste Schritte

MCP-Tools — die vollständige Tool-Oberfläche, die dein Client nach dem Verbinden aufrufen kann.
Täglicher Workflow — die Start-Arbeit-Checkpoint-Resume-Schleife, egal welchen Client du nutzt.