---
title: "Sitzungen"
description: "Eine Sitzung ist ein Git-Branch und eine Sandbox, in der der Agent arbeitet."
---

Eine Sitzung ist eine Einheit der Agentenarbeit. Beeuni erstellt dafür einen Git-Branch und richtet eine Sandbox ein. Die Sitzungs-ID, der Branch-Name und die Sandbox-ID haben denselben Wert.

## Status

Eine Sitzung erreicht in der Praxis einen von 4 Zuständen.

| Status | Bedeutung |
|---|---|
| `provisioning` | Beeuni erstellt den Branch und fordert die Sandbox an. |
| `running` | Die Sandbox ist aktiv und erreichbar. |
| `stopped` | Die Sitzung wurde von dir oder durch automatisches Stoppen wegen Inaktivität pausiert. |
| `failed` | Die Bereitstellung ist fehlgeschlagen. |

Die Datenbank definiert 3 weitere Werte (`queued`, `branching`, `completed`). Beeuni schreibt sie derzeit nicht für eine Sitzung.

<a id="stop-resume-and-idle-auto-stop"></a>

## Stoppen, Fortsetzen und automatisches Stoppen wegen Inaktivität

Du kannst eine Sitzung selbst stoppen. Beim Fortsetzen wird dieselbe Sandbox mit demselben Dateisystem und derselben Laufzeitidentität wiederhergestellt. Nur die laufenden Prozesse und der Arbeitsspeicher werden zurückgesetzt. Die Standard-Harness-Unterhaltung bleibt mit der Sitzung verknüpft.

Beeuni stoppt eine inaktive Sitzung außerdem automatisch für dich:

- Nach 15 Minuten Inaktivität bei einer normalen Sitzung oder einem Trigger-Lauf.
- Nach 2 Minuten Inaktivität bei einer Worker-Sitzung, die von einer anderen Sitzung gestartet wurde.

Ein beschäftigter Agenten-Durchlauf verhindert das Stoppen. Die Wartungsprüfung läuft alle 5 Minuten. Ein normales automatisches Stoppen erfolgt daher ungefähr 15 bis 20 Minuten nach dem letzten Terminal-Durchlauf.

Ein Durchlauf, der auf eine Person wartet, führt keine Arbeit aus: Der Agent hat eine Frage gestellt oder bittet um Erlaubnis, ein Tool auszuführen. Ein solcher Durchlauf behält den Computer höchstens 2 Stunden, nachdem Beeuni das Warten erstmals erkannt hat. Bei einem Trigger- oder Zeitplan-Lauf erhält niemand die Anfrage, und das Limit beträgt 30 Minuten. Danach beendet Beeuni den Durchlauf und stoppt den Computer. Sende eine Nachricht, um fortzufahren. Ein Modellaufruf oder deine geöffnete Sitzungsseite zählt als Aktivität und verlängert die Nutzung des Computers wie gewohnt.

Eine von dir verwendete Sitzungsseite hält die Sitzung aktiv. Sie zählt als in Verwendung, solange der Tab sichtbar ist und du in den letzten 10 Minuten geklickt, getippt, gescrollt oder ihn berührt hast, und nur, wenn du Sitzungen im Projekt starten darfst. Ein geöffneter Tab ohne Eingaben wird nach 10 Minuten nicht mehr gezählt, sodass die Sitzung etwa 15 bis 20 Minuten später stoppt. Der geöffnete Tab eines Nur-Lese-Viewers hält die Sitzung nie aktiv. Die alleinige Verwendung der Seite hält eine Sitzung höchstens 2 Stunden nach ihrem letzten Agenten-Durchlauf aktiv; eine neue Nachricht startet einen Durchlauf und setzt dieses Limit zurück.


<a id="what-stop-and-delete-keep"></a>

## Was beim Stoppen und Löschen erhalten bleibt

:::warning[Löschen ist dauerhaft]
Das Löschen einer Sitzung zerstört ihre Sandbox dauerhaft. Beeuni behält den Sitzungseintrag und den Git-Branch, sodass du übertragene Arbeit weiterhin wiederherstellen kannst. Alles, was nicht übertragen wurde, ist verloren.
:::

