OpenCode

Stand: 2026-05-26

Die Runtime-Flows für OpenCode über LiteLLM, MCPHub und Tooling sind in der Diagrammübersicht und im LiteLLM Routing zusammengefasst.

Für normale Benutzer und Operatoren gibt es eigene Onboarding-Seiten:

• OpenCode Operator Onboarding
• OpenCode Quickstart
• OpenCode Setup fuer macOS
• OpenCode Setup fuer Windows
• OpenCode Troubleshooting
• OpenCode Security Guide

Ziel

OpenCode wurde so vorbereitet, dass es fuer mehrere Benutzer als produktive AI Operations Console arbeiten kann. Coding- und Skriptarbeit bleiben moeglich, sind aber nicht der Hauptzweck. Der Schwerpunkt liegt auf Infrastruktur, Operations, SSH, PowerShell, Microsoft 365, Intune, APIs, Firewalling, NetBox, Proxmox, Dokumentation, Incident Response, Change Reviews und Governance.

• Modellrouting ausschliesslich ueber LiteLLM per HTTPS
• kein direkter GB10/Ollama-Provider im Client
• Default-Modell für größere Aufgaben
• Small-Modell für schnelle Aufgaben
• Skills für Infrastruktur, Git, Proxmox, Open WebUI/Ollama, M365 und Security
• Memory-Dateien für wiederkehrende Projektinformationen
• Remote-MCPs für Dokumentations-, Code- und Lanstyle-Infrastruktur-Recherche
• NetBox als produktive IPAM/DCIM-Quelle
• SearXNG/Open WebUI als interne Websuche

Das Zielprofil und die Ops-Modi sind in OpenCode als AI Operations Console dokumentiert.

Konfiguration

