---
title: "Ältere beeuni.toml"
description: "Supportstatus und Migrationspfad von beeuni.toml v1 zu beeuni.yaml v2."
---

Diese Seite behandelt das v1-Manifest (`beeuni.toml`, `beeuni_version: 1`). Das aktuelle Manifest findest du in der [Manifestreferenz](/docs/de/project/manifest).

<a id="support-status"></a>

## Supportstatus

Beeuni unterstützt weiterhin v1-Manifeste. Die Plattform löst das Manifest eines Projekts in dieser Reihenfolge auf: `beeuni.yaml`, dann `beeuni.yml`, dann `beeuni.toml`. Der aktuelle Starter erstellt ein `beeuni_version: 2` `beeuni.yaml`. Ein v1-Projekt funktioniert ohne erzwungenes Upgrade weiter.

v1 akzeptiert TOML- oder YAML-Syntax. Version 2 akzeptiert nur YAML. Ein v2-Manifest in TOML schlägt bei der Validierung fehl.

<a id="migrate-to-v2"></a>

## Auf v2 migrieren

1. Erstelle `beeuni.yaml` im Stammverzeichnis des Repos. Setze `beeuni_version: 2`.

2. Wandle `[[agents]]` in eine `agents:`-Map mit Agentennamen als Schlüssel um.

3. Benenne das Feld `env` jedes Agents in `secrets` um. Führe alle Secrets auf, die der Agent benötigt – v2 gewährt standardmäßig keine Secrets.

4. Füge `default_agent` hinzu und gib darin den Agenten an, der standardmäßig ausgeführt wird.

5. Lösche `[[channels]]`. Verbinde jeden Channel erneut über das Dashboard.

6. Wenn du `[sandbox]` oder `[[sandboxes]]` verwendest, verschiebe jede Bilddefinition unter `sandbox.templates`.

7. Führe `beeuni validate` für `beeuni.yaml` aus. Behebe alle gemeldeten Fehler.

8. Lösche `beeuni.toml`.

Das Agentenverhalten – System-Prompt, `model`, `mode`, `temperature` und mehr – wird nie verschoben. Es befindet sich bereits in beiden Versionen im Frontmatter der `.md` jedes Agents unter `.beeuni/opencode/agents/`. Siehe [Agents](/docs/de/project/agents).

Prüfe das Ergebnis mit `beeuni validate --file beeuni.yaml`. Rufe das vollständige v2-Schema mit `beeuni schema --version 2` ab. Beide Befehle findest du in der [CLI-Referenz](/docs/de/cli).

<a id="key-differences"></a>

## Wichtigste Unterschiede

| v1 (`beeuni_version: 1`) | v2 (`beeuni_version: 2`) | Änderung |
|---|---|---|
| `[[agents]]` (Array) | `agents:` (Map mit Namen als Schlüssel) | Wandle jedes Array-Element in einen Map-Eintrag um. |
| `[[agents]].env` | `agents.<name>.secrets` | Umbenannt. Der Standardwert ändert sich von `all` zu `none` – siehe den Hinweis unten. |
| `[[agents]].model` | entfernt | In v1 ohne Wirkung (wird geparst, aber nie angewendet). Das Agentenverhalten stammt immer aus dem Frontmatter der `.md` des Agents. |
| `[[agents]].file` | `agents.<name>.file` | In v1 ohne Wirkung (wird geparst, aber nie angewendet). In v2 gibt es die `.md` des Agents an. |
| kein `default_agent` | `default_agent` (erforderlich) | Muss einen deklarierten, aktivierten Agenten angeben. |
| `[[channels]]` | entfernt | Das Channel-Routing wird über das Dashboard verwaltet. Ein verbundener Channel erscheint als `connectors:`-Eintrag mit `provider: channel`. |
| `[sandbox]` (Einzahl, Bildschlüssel direkt darin) | `sandbox.templates` (Liste) | Verschiebe jedes Bild in einen Template-Eintrag. |
| `[[sandboxes]]` | `sandbox.templates` | Umbenannt. |

:::warning[Secrets sind in v2 standardmäßig nicht freigegeben]
  In v1 erhält ein Agent ohne Feld `env` standardmäßig alle Projekt-Secrets. In v2 erhält ein Agent ohne Feld `secrets` keine. Führe bei der Migration alle Secrets auf, die jeder Agent benötigt – verliert ein Agent unbemerkt ein Secret, kann er mitten in einer Aufgabe scheitern.
:::

Einige `beeuni_permissions`-Aktionen werden in v1 aus Kompatibilitätsgründen toleriert (`project.session.exec`, `project.gateway.routing.edit`, `project.schedule.read`, `project.schedule.write`, `project.webhook.read`, `project.webhook.write`, `channel.read`, `channel.connect`, `channel.send`, `channel.disconnect`) – die Plattform warnt davor, erlaubt sie aber. In v2 führen dieselben Aktionen zu einem Fehler. Entferne sie vor der Migration aus der `beeuni_permissions`-Freigabe aller Agents.