Projekteinstellungen

In den Projekteinstellungen konfigurieren Sie die projektbezogenen Standardwerte und Integrationen, die sich auf alle Sandboxes, Workflows und Issue-Sessions auswirken. Die Einstellungsseite ist in Tabs organisiert, von denen jeder einen anderen Aspekt der Projektkonfiguration abdeckt. Der Zugriff auf die Einstellungen erfordert die Rolle Admin oder Eigentümer.

Navigieren Sie zu den Projekteinstellungen über das untere Ende der Seitenleiste (das Schraubenschlüssel-Symbol) oder direkt unter /p/{projectId}/settings.

API-Schlüssel-Konfiguration

CodeCourier benötigt API-Schlüssel für die externen Dienste, mit denen es integriert wird. Schlüssel werden pro Projekt konfiguriert, das heißt unterschiedliche Projekte können unterschiedliche API-Konten verwenden. Alle Schlüssel werden in der Datenbank verschlüsselt gespeichert, und nur die letzten vier Zeichen werden in der UI angezeigt.

Erforderliche Schlüssel

Optionale Schlüssel

System-Prompt-Konfiguration

Der Sandbox-System-Prompt ist ein Standard-Prompt, der in jede Sandbox-Session des Projekts injiziert wird. Er definiert das Basisverhalten aller KI-Agenten, einschließlich Anweisungen für die Arbeit innerhalb der E2B-Sandbox-Umgebung, Präferenzen zur Paketverwaltung, Dateisystem-Konventionen und Git-Workflow-Regeln.

Der Standard-System-Prompt enthält kritische sandbox-spezifische Anweisungen wie:

• Dev-Server an 0.0.0.0 binden, damit sie öffentlich erreichbar sind
• Server im Hintergrund mit nohup starten
• Das Basisverzeichnis /home/user/ verwenden
• Die öffentliche URL aus Sandbox-ID und Port konstruieren
• Git-Commit-Konventionen und Authentifizierungs-Setup

Sie können den System-Prompt anpassen, um projektspezifische Regeln hinzuzufügen, die für alle Sessions gelten sollen, unabhängig davon, welche Persona oder welcher Workflow ausgeführt wird.

CLAUDE.md-Vorlage

Das Feld CLAUDE.md erlaubt es Ihnen, eine Vorlage für die CLAUDE.md-Datei zu definieren, die in jede Sandbox geschrieben wird. Diese Datei stellt projektbezogenen Kontext für den KI- Agenten bereit, einschließlich Architekturentscheidungen, Coding-Standards, Abhängigkeitspräferenzen und anderem Wissen, das über Sessions hinweg bestehen soll.

Betrachten Sie CLAUDE.md als das "institutionelle Wissen" des Projekts, auf das jeder Agent unabhängig von der Aufgabe Zugriff haben sollte.

Issue-Discovery-Prompt

Der Issue-Discovery-Prompt konfiguriert die Standard-Anweisungen, die von Issue-Sessions verwendet werden. Dieser Prompt wird injiziert, wenn ein KI-Agent beginnt, die Codebasis auf Issues zu analysieren. Passen Sie ihn an, um die Issue-Triage-Konventionen Ihres Projekts, Prioritätspräferenzen und Fokusbereiche bei der Discovery widerzuspiegeln.

Umgebungsvariablen

Sie können Umgebungsvariablen definieren, die in jede Sandbox-Session injiziert werden. Diese sind nützlich für Konfigurationswerte, die Ihre Codebasis zur Laufzeit benötigt:

• Schlüssel - Der Name der Umgebungsvariable (z. B. DATABASE_URL)
• Wert - Der Wert der Variable
• Secret-Flag - Ob der Wert in der UI maskiert werden soll

Die Einstellungsseite unterstützt zwei Sätze von Umgebungsvariablen:

• Sandbox-Umgebungsvariablen - In Entwicklungs-Sandbox-Sessions injiziert
• Deploy-Umgebungsvariablen - Werden bei Deployment-Operationen verwendet

Skills und Commands

Die Projekteinstellungen umfassen die Möglichkeit, auszuwählen, welche Skills und Commands projektweit verfügbar sind. Skills sind Pakete mit Domänen- Wissen (Referenzdateien, Best Practices, API-Dokumentationen) und Commands sind wiederverwendbare Prompt- Vorlagen. Wenn Sie sie auf Projektebene auswählen, werden sie für alle Personas und Sessions im Projekt verfügbar.