• Admin-Config: ~/.config/opencode/opencode.jsonc
• Operator-Config-Vorlage: agent-runtime/configs/opencode.operator.jsonc
• Beispiel-ENV-Datei: agent-runtime/configs/opencode.env.example
• Beispiel-LaunchAgent: agent-runtime/configs/com.lanstyle.opencodeenv.example.plist
• Beispiel-Windows-ENV-Setup: agent-runtime/configs/opencode-windows-env-setup.example.ps1
• Globale Regeln: ~/.config/opencode/AGENTS.md
• Skills: ~/.config/opencode/skills/*/SKILL.md
• Memory: ~/.config/opencode/memory/*.md
• Lokale Secrets: ~/.config/opencode/secrets.env
• Lokale Admin-Fallback-Secrets: ~/.config/opencode/lanstyle-mcp.env

Secrets-Datei:

• Rechte: 600
• wird nicht dokumentiert
• wird nicht in Git gespeichert
• secrets.env wird über die lokale Shell-/Launch-Umgebung geladen
• lanstyle-mcp.env wird nur von deaktivierten lokalen Admin-Fallback-Wrappern gelesen
• secrets.env muss lokal 0600 haben und bleibt ausserhalb von Git.
• LANSTYLE_MCPHUB_TOKEN wird pro Benutzer/Client vergeben und kann serverseitig einzeln deaktiviert werden.
• Aktiver User-Token fuer Maximilian: maximilian-eberhardt-mbp-pro-max in Vaultwarden; der fruehere Bootstrap-Token ist deaktiviert.

Modelle

• Default: lanstyle-litellm/lanstyle/agent-stable
• Small: lanstyle-litellm/lanstyle/fast
• Primaerer Endpoint: https://litellm.lanstyle.de/v1
• Im OpenCode-Client ist kein interner Fallback per 10.222.x.x oder 10.0.x.x konfiguriert.
• Direkter Ollama-/GB10-Provider ist aus der aktiven OpenCode-Konfiguration entfernt; Ollama wird über LiteLLM geroutet.
• Kontextlimits sind in OpenCode explizit pro Modell gesetzt, weil Ollamas OpenAI-kompatibler /v1/models-Endpoint keine Kontext-Metadaten liefert und OpenCode sonst 0 anzeigt.
• lanstyle/agent-stable zeigt auf qwen3-coder-next:latest und ist aktuell das produktive Standardmodell fuer OpenCode.
• lanstyle/architect zeigt auf gpt-oss:120b und ist fuer Planung, Architektur und Reviews vorgesehen.
• lanstyle/agent zeigt auf qwen3.6:35b-a3b und bleibt experimentell, weil es bei laengeren sichtbaren Antworten mit leerem content und finish=length enden kann.
• entfernt zeigt ebenfalls auf qwen3.6:35b-a3b, erzwingt aber serverseitig think:false. Der Alias ist experimentell und im Admin-Profil sichtbar, aber kein Default.
• lanstyle/agent und entfernt sind nicht Bestandteil des Operator-Profils. Normale Operatoren sehen produktiv nur agent-stable, fast und architect.
• lanstyle/fast zeigt auf qwen3-coder-next:latest fuer kleine Aufgaben und schnelle Klassifikation, weil qwen3.5:latest ueber LiteLLM keinen sichtbaren Content geliefert hat.
• Der LiteLLM API-Key liegt lokal in ~/.config/opencode/secrets.env als LITELLM_API_KEY.
• OpenCode nutzt den separaten LiteLLM Virtual Key lanstyle-opencode, nicht den Master-Key.
• Externe OpenCode-Nutzung erfolgt ueber https://litellm.lanstyle.de/v1; der Endpoint wird in NPM mit SSL und Access List Max bereitgestellt.
• agent-stable und fast sind in OpenCode ohne Reasoning-Darstellung konfiguriert, damit sichtbarer Content und Streaming priorisiert werden. architect behaelt Reasoning fuer Planungs-/Review-Aufgaben.

Skills

Aktiv angelegt:

• infra-devops
• git-safe-workflow
• proxmox-admin
• openwebui-ollama
• m365-hybrid
• security-review
• netbox-ipam
• rag-knowledge-curator
• customer-access-model
• n8n-automation

MCPs

• context7 via https://mcp.context7.com/mcp
• gh_grep via https://mcp.grep.app
• lanstyle_mcphub via https://mcphub.lanstyle.de/lanstyle-mcp

Context7 nutzt eine Umgebungsvariable für den API-Key. Der Key steht nicht direkt in der OpenCode-Konfiguration.

OpenCode nutzt fuer Lanstyle-Infrastrukturarbeit den zentralen Remote-MCP-Pfad mit oauth:false und Authorization: Bearer {env:LANSTYLE_MCPHUB_TOKEN}. Dadurch ist kein manueller MCPHub-Login beim Öffnen von OpenCode nötig. Die freigegebenen Tools bleiben bewusst eindeutig benannt, z. B. netbox_list_prefixes, npm_list_proxy_hosts und proxmox_plan_guest_change.

Der normale MCPHub-OAuth-Endpunkt https://mcphub.lanstyle.de/mcp bleibt fuer MCPHub selbst erhalten, ist aber nicht der OpenCode-Standardweg.

Lokale stdio-MCPs bleiben als deaktivierter Admin-/LAN-Fallback vorhanden:

• lanstyle_infra_local
• lanstyle_write_plan_local

Timeouts:

• context7: 30000 ms
• gh_grep: 30000 ms
• lanstyle_mcphub: 60000 ms

Die hoeheren Timeouts reduzieren abgebrochene Tool-Listen und laengere MCP-Calls, ohne Schreibrechte zu erweitern.

Onboarding fuer weitere Benutzer

1. OpenCode installieren und einmal starten.
2. ~/.config/opencode/opencode.jsonc aus der Vorlage agent-runtime/configs/opencode-mcp.example.json bzw. der Lanstyle-Standardkonfiguration uebernehmen.
3. ~/.config/opencode/secrets.env anlegen und auf 0600 setzen.
4. LITELLM_API_KEY aus Vaultwarden eintragen.
5. LANSTYLE_MCPHUB_TOKEN aus Vaultwarden eintragen.
6. optional CONTEXT7_API_KEY eintragen.
7. OpenCode neu starten.
8. Testen: Modellliste, kurzer Chat mit lanstyle/agent-stable, MCP Tool Listing, read-only Tool, plan-only Tool.

Keine internen 10.222.x.x-, 10.0.x.x- oder GB10/Ollama-Ziele in Client-Konfigurationen eintragen.

Token-Namensschema fuer neue Benutzer:

• vorname-nachname-client
• Beispiel ohne Secretwert: maximilian-eberhardt-mbp-pro-max
• pro Benutzer und Client ein eigener Token
• Sperrung erfolgt serverseitig pro Token, ohne andere Benutzer zu beeinflussen

Profile

Admin-Profil

Pfad: ~/.config/opencode/opencode.jsonc

Das Admin-Profil ist fuer Maximilian bzw. explizit berechtigte Administratoren gedacht. Es erlaubt lokale Datei- und Shell-Arbeit im Projektkontext, nutzt aber fuer Lanstyle-Infrastruktur weiterhin den Remote-MCP mit serverseitigem RBAC, Approval und Controlled Execution.

Operator-Profil

Vorlage: agent-runtime/configs/opencode.operator.jsonc

Das Operator-Profil ist fuer normale Benutzer gedacht:

• LiteLLM nur ueber https://litellm.lanstyle.de/v1
• Remote-MCP nur ueber https://mcphub.lanstyle.de/lanstyle-mcp
• keine lokalen stdio-MCPs
• keine direkten 10.x Upstreams
• kein direkter GB10/Ollama-Provider
• Default lanstyle/agent-stable
• lanstyle/agent ausgeblendet, weil experimentell
• lokale bash- und edit-Berechtigungen sind deny

Operatoren arbeiten damit ueber read-only, preflight, mock und approval-basierte Tools. Echte Infrastrukturwrites laufen ausschliesslich ueber serverseitige Approval-, Lock-, Backup-, Audit- und Verification-Pfade.

Self-Service Access

Normale Benutzer sollen OpenCode-Zugaenge ueber den OpenWebUI-Self-Service anfordern. Die interne Access API erzeugt pro Benutzer und Geraet einen LiteLLM Virtual Key, einen Remote-MCP Bearer Token und eine einmalige opencode.env oder ein ZIP-Paket.

Regeln:

• bestehende Tokenwerte werden nie angezeigt
• neue Tokenwerte sind nur einmalig abrufbar
• Status zeigt nur Fingerprints, Erstellzeit und Ablauf
• Admin- und Operator-Profil bleiben getrennt
• normale Operatoren erhalten keine lokalen bash-/edit-Freigaben

Details: OpenCode Self-Service Access.

Berechtigungen Admin-Profil

OpenCode ist im Admin-Profil für den lokalen produktiven Arbeitsmodus so eingestellt, dass normale Projektarbeit nicht ständig nachfragt.

• Desktop Auto-Approve: aktiv
• read, grep, glob, skill, webfetch, websearch, todowrite, question: allow
• edit: allow
• bash: allow
• external_directory: ask
• context7_*: allow
• gh_grep_*: allow
• lanstyle_mcphub_*: allow
• lokale Fallback-MCPs: ask
• netbox_*, npm_*, gitea_get_version, proxmox_get_version, proxmox_list_cluster_resources: allow
• Plan-only Tools gitea_plan_repository_change, netbox_plan_prefix_change, proxmox_plan_guest_change: allow
• Backup vor der Basisänderung: /Users/vinc32/Documents/opencode-backups/20260520-201537-permissions-autoapprove
• Backup vor Freigabe externer Toolserver: /Users/vinc32/Documents/opencode-backups/20260520-201635-external-tools-autoallow
• Backup vor Entfernen ungültiger Tool-Permissions: /Users/vinc32/Documents/opencode-backups/20260521-030032-remove-invalid-tool-permissions

Damit darf OpenCode innerhalb des jeweiligen Projektkontexts Dateien ändern, Shell-Kommandos ausführen und die eingerichteten Toolserver Context7, grep.app und lanstyle_mcphub ohne Rückfrage nutzen. Zugriffe außerhalb des Projektordners bleiben bewusst genehmigungspflichtig.

Berechtigungen Operator-Profil

• read, grep, glob, skill, webfetch, websearch, todowrite, question: allow
• edit: deny
• bash: deny
• external_directory: ask
• Remote-MCPs: allow
• lokale stdio-MCPs: nicht konfiguriert
• Write-nahe Tools bleiben serverseitig durch RBAC, Approval, Dependency Locks und Backup Enforcement begrenzt.

Empfohlener Test nach Einrichtung:

1. OpenCode mit Operator-Konfiguration starten.
2. Modellliste pruefen: agent-stable, fast, architect.
3. MCP Tool Listing ausfuehren.
4. netbox_get_status als read-only Tool testen.
5. proxmox_plan_guest_change oder Golden-Path-Preflight testen.
6. Sicherstellen, dass lokale Bash/Edit-Aktionen nicht automatisch erlaubt sind.

Controlled Execution UX

OpenCode soll echte Infrastruktur-Changes nicht direkt per Shell ausfuehren, sondern ueber den Controlled Execution Layer planen und erst nach Approval ausfuehren.

Serverseitig verfuegbar:

• chain_status
• active_step
• waiting_for_approval
• rollback_available
• rollback_readiness_state
• verification_summary
• backup_summary
• audit_reference
• chain_summary

Operator UX fuer Changeplaene

OpenCode soll Controlled-Execution-Antworten nicht als Rohdaten anzeigen, sondern den Block operator_summary priorisieren.

Operator-Konsole

OpenCode nutzt die Tools API als Operations-Konsole. Für gute Lesbarkeit soll OpenCode diese Felder bevorzugt rendern:

1. summary
2. operator_summary
3. risk_summary
4. policy_summary
5. approval_summary
6. timeline_summary
7. next_action
8. explicit_out_of_scope
9. blockers
10. warnings

Hilfsendpunkte:

Endpoint	Zweck
/ops/opencode-guidance	Anzeige- und Priorisierungsregeln
/ops/self-service-templates	sichere Standardaufgaben
/ops/change-review/preflight	zweiter Review-Layer vor Changes
/ops/rbac-model	Rollen-/Tokenmodell
/ops/safe-mode-policy	Incident-/Safe-Mode-Verhalten

Wichtige Felder:

Feld	Anzeige
what_will_happen	Kurzbeschreibung des Changes
affected_systems	betroffene Systeme
risk_level / risk_reason	Risk Badge und Begruendung
approval_id_required	benoetigte Freigabe-ID
exact_approval_phrase	exakt zu sendender Freigabetext
locks	aktive oder geplante Dependency Locks
backups	erwartete oder erzeugte Backups
rollbacks	moeglicher Rueckweg
in_scope	explizit enthalten
out_of_scope	explizit nicht enthalten

Wenn changeplan_artifact oder recovery_artifact vorhanden ist, kann OpenCode den Markdown-Pfad fuer Menschen und den JSON-Pfad fuer Maschinen anzeigen.

Wichtig: OpenCode darf keine Tokenwerte oder lokale Secret-Dateien in Artefakte kopieren.

Unified Operator Response

OpenCode soll bevorzugt unified_operator_response rendern, wenn dieser Block vorhanden ist.

Pflichtanzeige:

• summary
• workflow_state
• action_classification
• human_decision_points
• risk_summary
• policy_summary
• lock_summary
• backup_summary
• rollback_summary
• approval_summary
• timeline_summary
• next_action
• exact_approval_phrase
• explicit_out_of_scope
• warnings
• blockers

Rendering-Hinweise wie show_as_blocker, highlight_risk, highlight_approval, highlight_recovery, timeline_cards und risk_badges kommen serverseitig mit. OpenCode soll diese Hinweise als UI-Priorisierung verstehen, nicht als Sicherheitsentscheidung.

Empfohlene Anzeigeprioritaet

OpenCode soll bei Operations-Antworten zuerst anzeigen:

1. operator_priority
2. operator_card
3. blockers
4. warnings
5. next_action
6. approval_ux
7. rollback_ux
8. timeline_compact
9. trust_summary

Einklappbar bleiben:

• risk_summary
• policy_summary
• lock_summary
• backup_summary
• recovery_summary
• rohe Timeline-/Debug-Felder

Die Startansicht soll nie mit Roh-JSON beginnen. Ziel ist eine Operations-Karte mit Status, Risk, Next Action, Approval, Rollback, Backup, Drift und Confidence/Freshness. trust_summary.confirmed sind bestaetigte Fakten, interpreted sind Ableitungen der Plattform, uncertain sind Warnungen oder fehlende Daten.

Der erste produktionsnahe Chain-Test proxmox_test_chain_v1 wurde erfolgreich ausgefuehrt. Fuer normale Arbeit bedeutet das: OpenCode kann kuenftig Multi-Step-Aenderungen als Chain planen, Status und Rollback-Bereitschaft anzeigen und darf Live-Writes nur ueber scoped Tools mit Approval-ID ausloesen.

Der erste Multi-System-Workflow lanstyle-ce-test-01 ist als Preflight vorbereitet. OpenCode kann damit Dependency Graph, Risk Summary, Rollback-Reihenfolge, betroffene Systeme und Pending Approvals anzeigen, ohne eine LXC zu erstellen.

Fuer Cleanup-/Destroy-Flows muss OpenCode zusaetzlich sichtbar machen:

• destructive_action
• requires_separate_cleanup_approval
• mandatory_cooldown_minutes
• mandatory_double_confirmation
• rollback_possible_after_remove_lxc=false
• remove_lxc_enabled=false
• Dependency Graph vor Destroy
• Archive References
• Pending Cleanup Approval
• Orphan Detection

Der aktuelle Cleanup-Preflight fuer LXC 124 ist plan-only. OpenCode darf daraus keinen remove_lxc-Execute ableiten.

Fuer State und Drift soll OpenCode anzeigen:

• Desired vs. Observed State
• Drift-Warnungen
• unmanaged_change_detected
• Chain Ownership
• reconciliation_required
• Rollback-Verfuegbarkeit
• Cleanup State
• Object/Chain/Approval/Rollback/Cleanup Timeline

OpenCode darf Drift nicht automatisch reparieren. Der naechste Schritt nach Drift-Erkennung ist ein Plan mit separater Reconciliation-Approval.

Fuer Policy und Risk soll OpenCode anzeigen:

• Risk Badge
• Blast Radius Summary
• Maintenance Window Warning
• Policy Violations
• Blocked Execution Reason
• Approval Escalation Required
• Dependency Lock Active
• Chain Owner und Approval Owner

Wenn policy_decision=blocked oder approval_escalation_required=true zurueckkommt, darf OpenCode keinen Execute starten, sondern muss einen Changeplan mit Freigabeanforderung erzeugen.

Fuer Dependency Locks soll OpenCode anzeigen:

• lock_status
• blocked_by
• lock_owner
• expires_at
• release_required
• stale_lock_warning
• emergency_hold_warning

Bei aktivem Lock darf OpenCode nur planen, nicht ausfuehren. Ein Release braucht eine nachvollziehbare eigene Aktion.

Chain-Antworten enthalten kuenftig direkt:

• lock_candidates
• lock_conflicts
• execution_allowed
• blocked_reason
• lock_recommendation
• lock_id
• lock_status
• blocked_by

Wenn execution_allowed=false ist, muss OpenCode stoppen und den Blockgrund anzeigen.

Die Lock-Antworten kommen aus dem operationalen SQLite-Store. Historische JSONL-Events sind nur Audit. OpenCode soll stale/orphaned/failed-release Locks als manuelle Pruefung anzeigen und keinen Auto-Override anbieten.

Fuer Lock Recovery soll OpenCode anzeigen:

• lock_recovery_required
• recovery_options
• recommended_action
• risk_level
• manual_review_required
• approval_text

Recovery Execute ist nur mit eigener Approval-ID erlaubt.

Hinweis zu lokalem Ollama/OpenCode Tool-Calling: Falls ein Modell ein nicht verfügbares Tool wie list, run oder todo_write aufruft, ist das ein Modell-/Tool-Schema-Mismatch. OpenCode nennt die eingebauten Tools unter anderem glob, grep, read, write, bash und todowrite. In den globalen OpenCode-Regeln ist deshalb hinterlegt, welche Toolnamen exakt zu nutzen sind.

• Ein Test mit globalen Alias-Tools wurde wieder deaktiviert, weil OpenCode dadurch @opencode-ai/plugin@local installieren wollte und Sessions mit ERR_MODULE_NOT_FOUND blockierte.
• Deaktivierte Alias-Tools: ~/.config/opencode/tools.disabled-20260521-015555/
• @opencode-ai/plugin ist danach lokal in ~/.config/opencode/package.json mit Version 1.15.6 hinterlegt und installiert, damit OpenCode keine kaputten lokalen Plugin-Abhängigkeiten mehr lädt.
• Backup vor erster Regel-Ergänzung: /Users/vinc32/Documents/opencode-backups/20260520-202457-avoid-list-tool
• Backup vor Alias-Ergänzung: /Users/vinc32/Documents/opencode-backups/20260521-015055-tool-aliases
• Backup vor Deaktivierung der Alias-Tools: /Users/vinc32/Documents/opencode-backups/20260521-015555-disable-broken-alias-tools
• Backup vor Wechsel des Default-Modells auf qwen2.5-coder:32b: /Users/vinc32/Documents/opencode-backups/20260521-015657-default-stable-tool-model
• Backup vor Wiederherstellung von qwen3-coder-next:latest als Default: /Users/vinc32/Documents/opencode-backups/20260521-020207-restore-coder-next-default
• Backup vor lokaler Plugin-Abhängigkeit: /Users/vinc32/Documents/opencode-backups/20260521-015928-install-plugin-dependency

Die MCP-Server Context7 und grep.app melden beim Start teilweise Method not found failed to get prompts. Das betrifft die optionale MCP-Prompt-Abfrage und nicht zwingend die eigentlichen Tools. Falls OpenCode dadurch wieder blockiert, die MCPs temporär deaktivieren und erst danach gezielt einzeln wieder aktivieren.

Interner Lanstyle MCP

Vorbereitet:

• MCP-Projekt: agent-runtime/mcp/lanstyle-infra-mcp
• Startwrapper: agent-runtime/scripts/start-lanstyle-infra-mcp.sh
• OpenCode-Beispiel: agent-runtime/configs/opencode-mcp.example.json
• Aktivierungsrunbook: agent-runtime/runbooks/opencode-mcp-activation.md
• Remote-MCP-Service: agent-runtime/tools/lanstyle_remote_mcp.py

Zweck:

• NetBox, NPM, Proxmox und Gitea read-only in OpenCode nutzbar machen.
• Secrets serverseitig im Agent-Runtime-LXC halten; Client nutzt nur LANSTYLE_MCPHUB_TOKEN.
• Keine generischen Tools wie list, run, write oder todo_write bereitstellen.

Vorbereitete Toolnamen:

• netbox_get_status
• netbox_list_sites
• netbox_list_prefixes
• npm_list_proxy_hosts
• proxmox_get_version
• proxmox_list_cluster_resources
• gitea_get_version
• controlled_execution_get_policy
• controlled_execution_mock_noop
• controlled_execution_proxmox_config_export
• controlled_execution_npm_proxy_export
• controlled_execution_netbox_object_export

Controlled Execution Workflow

OpenCode darf echte Infrastrukturänderungen nicht direkt ausfuehren. Der Sollablauf ist:

1. Plan erstellen.
2. Risiko klassifizieren.
3. Backup-/Export-Anforderung festlegen.
4. Menschliche Approval-ID einholen.
5. Nur ein scoped Controlled-Execution-Tool ausfuehren.
6. Verification, Audit und Rollback-Referenz pruefen.
7. Doku aktualisieren.

Aktuell sind in OpenCode nur Mock und Export-only Aktionen produktiv nutzbar. Live-Writes wie Proxmox create_lxc, NetBox create_prefix oder NPM update_backend bleiben gesperrt, bis ein erster echter Change separat freigegeben wurde.

OpenCode kann fuer Governance-Status die Tools-API nutzen:

• GET /controlled-execution/policy
• GET /execution-chains/policy

Bei Chain-Antworten sollen Agenten dem Benutzer anzeigen:

• chain_id
• chain_status
• steps_completed / steps_total
• partial_failure_state
• resumable
• backup_reference
• rollback_plan

Replay- oder Approval-Fehler muessen sichtbar als blockiert gemeldet werden, nicht als normales Toolproblem.

Arbeitsweise für MSP-Kunden

• Kundenkontext zuerst bestimmen.
• Pro Kunde Gitea-Organisation, Wiki-Seite und NetBox-Objekte als Quellen nutzen.
• Maximilian darf alle Kunden bearbeiten.
• Weitere Benutzer bekommen nur die vorgesehenen Organisationen/Repositories.
• Schulen werden als eigene Gruppe behandelt.
• Secrets, private Keys, Zugangsdaten und vollständige Exporte werden nicht in RAG oder Git übernommen.

Kundenprojekte

OpenCode wurde lokal mit eigenen Projekten pro Organisation vorbereitet.

• Projektwurzel: /Users/vinc32/Documents/OpenCode-Projekte
• OpenCode-Datenbank: ~/.local/share/opencode/opencode.db
• Kunden-Memory: ~/.config/opencode/memory/customers.md
• Backup vor Anlage: /Users/vinc32/Documents/opencode-backups/20260520-184626-before-customer-projects

Angelegte OpenCode-Projekte:

Organisation	Projektpfad	Gitea-Organisation
Lanstyle IT Solutions GmbH	/Users/vinc32/Documents/OpenCode-Projekte/lanstyle	lanstyle
Lanstyle Netzwerkinfrastruktur	/Users/vinc32/Documents/OpenCode-Projekte/lanstyle-netzwerkinfrastruktur	lanstyle
TecMed Deutschland GmbH	/Users/vinc32/Documents/OpenCode-Projekte/tecmed-deutschland	tecmed-deutschland
ARTIS Immobilienverwaltung GmbH	/Users/vinc32/Documents/OpenCode-Projekte/artis-immobilienverwaltung	artis-immobilienverwaltung
Hauck GmbH & Co. KG	/Users/vinc32/Documents/OpenCode-Projekte/hauck	hauck
Salzmannschule Schnepfenthal	/Users/vinc32/Documents/OpenCode-Projekte/salzmannschule-schnepfenthal	salzmannschule-schnepfenthal
Sportgymnasium Oberhof	/Users/vinc32/Documents/OpenCode-Projekte/sportgymnasium-oberhof	sportgymnasium-oberhof
Sportgymnasium Jena	/Users/vinc32/Documents/OpenCode-Projekte/sportgymnasium-jena	sportgymnasium-jena
Sportgymnasium Erfurt	/Users/vinc32/Documents/OpenCode-Projekte/sportgymnasium-erfurt	sportgymnasium-erfurt
Musikgymnasium Schloss Belvedere Weimar	/Users/vinc32/Documents/OpenCode-Projekte/musikgymnasium-belvedere-weimar	musikgymnasium-belvedere-weimar
Privat / Eberhardt	/Users/vinc32/Documents/OpenCode-Projekte/privat-eberhardt	privat-eberhardt
ProbeFox GmbH	/Users/vinc32/Documents/OpenCode-Projekte/probefox	probefox
XAM GmbH	/Users/vinc32/Documents/OpenCode-Projekte/xam	xam
Deutsches Rotes Kreuz Muldenthal	/Users/vinc32/Documents/OpenCode-Projekte/drk-muldenthal	drk-muldenthal
FSG Energy GmbH & Co. KG	/Users/vinc32/Documents/OpenCode-Projekte/fsg-energy	fsg-energy
Speed Clever Leben Versicherungsservice GmbH	/Users/vinc32/Documents/OpenCode-Projekte/speed-clever-leben	speed-clever-leben

Lanstyle Netzwerkinfrastruktur ist bewusst als eigenes OpenCode-Projekt angelegt, obwohl es zur Organisation lanstyle gehört. OpenCode erkennt Kontext primär über den geöffneten Projektordner/Worktree und die Session-Zuordnung, nicht allein über die Firma. Für die Lindenstraße-Netzwerkplanung daher immer den Worktree /Users/vinc32/Documents/OpenCode-Projekte/lanstyle-netzwerkinfrastruktur öffnen.

• Gitea-Repo: https://git.lanstyle.de/lanstyle/netzwerkinfrastruktur
• vorbereitete OpenCode-Sitzung: Lindenstraße Netzwerk Neuplanung
• Prompt-Datei: docs/lindenstrasse-netzwerkplanung-prompt.md
• Backup vor OpenCode-Registrierung: /Users/vinc32/Documents/opencode-backups/20260520-200747-before-lanstyle-netzwerk-project

Jedes Projekt enthält ein eigenes AGENTS.md und README.md mit Quellen, Gitea-Organisation, Vaultwarden-Zuordnung und Arbeitsregeln. Secrets werden darin nicht gespeichert.

Git-Anbindung

Die lokalen OpenCode-Projekte sind als Git-Repositories initialisiert und mit Gitea verbunden.

• Pro Organisation wurde ein privates Repository dokumentation angelegt.
• Jeder lokale OpenCode-Projektordner hat origin auf das jeweilige Organisations-Repository gesetzt.
• Alle 15 Projektordner wurden initial mit AGENTS.md und README.md nach Gitea gepusht.
• Beispiel: /Users/vinc32/Documents/OpenCode-Projekte/tecmed-deutschland -> https://git.lanstyle.de/tecmed-deutschland/dokumentation.git
• Git nutzt lokal credential.helper=osxkeychain, damit OpenCode/Git vorhandene macOS-Keychain-Credentials nutzen kann.
• Der Gitea-Token für OpenCode/Git liegt lokal im macOS-Keychain und zusätzlich als GITEA_TOKEN in ~/.config/opencode/secrets.env.
• ~/.config/opencode/secrets.env hat Dateirechte 600 und wird nicht in Git gespeichert.
• Backup vor der Git-Anbindung: /Users/vinc32/Documents/opencode-backups/20260520-192630-before-gitea-remotes

Repository-Strategie:

• dokumentation: Kundenkontext, Runbooks, Inventar, OpenCode-Regeln, Wiki-nahe Inhalte
• automationen: nur anlegen, wenn pro Kunde echte Skripte/Jobs entstehen
• configs: nur anlegen, wenn versionierte Konfigurationen getrennt von Doku gepflegt werden sollen
• Keine Secrets, privaten Keys oder Roh-Exporte committen.

Für bessere Erkennbarkeit in der OpenCode-GUI wurden lokale SVG-Projekticons gesetzt.

• Icon-Verzeichnis: ~/.config/opencode/project-icons
• Die Icons sind zusätzlich als Data-URL in icon_url und icon_url_override der OpenCode-Projekttabelle hinterlegt.
• Backup vor der Änderung: /Users/vinc32/Documents/opencode-backups/20260520-190244-before-project-icons
• OpenCode ggf. vollständig neu starten, damit die GUI die Icons neu lädt.

Für Organisationen mit bekannten offiziellen Domains wurden die Kürzel-Icons durch offizielle Favicons/Logo-Ausschnitte ersetzt:

• Quellen-/Icon-Verzeichnis: ~/.config/opencode/project-icons/official
• Manifest: ~/.config/opencode/project-icons/official/manifest.json
• Backup vor der Änderung: /Users/vinc32/Documents/opencode-backups/20260520-191114-before-official-project-icons
• Offizielle Quellen: lanstyle.de, tecmedgmbh.de, drkmuldental.de, salzmannschule.de, fsg-energy.de, hauck.de, speed-clever-leben.de, artis-immobilien.de
• Für Salzmannschule wurde aus dem offiziellen Logo der linke Logo-Bereich als quadratisches Icon erzeugt.

OpenCode Desktop zeigt die Projekticons nicht nur aus der SQLite-Projekttabelle an. Die GUI speichert sichtbare Workspace-Icons zusätzlich in einzelnen Desktop-State-Dateien unter:

• ~/Library/Application Support/ai.opencode.desktop/opencode.workspace.-Users-vinc3.*.dat

Die Zuordnung der Dateien erfolgt über den normalisierten Projektpfad und eine FNV-1a-Checksum. Nach Test über die GUI wurde TecMed Deutschland GmbH eindeutig als opencode.workspace.-Users-vinc3.p8wlo1.dat identifiziert. Anschließend wurden alle 15 bekannten OpenCode-Projekte mit workspace:icon versehen.

• Backup vor der Desktop-State-Anpassung: /Users/vinc32/Documents/opencode-backups/20260520-194955-before-workspace-icons
• Offizielle Icons wurden für die acht bekannten Domains genutzt.
• Projekte ohne offizielle Domain behalten lokale Initialen-Icons.
• OpenCode vollständig neu starten, wenn Icons nach der Änderung nicht sofort sichtbar sind.

Websuche

OpenCode hat websearch und webfetch erlaubt. Für technische Dokumentation zuerst Context7 verwenden, für Code-Recherche gh_grep, für allgemeine Recherche Websuche. SearXNG ist primär für Open WebUI eingerichtet; eine OpenCode-MCP-Anbindung sollte erst ergänzt werden, wenn ein stabiler lokaler SearXNG-MCP-Server feststeht.

Git-Empfehlung

• lokal entwickeln
• git status und git diff vor jedem Commit prüfen
• gezielt stagen
• manuell committen
• Gitea als privates Remote nutzen
• keine Secrets oder private Keys committen