Stoppen und Fortsetzen erhalten die Identität und das Dateisystem der Sandbox. Löschen zerstört die Sandbox. Git ist der einzige dauerhafte Datensatz: Arbeit, die der Agent committet und überträgt, bleibt erhalten; alles andere nicht.

## Labels

Ein Label klassifiziert eine Sitzung: `bug`, `customer: eu`, `worker`. Öffne das `⋯`-Menü einer Sitzung und wähle **Labels bearbeiten**. Der Filter **Labels** in der Sitzungsliste zeigt nur Sitzungen an, die jedes von dir ausgewählte Label tragen. Labels sind frei definierbar, 1–64 Zeichen lang und auf höchstens 20 pro Sitzung begrenzt.

Auch Agents und Skripte setzen Labels: `beeuni sessions new --label worker`, `beeuni sessions update --label needs-review` (innerhalb einer Sitzung, ohne ID, wird diese Sitzung mit einem Label versehen) oder `labels` in der API und im SDK. Eine Sitzung enthält außerdem ein frei definierbares `metadata`-Objekt für deine eigenen Schlüssel – siehe SDK-Sitzungen.

<a id="runtime"></a>

## Laufzeit

Eine Sitzung führt ein Harness aus, Standard-Harness oder Experimental-Harness. Siehe [Harnesses](/docs/de/work/harnesses). Beeuni speichert den ausgewählten Agenten und das Modell, wenn die Sitzung gestartet wird. Eine laufende Sitzung behält ihr Harness, bis sie neu gestartet oder fortgesetzt wird.

<a id="session-access"></a>

## Sitzungszugriff

Eine Sitzung ist für die Person privat, die sie erstellt hat. Der Eigentümer öffnet **Sitzungszugriff** und wählt eine von 3 Optionen.

| Option | Wer die Sitzung öffnen kann |
|---|---|
| Nur du | Nur der Eigentümer. Dies ist die Standardeinstellung. |
| Bestimmte Personen | Der Eigentümer sowie die vom Eigentümer ausgewählten Mitglieder und Gruppen. |
| Gesamtes Projekt | Jedes Mitglied des Projekts. |

Alle Personen mit Zugriff können die Unterhaltung lesen und fortsetzen.