Sie können auch Scripts auswählen - ausführbare Shell-Skripte, die in Sandbox-Umgebungen für gängige Setup-Aufgaben injiziert werden können.

Learning-Konfiguration

Das Learning-System erfasst Muster, Stolpersteine und Best Practices aus Sandbox-Sessions und stellt sie zukünftigen Runs zur Verfügung. Die Projekteinstellungen steuern:

• Learning-Vorlagen-ID - Die für die Learning-Extraktion verwendete Sandbox-Vorlage
• Learning-Modell - Welches KI-Modell Learnings aus Session-Transkripten extrahiert
• Merging-Vorlagen-ID - Die Vorlage, die für das Mergen von Code-Änderungen aus abgeschlossenen Runs verwendet wird
• Merging-Modell - Welches Modell Merge-Operationen behandelt

Git-Konfiguration

Für Projekte, die Git-Commits und Pull-Requests erstellen, können Sie konfigurieren:

• GitHub-Repository-URL - Das mit diesem Projekt verknüpfte Repository (auf Projektebene festgelegt)
• Git-Commit-Name - Der Autorenname, der bei vom KI-Agenten erstellten Commits verwendet wird
• Git-Commit-E-Mail - Die in Commits verwendete Autoren-E-Mail

Diese Einstellungen stellen sicher, dass alle KI-generierten Commits korrekt zugeordnet werden und den Git-Konventionen Ihres Teams entsprechen.

Convex-Schlüssel

Wenn Ihr Projekt Convex als Backend nutzt (wie CodeCourier selbst), können Sie konfigurieren:

• Convex-Deploy-Key - Wird für das Deployment von Convex-Funktionen aus der Sandbox verwendet
• Convex-Dev-Key - Wird für Convex-Operationen im Entwicklungsmodus verwendet

Diese Schlüssel ermöglichen es dem KI-Agenten, Convex-Backend-Änderungen direkt aus der Sandbox-Umgebung zu deployen und zu testen.

Test-Nutzer-Anmeldedaten

Für Projekte, die authentifiziertes Testen erfordern, können Sie Test-Nutzer-Anmeldedaten hinterlegen:

• E-Mail - E-Mail-Adresse des Testkontos
• Passwort - Passwort des Testkontos

Diese Anmeldedaten werden Sandbox-Sessions für automatisiertes End-to-End-Testing zur Verfügung gestellt, sodass Agenten sich in die Anwendung einloggen und authentifizierte Funktionen testen können.

Session-Konfigurationen

Neben den globalen Projektstandards bietet CodeCourier dedizierte Setup-Tabs für jeden der sechs Session-Typen, die die KI-Workflow-Pipeline antreiben. In jedem Setup-Tab können Sie das CLI-Tool, das Modell, den Thinking-Effort, das verknüpfte Kontextdokument und die ausgewählten Assets (Skills, Commands und Scripts) für diesen spezifischen Session-Typ konfigurieren. Änderungen an einem Session-Typ-Setup gelten für alle neuen Sessions dieses Typs projektweit, sofern sie nicht von einer Persona überschrieben werden.

Answering-Setup

Erreichbar unter /p/{id}/answering-setup. Konfiguriert den Answering-Agent - den Session-Typ, der auf natürlichsprachliche Fragen zur Codebasis und zum Projekt antwortet. Felder:

• CLI-Tool - Welcher Coding-Agent-CLI verwendet werden soll (Claude Code, OpenCode, Codex)
• Modell - Das spezifische LLM-Modell für Answering-Sessions
• Thinking-Effort - Tiefe der Argumentation (keine, niedrig, mittel, hoch, max)
• Kontext - Das Kontextdokument, das standardmäßig in Answering-Sessions injiziert wird
• Skills, Commands, Scripts - Standard-Assets für Answering-Sessions

Issues-Setup

Erreichbar unter /p/{id}/issues-setup. Konfiguriert den Issue-Discovery-Agent - den Session-Typ, der die Codebasis scannt und eine strukturierte Liste von Issues, Bugs und Verbesserungsmöglichkeiten erstellt. Felder:

• CLI-Tool - Welcher Coding-Agent-CLI verwendet werden soll
• Modell - Das spezifische LLM-Modell für Issue-Discovery-Sessions
• Thinking-Effort - Tiefe der Argumentation
• Kontext - Das Kontextdokument, das standardmäßig in Issue-Discovery-Sessions injiziert wird
• Skills, Commands, Scripts - Standard-Assets für Issue-Discovery-Sessions

Learning-Setup

