Runtime-Adapter
Claude Code ist die primäre Runtime. Codex, OpenCode und Pi erhalten geteilte Skills und Anweisungen aus einem devkit-Release über optionale Adapter; diese Seite sagt, wie du sie einschaltest und was sie schreiben.
Aktivieren
devkit config codex auto|on|off # Standard auto: aktiv, solange `codex` installiert ist
devkit config opencode auto|on|off # Standard off
devkit config pi auto|on|off # Standard offEin Moduswechsel wirkt beim nächsten devkit apply oder devkit sync. devkit config show zeigt die Modi; devkit doctor prüft die geschriebenen Dateien.
Was jeder Adapter schreibt
| Runtime | Geteilte Quelle | Form | Ziel |
|---|---|---|---|
| Codex | Portable Skills | od-<name>-Skills | ~/.agents/skills/ |
| Codex | Agents | TOML-Definitionen | ~/.codex/agents/ |
| Codex | Geteilte und Codex-Guard-Hooks | Native Hook-Konfiguration | ~/.codex/hooks.json |
| Codex | Guardrails | Rule-Dateien | ~/.codex/rules/ |
| Codex | Globale Anweisungen | Verwalteter Block | ~/.codex/AGENTS.md |
| OpenCode | Tool-Zugriff | Keys tools, permission und subagent_depth, nur ergänzt, nie entfernt; permission."*": "allow" steht vorne, damit opencode ohne Rückfragen startet und ein eigenes ask/deny trotzdem gilt | ~/.config/opencode/opencode.json |
| OpenCode | Globale Anweisungen | Verwalteter Block | ~/.config/opencode/AGENTS.md |
| Pi | Globale Anweisungen | Verwalteter Block markiert als od managed (onedot-devkit pi) | ~/.pi/agent/AGENTS.md |
| Pi | Geteilte Hooks | Kompiliertes Event-, Matcher- und Command-Manifest | ~/.pi/agent/extensions/devkit-hooks.manifest.json |
| Pi | Hook-Bridge | Verwalteter TypeScript-Adapter | ~/.pi/agent/extensions/devkit-hooks.ts |
Die Adapter lassen gleichnamige persönliche Einträge und alles außerhalb des verwalteten Blocks unangetastet; eine behaltene persönliche Rule wird als Warnung gemeldet, nicht als Fehler.
Pi liest beim Start das Hook-Manifest. Schreibende Delegates laden nur die Devkit-Bridge; ohne sie stoppt der Dispatch. Pi abzuschalten entfernt seine Hooks und, falls Codex ebenfalls aus ist, die gemeinsamen Skill-Links. Unlink entfernt nur devkit-eigene Links.
Skill-Namen
Mit Codex oder Pi schreibt devkit gemeinsame Skills als od-<name> nach ~/.agents/skills/. Pi findet sie auch ohne Codex; OpenCode nutzt seine native Skill-Erkennung. devkit path skill <name> bleibt präfixfrei, devkit run startet Scripts.
Pi-MCPs konfigurierst du separat über pi-mcp-adapter. imports: ["codex"] übernimmt Codex-MCP-Server ohne Codex-Start. Für Verbindungen beim Session-Start setze lifecycle: "eager" (oder "keep-alive" für dauerhafte Server) im Pi-Adapter-Override.
Modelle und Berechtigungen
Jeder Agent bekommt dieselbe Modellklasse wie in Claude Code, abgebildet auf die Modellnamen der Runtime. Nur lesende Agents können nicht schreiben; Agents, die editieren, bekommen Schreib- und Shell-Zugriff.
/delegate kann Review, Recherche oder Umsetzung an Codex oder eine andere installierte Runtime schicken; siehe Vorhaben. devkit path resume [projekt-dir] löst den Pre-Compact-Snapshot von Codex für ein Projekt auf.
OpenCode-Voraussetzungen
Ein geteilter Skill braucht in OpenCode die Built-ins read, glob, grep, list und bash. Ohne sie antwortet der Agent weiter, aber als Chatbot: keine Repo-Suche, kein devkit run, und /friction-feedback kann das nicht einmal melden. lsp und websearch sind optional.
OpenCode entfernt ein Built-in aus dem Toolset, sobald irgendeine gemergte Config-Ebene es verweigert — permission.read: "deny" oder tools.read: false ohne permission-Override. Die Ebenen mergen global → OPENCODE_CONFIG → Projekt-opencode.json/opencode.jsonc → .opencode/; ein globales deny bleibt wirksam, bis diese Datei sich ändert oder eine Projektebene denselben Key auf "allow" setzt.
Zwei weitere Stellen verstecken ein Deny: Ein permission-Block am Agent überschreibt das Top-Level, agent.explore.permission.bash: "deny" macht also diesen Subagent blind, auch wenn das Top-Level erlaubt, und experimental.primary_tools nennt Tools, die nur Primary-Agents behalten — ein dort genanntes Built-in ist jedem Subagent verweigert.
devkit apply schreibt das in ~/.config/opencode/opencode.json und lässt einen abweichenden persönlichen Wert stehen:
{
"$schema": "https://opencode.ai/config.json",
"subagent_depth": 2,
"permission": { "read": "allow", "glob": "allow", "grep": "allow", "list": "allow", "bash": "allow" }
}bash darf granular bleiben ("bash": { "git *": "allow", "*": "ask" }); nur eine Regel, die alles verweigert, zählt als fehlend. subagent_depth ist ein Top-Level-Key (nicht unter experimental): geteilte Skills delegieren an Subagents, die selbst delegieren, und OpenCodes Default 1 stoppt den zweiten Sprung mit Subagent depth limit reached (1).
devkit doctor --target opencode # nur OpenCode-Prüfungen, Exit 1 bei Befund
devkit doctor --target pi # nur Pi-Managed-Block und Hook-BridgeDer Bericht nennt jedes fehlende Built-in, die Datei, die es verweigert, jeden Agent mit eigenem Deny, jedes benötigte Tool in experimental.primary_tools und ein subagent_depth unter 2. Dieselben Prüfungen laufen in einem normalen devkit doctor, sobald der Adapter an ist oder ein Projekt eine eigene opencode.json mitbringt.
OpenCode liest Config, Agents, Skills und Plugins einmal beim Start; nach jeder Änderung neu starten. Verhindert eine kaputte Config den Start: OPENCODE_DISABLE_PROJECT_CONFIG=1 überspringt die Projektebene, OPENCODE_CONFIG=/pfad/datei.json lädt eine weitere Datei, OPENCODE_CONFIG_CONTENT='{"$schema":"https://opencode.ai/config.json"}' injiziert Inline-JSON.