**Eine geteilte Sitzung läuft mit gemeinsam genutzten Schlüsseln.** Sobald eine Sitzung geteilt wurde, verwendet sie ausschließlich Anbieter-Schlüssel, die mit dem gesamten Projekt geteilt sind, niemals die eigenen Schlüssel einer Person oder deren ChatGPT-Verbindung. Wenn ihr Modell mit deinen eigenen Schlüsseln lief, wird es durch das Teilen auf die Projektschlüssel dieses Anbieters umgestellt. Wenn das Projekt keinen Schlüssel teilt, mit dem das Modell ausgeführt werden kann, wird das Teilen abgelehnt und die Sitzung bleibt privat. Siehe [Anbieter-Schlüssel und Mitgliederzugriff](/docs/de/project/models#provider-keys-and-member-access).

**Nur der Eigentümer kann dies ändern.** Ein Projektmanager, der die Sitzung nicht erstellt hat, kann sie öffnen, sobald sie mit ihm geteilt wurde, und sie stoppen, neu starten oder löschen. Er kann nicht festlegen, wer sie sonst noch öffnen darf. Das Teilen einer Sitzung mit einem Manager bedeutet nicht, dass ihm die Zugriffsliste übergeben wird.

Eine Art von Sitzung hat keinen menschlichen Eigentümer: Sitzungen, die von einem Trigger erstellt werden und unter der Identität des Trigger-Agenten laufen. Projektmanager verwalten diese. Lege die Richtlinie für alle diese Sitzungen direkt am Trigger fest, unter **Sitzungszugriff** beim Trigger – das Speichern dort aktualisiert auch die Sitzungen, die dieser Trigger bereits erstellt hat.

<a id="admins-can-open-every-session"></a>

### Administratoren können jede Sitzung öffnen

Ein Kontoinhaber kann Kontoinhabern und Administratoren erlauben, **jede** Sitzung im Konto zu öffnen, einschließlich Sitzungen, die Mitglieder privat halten. Aktiviere dies unter **Konto → Einstellungen → Sicherheit → Administratoren können jede Sitzung öffnen**. Standardmäßig ist diese Option deaktiviert.

- **Nur ein Kontoinhaber kann dies ändern.** Ein Administrator sieht den Schalter, kann ihn aber nicht umlegen. Kein Administrator kann sich also selbst Zugriff auf die Arbeit aller gewähren.
- **Administratoren finden diese Sitzungen auf der Sitzungsseite des Projekts.** In der Seitenleiste werden weiterhin nur Sitzungen aufgeführt, die du gestartet hast oder die mit dir geteilt wurden.
- **Der Zugriff ist vollständig.** Ein Administrator kann die Sitzung öffnen, lesen und fortsetzen – genauso wie bei einer Sitzung, die mit dem gesamten Projekt geteilt wurde.
- **Mitglieder sehen dies.** Solange die Option aktiviert ist, weist der Dialog „Sitzungszugriff“ darauf hin, dass Eigentümer und Administratoren jede Sitzung öffnen können.
- **Alles wird protokolliert.** Jede Änderung wird als `iam.session_oversight.enable` oder `iam.session_oversight.disable` aufgezeichnet, und jede Sitzung, die ein Administrator darüber öffnet, als `project.admin_oversight_session_read` (höchstens einmal pro Administrator und Sitzung je Stunde).
- Agenten- und Sandbox-Tokens erhalten diesen Zugriff niemals, auch wenn sie von einem Administrator gestartet wurden.

<a id="find-a-session-by-owner-or-access"></a>

### Eine Sitzung nach Eigentümer oder Zugriff finden

Die **Sitzungsseite** des Projekts zeigt in jeder Sitzungszeile den Eigentümer und den Zugriff: den Avatar und Namen des Eigentümers (**Du** für deine eigenen Sitzungen), gefolgt von einem Symbol dafür, wer sie öffnen kann: ein Schloss für **Nur der Eigentümer**, Personen für **Bestimmte Personen** und ein Globus für **Gesamtes Projekt**.

Öffne auf der Sitzungsseite **Filter**, um die Liste einzugrenzen:

- **Eigentümer** – ein Eintrag pro Person mit einer Anzahl.
- **Zugriff** – Nur der Eigentümer, Bestimmte Personen oder Gesamtes Projekt.
- **Gruppierung → Eigentümer** – ein Abschnitt pro Person, deine Sitzungen zuerst.

Die Filter lassen sich mit **Status**, **Quelle** und der Suche kombinieren. **Zurücksetzen** löscht alle Filter.

:::warning[Eine Sitzung behält ihren Eigentümer]
Wenn jemand aus dem Konto entfernt wird, werden seine Sitzungen nicht auf eine andere Person übertragen. Die Zugriffsrichtlinie bleibt unverändert. Ein Projektmanager kann diese Sitzungen weiterhin stoppen oder löschen – Löschen ist die Möglichkeit, den Zugriff auf eine Sitzung zu entziehen, die niemand mehr besitzt.
:::

<a id="sharing-a-preview"></a>

## Eine Vorschau teilen

Du kannst die Live-Vorschau einer Sitzung über einen öffentlichen Link im Nur-Lese- oder interaktiven Modus teilen. Das Erstellen dieses Links obliegt dem Eigentümer der Sitzung, aus demselben Grund: Der Link ist nicht authentifiziert, sodass jeder, der die URL besitzt, die Sitzung lesen kann, ohne sich anzumelden. Ein Projektmanager kann die Links einer Sitzung auflisten und widerrufen, ohne ihr Eigentümer zu sein – durch das Widerrufen wird ausschließlich Zugriff entfernt.

Die vollständige Status-Enumeration, injizierte Umgebungsvariablen und Daemon-Endpunkte findest du unter [Laufzeit](/docs/de/work/runtime). Wie eine Sitzung ihren Agenten auswählt, findest du unter [Agents](/docs/de/project/agents). Sitzungen, die durch einen Zeitplan oder Webhook gestartet werden, findest du unter [Trigger](/docs/de/connect/triggers). Wie du Sitzungsarbeit in den Standard-Branch übernimmst, findest du unter [Änderungsanfragen](/docs/de/work/change-requests).