Erreichbar unter /p/{id}/learning-setup. Konfiguriert den Learning-Extraktions-Agent - den Session-Typ, der abgeschlossene Session-Transkripte liest und strukturierte Learning-Datensätze daraus extrahiert. Felder:

• CLI-Tool - Welcher Coding-Agent-CLI verwendet werden soll
• Modell - Das spezifische LLM-Modell für die Learning-Extraktion
• Thinking-Effort - Tiefe der Argumentation
• Kontext - Das Kontextdokument, das standardmäßig in Learning-Sessions injiziert wird
• Skills, Commands, Scripts - Standard-Assets für Learning-Sessions

Merging-Setup

Erreichbar unter /p/{id}/merging-setup. Konfiguriert den Merge-Agent - den Session-Typ, der für das Mergen von Code-Änderungen aus abgeschlossenen Workflow-Runs zurück in den Hauptbranch verantwortlich ist. Felder:

• CLI-Tool - Welcher Coding-Agent-CLI verwendet werden soll
• Modell - Das spezifische LLM-Modell für Merge-Operationen
• Thinking-Effort - Tiefe der Argumentation (höherer Effort hilft beim Lösen komplexer Merge-Konflikte)
• Kontext - Das Kontextdokument, das standardmäßig in Merging-Sessions injiziert wird
• Skills, Commands, Scripts - Standard-Assets für Merging-Sessions

Evaluator-Setup

Erreichbar unter /p/{id}/evaluator-setup. Konfiguriert den Quality-Evaluator - einen Session-Typ, der die Agenten-Ausgabe gegen definierte Qualitätskriterien bewertet und benotet. Der Evaluator wird verwendet, wenn Sie eine quantitative Qualitätsmessung statt eines binären Pass-/Fail-Verdikts wünschen. Felder:

• CLI-Tool - Welcher Coding-Agent-CLI verwendet werden soll
• Modell - Das spezifische LLM-Modell für Evaluations-Sessions
• Thinking-Effort - Tiefe der Argumentation
• Kontext - Das Kontextdokument, das standardmäßig in Evaluator-Sessions injiziert wird
• Skills, Commands, Scripts - Standard-Assets für Evaluator-Sessions

Judge-Setup

Erreichbar unter /p/{id}/judge-setup. Konfiguriert den Output-Judge - einen Session-Typ, der mehrere Agenten-Ausgaben nebeneinander vergleicht und die beste auswählt. Der Judge wird in Evaluations-Pipelines verwendet, in denen mehrere Lösungsvarianten erzeugt werden und Sie eine automatisierte Auswahl des Gewinners wünschen. Felder:

• CLI-Tool - Welcher Coding-Agent-CLI verwendet werden soll
• Modell - Das spezifische LLM-Modell für Judge-Sessions
• Thinking-Effort - Tiefe der Argumentation (hoher Effort empfohlen für nuancierte Vergleiche)
• Kontext - Das Kontextdokument, das standardmäßig in Judge-Sessions injiziert wird
• Skills, Commands, Scripts - Standard-Assets für Judge-Sessions

Weitere Felder der Projekteinstellungen

Die folgenden Einstellungen sind im Schema der Projekteinstellungen verfügbar, werden aber in den vorherigen Abschnitten nicht behandelt. Sie steuern Deployment, Testing, Lebenszyklus und fortgeschrittene Infrastruktur-Verhaltensweisen.

Deploy-Umgebungsvariablen

Zusätzlich zu den Sandbox-Umgebungsvariablen (die in Entwicklungs-Sessions verwendet werden) können Sie einen separaten Satz von Deploy-Umgebungsvariablen für Deployment- und Produktionskontexte definieren. Diese werden verschlüsselt gespeichert und nur in Sessions injiziert, die Deploy-Operationen durchführen - sie sind in normalen Sandbox-Sessions nicht sichtbar.

Verwenden Sie Deploy-Umgebungsvariablen für Produktions-API-Schlüssel, Produktions-Datenbank-URLs, CDN-Token und andere Anmeldedaten, die niemals in Entwicklungs-Sandboxes vorhanden sein sollten. Das Schlüssel/Wert- Format ist identisch mit Sandbox-Umgebungsvariablen, einschließlich derselben Secret-Masking-Unterstützung.

Test-Nutzer-Anmeldedaten

Für Projekte, die authentifiziertes End-to-End-Testing erfordern, können Sie Test-Nutzer-Anmeldedaten in den Projekteinstellungen hinterlegen. Diese werden Sandbox-Sessions zur Verfügung gestellt, damit Agenten sich als Testnutzer in die Anwendung einloggen und authentifizierte Funktionen testen können.

