> ## Documentation Index
> Fetch the complete documentation index at: https://docs.base44.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Base44 in der Cloud-Sandbox

> Erstelle Base44-App-Code innerhalb der Base44-Cloud-Sandbox mit deinem eigenen Coding-Agenten. Es gibt keinen lokalen Checkout: Du liest, schreibst und führst Dateien über die Sandbox-Tools aus (über MCP oder die base44 sandbox...

<Warning>
  Diese Seite ist Teil eines KI-Coding-Agent-Skills und für Agenten geschrieben, nicht für Menschen. Für die menschenlesbare Base44-Dokumentation siehe die [Entwicklerdokumentation](/developers).
</Warning>

# Base44 in der Cloud-Sandbox

Erstelle Base44-App-Code **innerhalb der Base44-Cloud-Sandbox** mit deinem eigenen Coding-Agenten. Es gibt keinen lokalen Checkout: Du liest, schreibst und führst Dateien über die Sandbox-Tools aus (über MCP oder die `base44 sandbox`-CLI), und die Plattform baut und deployt aus dem, was du schreibst.

Für **wie du dich verbindest** zur Sandbox (MCP-Endpunkt oder die `base44 sandbox`-CLI, die Tools `read_file` / `write_file` / `edit_file` / `run_command` / `grep` / `list_directory` / `create_checkpoint` — die die CLI unter kürzeren Namen bereitstellt (`sandbox read` / `sandbox write` / `sandbox edit` / `sandbox run` / `sandbox grep` / `sandbox ls` / `sandbox checkpoint`), die Edit→Preview→Verify-Schleife, Persistenz und Konkurrenz), verwende den Skill **`base44-remote-dev`**. Dieser Skill behandelt **was du erstellen kannst und wie**, sobald du verbunden bist.

> **Prüfe diese Referenzen zuerst.** Dieser Skill und seine Geschwister (`base44-remote-dev`, `base44-sdk`) sind die Quelle der Wahrheit — konsultiere sie, bevor du im Web suchst. Siehe [Referenzreihenfolge und die vollständige README](#referenzreihenfolge-und-die-vollständige-readme).

## ⚡ Das mentale Modell: Die Datei zu schreiben *ist* das Deploy

Du arbeitest an einer **Remote**-App, nicht an einem lokalen Checkout. Der projektebene CLI-Workflow gilt **nicht** — führe nie `base44 deploy`, `base44 functions deploy`, `base44 ... push`, `base44 create` oder `base44 scaffold` aus. Sie setzen ein lokales Projekt und einen manuellen Deploy-Schritt voraus, den es hier nicht gibt.

Stattdessen: **Sobald du eine Ressourcen-Datei in die Sandbox schreibst — eine Backend-Funktion, eine Entität oder einen Agenten — deployt/synct die Plattform sie von dort aus.** Dein Schreibvorgang wird automatisch commitet (\~5s Entprellung) und geht live. Du führst kein `deploy`/`push`-Kommando aus und musst nicht darauf warten.

**Eine Ausnahme — Connectors.** OAuth-Connectors werden nicht als Dateien erstellt; sie werden gegen die Remote-App über deren ID eingerichtet, entweder mit den MCP-Connector-Tools oder mit den dedizierten, projektlosen `base44 connectors`-Befehlen (die `--app-id` nehmen und kein lokales Projekt brauchen). Siehe [Connectors](#connectors-oauth-integrationen) unten.

Du kannst weiterhin `run_command` (`sandbox run` in der CLI) für gewöhnliche Prüfungen verwenden (z. B. `npm run build`, `npx tsc --noEmit`, `npm run lint`) und für die Preview — das ist Verifizierung, kein Deployment. Siehe die Edit→Preview→Verify-Schleife in `base44-remote-dev`.

## Was du heute erstellen kannst

| Ressource                                    | Status in der Sandbox                                                                                                           |
| -------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- |
| **Backend-Funktionen** (`base44/functions/`) | ✅ Unterstützt — schreibe die Dateien; sie deployen aus der Sandbox.                                                             |
| **Entitäten** (`base44/entities/`)           | ✅ Unterstützt — schreibe die `.jsonc`-Schema-Datei; sie synct automatisch. Kein `entities push`.                                |
| **Agenten** (`base44/agents/`)               | ✅ Unterstützt — schreibe die `.jsonc`-Config-Datei; sie synct automatisch. Kein `agents push`.                                  |
| **Frontend-Code** (`src/…`)                  | ✅ Unterstützt — bearbeite normal; HMR/Preview spiegelt es. Verwende den **`base44-sdk`**-Skill für SDK-API-Nutzung.             |
| **Connectors** (OAuth-Integrationen)         | ✅ Unterstützt — richte über den Connect-Flow unten ein (MCP-Tools oder `base44 connectors`), **nicht** durch Dateien schreiben. |

## Backend-Funktionen

Backend-Funktionen liegen in `base44/functions/`, ein Verzeichnis pro Funktion (kebab-case-Name). In der Sandbox musst du nur die **`entry.ts`**-Datei direkt unter `base44/functions/<name>/` erstellen — **keine `function.jsonc` nötig** (die Sandbox leitet die Funktion aus dem Verzeichnis ab; die Config-Datei wird in diesem Modus ignoriert):

```
base44/functions/
  process-order/
    entry.ts
```

Entry-Datei — Funktionen laufen auf **Deno** (nicht Node.js), exportieren mit `Deno.serve()` und verwenden das `npm:`-Präfix für npm-Pakete:

```typescript theme={null}
import { createClientFromRequest } from "npm:@base44/sdk";

Deno.serve(async (req) => {
  const base44 = createClientFromRequest(req);   // inherits the caller's auth
  const { orderId } = await req.json();
  const order = await base44.entities.Orders.get(orderId);
  return Response.json({ success: true, order });
});
```

Konventionen:

* **Kebab-case**-Verzeichnis und Funktionsname; Entry normalerweise `entry.ts`.
* `createClientFromRequest(req)` für einen Client im Auth-Kontext des Aufrufers; `base44.asServiceRole.…` für Admin-Operationen.
* Lies Secrets mit `Deno.env.get("KEY")` (in den App-Einstellungen konfiguriert).
* Gib mit `Response.json(body, { status })` zurück; behandle Fehler und setze passende Statuscodes.

Das reicht, um Funktionen korrekt zu erstellen. Für tiefere Details und mehr Beispiele (Service-Rolle, Secrets, häufige Fehler) siehe die Referenz im `base44-cli`-Skill: [`functions-create.md`](https://docs.base44.com/developers/skills/base44-sandbox/../base44-cli/references/functions-create.md) — aber **ignoriere ihre "Deploying Functions"/CLI-Abschnitte** und ihre **`function.jsonc`**-Anleitung, die ein lokales Projekt voraussetzen und in der Sandbox nicht gelten (hier schreibst du nur `entry.ts`).

> **Aufruf der Funktion vom Frontend:** `base44.functions.invoke(name, data)` gibt die **rohe axios-Antwort** zurück — das JSON deiner Funktion liegt auf **`.data`** (`const result = res.data`), nicht auf dem Top-Level-Objekt, und es **wirft bei Non-2xx** (Fehler-Body bei `err.response.data`). Siehe die [`functions.md`](https://docs.base44.com/developers/skills/base44-sandbox/../base44-sdk/references/functions.md) im `base44-sdk`-Skill für Details.

## Entitäten

Eine `.jsonc`-Datei pro Entität in `base44/entities/`. Schreibe einfach die Datei — sie synct automatisch; **führe kein `base44 entities push` oder `deploy` aus.**

* **Dateiname:** `{kebab-case}.jsonc` — z. B. `team-member.jsonc` für eine Entität namens `TeamMember`.
* **Entitäts-`name`:** PascalCase, nur alphanumerisch (`/^[a-zA-Z0-9]+$/`).
* **Feldnamen:** `snake_case`.

```jsonc theme={null}
// base44/entities/task.jsonc
{
  "name": "Task",
  "type": "object",
  "properties": {
    "title": { "type": "string", "description": "Task title" },
    "status": { "type": "string", "enum": ["todo", "doing", "done"], "default": "todo" },
    "due_date": { "type": "string", "format": "date" },
    "board_id": { "type": "string", "description": "Owning board" }
  },
  "required": ["title"]
}
```

Feldtypen: `string`, `number`, `integer`, `boolean`, `array`, `object`, `binary`. String-Formate umfassen `date`, `date-time`, `email`, `uri`, `uuid`, `file`, `richtext`. Für vollständige Schema-Details und Row-Level Security (RLS) siehe die `base44-cli`-Referenzen [`entities-create.md`](https://docs.base44.com/developers/skills/base44-sandbox/../base44-cli/references/entities-create.md) und [`rls-examples.md`](https://docs.base44.com/developers/skills/base44-sandbox/../base44-cli/references/rls-examples.md) — aber **ignoriere ihre `entities push`/Deploy-Abschnitte**; die Sandbox synct die Datei für dich.

## Agenten

Eine `.jsonc`-Datei pro Agent in `base44/agents/`. Schreibe einfach die Datei — sie synct automatisch; **führe kein `base44 agents push` oder `deploy` aus.**

* **Dateiname:** `{agent_name}.jsonc` — z. B. `support_agent.jsonc`.
* **Agenten-`name`:** `/^[a-z0-9_]+$/` (kleingeschrieben, Unterstriche, 1–100 Zeichen).

```jsonc theme={null}
// base44/agents/support_agent.jsonc
{
  "name": "support_agent",
  "description": "Brief description of what this agent does",
  "instructions": "Detailed instructions for the agent's behavior",
  "tool_configs": [
    { "entity_name": "tasks", "allowed_operations": ["read", "create", "update", "delete"] },
    { "function_name": "send_email", "description": "Send an email notification" }
  ],
  "whatsapp_greeting": "Hello! How can I help you today?"
}
```

Erforderlich: `name`, `description`, `instructions`. Optional: `tool_configs` (Standard `[]`), `whatsapp_greeting`. Tool-Configs sind entweder ein **Entity-Tool** (`entity_name` + `allowed_operations`: eines von `read`/`create`/`update`/`delete`) oder ein **Backend-Function-Tool** (`function_name` + `description`). Für das vollständige Agenten-Schema siehe den Abschnitt **Agent Schema** in der [`SKILL.md`](https://docs.base44.com/developers/skills/base44-sandbox/../base44-cli/SKILL.md) des `base44-cli`-Skills — aber **ignoriere ihre `agents push`/`agents pull`/Deploy-Befehle**, die ein lokales Projekt voraussetzen; in der Sandbox synct die Datei automatisch.

## Connectors (OAuth-Integrationen)

Connectors (Google Calendar, Gmail, Slack, …) geben deinen Backend-Funktionen Tokens für Drittanbieter-API-Aufrufe. In Remote-Dev gibt es **keine Connector-Dateien zu schreiben** — du operierst direkt auf dem Connector der App über deren ID. Zwei Oberflächen, gleiches Backend und gleiches Verhalten:

> **Deklarative Scopes — vor dem Setzen lesen.** Das Verbinden eines Connectors **ersetzt** sein Scope-Set durch genau die übergebenen Scopes (kein Merging). Jeder ausgelassene Scope wird entfernt und der Nutzer erneut um Zustimmung gebeten. **Liste immer zuerst die aktuellen Scopes des Connectors auf und übergib das vollständige gewünschte Set** (die, die du behalten willst, **plus** neue).

> **OAuth braucht einen Menschen.** Beim Verbinden wird eine **Autorisierungs-URL** zurückgegeben, die der Nutzer in einem Browser öffnen muss, um sich anzumelden und zuzustimmen — du kannst das nicht selbst abschließen. Nachdem er fertig ist, liste erneut auf, um zu bestätigen, dass es verbunden ist, und lies die **gewährten** Scopes (ein Anbieter kann weniger gewähren als angefordert).

### Über MCP (`base44-remote-dev`-Transport)

Zwei Tools, beide nehmen `appId`. Scopes: `list_connectors` benötigt `apps:read`; `initiate_connector_connection` benötigt `apps:write` (Achtung: **nicht** `sandbox:write`).

1. **`list_connectors`** — `{ appId, integrationTypes? }`. Ohne `integrationTypes` gibt es den vollständigen Katalog zurück; jeder Eintrag hat Name, Beschreibung, verbunden? und (falls verbunden) Status und gewährte Scopes. Übergib `integrationTypes` für vollständige Details zu bestimmten Connectors.
2. **`initiate_connector_connection`** — `{ appId, integrationType, scopes, connectionConfig? }`. `scopes` ist das **vollständige** gewünschte Set (siehe den Hinweis zu deklarativen Scopes). Gibt entweder `already_authorized: true` (nichts zu tun) oder eine `redirect_url` zurück, die der Nutzer öffnen muss. Nach der Anmeldung ruf `list_connectors` erneut auf, um zu verifizieren.

```
On appId <APP_ID>: call list_connectors to read googlecalendar's current scopes,
then initiate_connector_connection for googlecalendar with the full scope set
(existing + the calendar.events scope I need). Give me the authorization URL.
```

### Über die CLI (projektlos, `--app-id`)

Diese `base44 connectors`-Unterbefehle funktionieren **ohne lokales Projekt** — sie lösen die App-ID aus `--app-id`, dann `BASE44_APP_ID`, dann einer lokalen `.app.jsonc` auf. Keine `config.jsonc` erforderlich.

```bash theme={null}
# 1. See available integration types for the app
npx base44 connectors list-available --app-id <APP_ID>

# 2. Initialize the connector and start OAuth (sets it to EXACTLY these scopes).
#    Non-interactive: prints the authorization URL. Interactive: also opens the
#    browser and polls until authorized.
npx base44 connectors initiate --app-id <APP_ID> \
  --integration-type googlecalendar \
  --scopes https://www.googleapis.com/auth/calendar.readonly https://www.googleapis.com/auth/calendar.events

# 3. (optional) Fetch the resulting connector config
npx base44 connectors pull --app-id <APP_ID> --dir ./connectors
```

`--scopes` akzeptiert eine leerzeichen- oder kommagetrennte Liste. Wie bei MCP muss der Nutzer die ausgegebene Autorisierungs-URL öffnen, um die Zustimmung abzuschließen; danach spiegelt `list-available` / `pull` den verbundenen Zustand und die gewährten Scopes.

> Das ist die **einzige** Base44-CLI-Nutzung, die zu Remote-Dev gehört — sie zielt auf eine Remote-App per ID ohne lokales Projekt und ohne Deploy-Schritt. Kein Widerspruch zur "no CLI"-Regel oben, die sich auf lokale Projekt-/Deploy-Befehle bezieht.

### Einen verbundenen Connector im Code verwenden

Das Verbinden autorisiert nur den Connector. Um die Drittanbieter-API tatsächlich aufzurufen, hole seinen OAuth-Access-Token **innerhalb einer Backend-Funktion** mit dem Service-Rollen-Connectors-Modul — `base44.asServiceRole.connectors.getConnection(integrationType)` — und verwende den zurückgegebenen `accessToken` (und optionale `connectionConfig`) in deinem eigenen `fetch`:

```typescript theme={null}
import { createClientFromRequest } from "npm:@base44/sdk";

Deno.serve(async (req) => {
  const base44 = createClientFromRequest(req);

  // App-scoped OAuth token — backend / service role only.
  const { accessToken, connectionConfig } =
    await base44.asServiceRole.connectors.getConnection("googlecalendar");

  const events = await fetch(
    "https://www.googleapis.com/calendar/v3/calendars/primary/events",
    { headers: { Authorization: `Bearer ${accessToken}` } },
  ).then((r) => r.json());

  return Response.json({ events });
});
```

Hinweise: Der Connector ist **app-bezogen** (ein verbundenes Konto, das von allen Nutzern geteilt wird); Base44 aktualisiert den Token für dich; du machst die API-Aufrufe. `getConnection()` ersetzt das veraltete `getAccessToken()`. Für die vollständige Modul-Referenz (Signaturen, `connectionConfig`, die Liste verfügbarer Dienste und ihrer Typkennungen) siehe die [`connectors.md`](https://docs.base44.com/developers/skills/base44-sandbox/../base44-sdk/references/connectors.md) im `base44-sdk`-Skill.

## Referenzreihenfolge und die vollständige README

**Konsultiere die Referenzen in diesem Skill und seinen Geschwister-Skills (`base44-remote-dev`, `base44-sdk`), bevor du im Web suchst.** Sie sind die Quelle der Wahrheit für die Sandbox-Bridge, Datei-/Ressourcenkonventionen und SDK-APIs — bevorzuge sie gegenüber allgemeinen Internet-Ergebnissen, die für Base44 oft veraltet oder falsch sind.

Für die vollständige, app-spezifische Remote-Dev-Referenz (Anweisungen + jeder Endpunkt, öffentlich, kein Auth zum Abruf nötig) lies die Onboarding-README für deine App:

```
https://app.base44.com/api/sandbox/<APP_ID>/local-agent/readme.md
```

(Das Cloud/MCP-Äquivalent ist `…/api/sandbox/<APP_ID>/claude-web/readme.md`.) Siehe den `base44-remote-dev`-Skill für die Verbindungsmechanik, die diese README beschreibt.

## Workflow in der Sandbox

1. **Orientieren** — `list_directory` / `read_file` / `grep` (`sandbox ls` / `sandbox read` / `sandbox grep` in der CLI), um die App zu verstehen, bevor du etwas änderst.
2. **Erstellen** — erstelle oder bearbeite Ressourcen-Dateien (Backend-Funktionen, Entitäten, Agenten) und Frontend-Code gemäß den obigen Konventionen; richte Connectors über den Connect-Flow ein.
3. **Verifizieren** — optional `run_command` (`sandbox run`) `npm run build` / `npx tsc --noEmit` und verwende `get_app_preview_url`, um Änderungen anzusehen (siehe `base44-remote-dev`).
4. **Lass es liefern** — tue **nichts** zum Deployen. Die Datei zu schreiben ist das Deploy; der Auto-Commit (\~5s) persistiert und liefert es. Halte einen Moment nach dem letzten Edit inne, bevor du dich trennst, damit der Commit landet.
5. **(Optional) Checkpoint** — markiere einen bekannt-guten Wiederherstellungspunkt, zu dem der Nutzer mit `create_checkpoint` (`base44 sandbox checkpoint --name "..."` in der CLI) zurückrollen kann. Er flusht zuerst ausstehende Änderungen, sodass der Checkpoint deinen neuesten Code erfasst. Siehe `base44-remote-dev` für Details.

<Note>Diese Seite wurde mit KI übersetzt. Für die genauesten und aktuellsten Informationen siehe die [englische Version](/). </Note>