• E-Mail - E-Mail-Adresse des Testkontos
• Passwort - Passwort des Testkontos (verschlüsselt gespeichert)

Die Anmeldedaten werden als Umgebungsvariablen in die Sandbox injiziert, sodass Agenten und Testskripte sie referenzieren können, ohne dass sie irgendwo hartcodiert sind.

PR-Vorlage

Das Feld PR-Vorlage akzeptiert eine Markdown-Vorlage, die verwendet wird, wenn Agenten Pull-Requests aus Workflow-Runs erstellen. Die Vorlage folgt demselben Format wie eine GitHub.github/pull_request_template.md-Datei. Wenn ein Agent einen Pull-Request öffnet, wird diese Vorlage als PR-Body verwendet, vorab gefüllt mit dem relevanten Kontext aus dem Workflow-Run (Issue-Titel, Prompt-Zusammenfassung, Checklisten-Einträge).

## Summary
<!-- Describe what this PR does and why -->

## Changes
<!-- List the key files and components changed -->

## Testing
- [ ] Unit tests added or updated
- [ ] Build passes (`bun run build`)
- [ ] Lint clean (`bun run lint`)
- [ ] E2E tests pass (if applicable)

## Related Issues
<!-- Link to the issue or task this PR resolves -->

Convex-Deploy-Key

Der Convex-Deploy-Key wird von Agenten verwendet, um Convex-Funktionen aus einer Sandbox zu deployen. Wenn gesetzt, können Agenten npx convex deploy innerhalb der Sandbox ausführen, und der Schlüssel authentifiziert das Deployment zu Ihrem Convex-Projekt. Dies ermöglicht vollständig automatisierte End-to-End-Workflows, in denen der Agent Backend-Code schreibt und in einer einzigen Session deployt.

Erzeugen Sie einen Deploy-Key aus dem Convex-Dashboard unter den Deployment-Einstellungen Ihres Projekts. Deploy-Keys sind auf ein bestimmtes Convex-Deployment beschränkt und sollten die minimal erforderlichen Berechtigungen nutzen.

Convex-Dev-Key

Der Convex-Dev-Key wird verwendet, um aus Sandboxes heraus im Entwicklungsmodus auf Convex zuzugreifen. Anders als der Deploy-Key (der Produktions-Deployments adressiert) verbindet sich der Dev-Key mit Ihrem Convex-Entwicklungs-Deployment, sodass Agenten in Entwicklungs-Sessions Daten in der Dev-Datenbank lesen und schreiben können.

Auto-Pause

Der Schalter Auto-Pause steuert, ob inaktive Sandboxes im Projekt nach einer Phase der Inaktivität automatisch pausiert werden. Wenn aktiviert, wird eine Sandbox, die für einen konfigurierbaren Zeitraum weder Nutzereingaben empfangen noch neue Ausgaben erzeugt hat, automatisch suspendiert, um Ressourcen zu sparen.

Pausierte Sandboxes bewahren ihren Dateisystem-Zustand und können wieder aufgenommen werden. Auto-Pause ist für Projekte empfohlen, in denen Sandbox-Sessions häufig versehentlich laufen gelassen werden, da es Kosten durch nicht genutzte E2B-Sandboxes verhindert.

Max. Pause-Dauer

Das Feld Max. Pause-Dauer legt fest, wie lange eine pausierte Sandbox aufbewahrt wird, bevor sie endgültig beendet wird. Sobald eine Sandbox länger als diese Dauer pausiert ist, wird sie automatisch beendet und ihr Zustand verworfen. Gültige Werte reichen je nach Tarif von Minuten bis Stunden.

Eine kürzere maximale Pause-Dauer reduziert Kosten, da vergessene Sandboxes früher beendet werden. Eine längere Dauer gibt Teammitgliedern mehr Zeit, zu einer pausierten Sandbox zurückzukehren und die Arbeit fortzusetzen. Der richtige Wert hängt von den Arbeitsmustern Ihres Teams ab.

Projekt-Logo

Sie können ein benutzerdefiniertes Logo für das Projekt hochladen. Das Logo wird in der Projektleiste der Seitenleiste angezeigt und hilft, Projekte visuell zu unterscheiden, wenn Sie Mitglied mehrerer Teams sind. Wenn kein Logo hochgeladen wird, zeigt das Projekt ein farbiges Initial-Badge, das aus dem Projektnamen abgeleitet wird.

Nächste Schritte