2026 OpenCode 2.0: Werden Projekte auf einem gemeinsam genutzten Mac vermischt?

Die OpenCode-V2-Dokumentation ordnet fünf Bereiche dem aktuellen Benutzerkonto zu: Sitzungen, Konfiguration, Integrationen, Berechtigungen und Werkzeugausführung. Daraus folgt die Entscheidung: Ein gemeinsam genutzter OpenCode-Hintergrunddienst ist keine Mehrbenutzer-Isolierung. Teilen Sie vorerst keine macOS-Benutzersitzung für unterschiedliche Forschungsprojekte, solange Konten, Verzeichnisse, Zugangsdaten und Dienstzugriffe nicht geprüft sind.

Dieser Leitfaden ist für Forschungsgruppenleitungen gedacht, die eine gemeinsame Mac-Umgebung planen.
Laboradministratoren finden hier Prüfpunkte für Konten, Dienste und Projektordner.
Forschungssoftware-Teams können damit den Wechsel von Einzelarbeit zu gemeinsamem Fernzugriff bewerten.

Zuletzt geprüft am 03.11.2026 anhand der OpenCode-V2-Dokumentation und des offiziellen Änderungsprotokolls. Prüfen Sie die genaue Konfiguration nach Updates erneut.

OpenCode 2.0 auf einem gemeinsam genutzten Mac: Was wird tatsächlich gemeinsam genutzt?

„Gemeinsam nutzen“ kann Verschiedenes bedeuten: Mehrere Personen arbeiten abwechselnd im selben macOS-Konto, sie melden sich mit getrennten Systemkonten an oder sie verbinden sich mit demselben OpenCode-Dienst. Diese Varianten haben unterschiedliche Grenzen. Dass mehrere Personen dieselbe physische Mac-Hardware verwenden, sagt allein nicht aus, ob ihre Anwendungssitzungen, Dateien oder Zugangsdaten voneinander getrennt sind.

Die OpenCode-V2-CLI-Dokumentation beschreibt, dass der Hintergrunddienst Anwendungszustände für das aktuelle Benutzerkonto verwaltet. Sie beschreibt außerdem die Verbindung mit einem eigenständigen Dienst oder einem angegebenen Server. Daraus lässt sich nicht ableiten, dass ein gemeinsamer Dienst automatisch getrennte Identitäten für mehrere Forschende bereitstellt. Ebenso wenig garantiert ein eigener Client pro Person eine Trennung, wenn alle Clients mit demselben Konto oder Dienst arbeiten.

Für eine belastbare Prüfung müssen Sie deshalb vier Dinge auseinanderhalten:

• Anwendungssitzung: Welche Sitzungen und welcher Anwendungszustand werden dem angemeldeten Benutzer zugeordnet?
• macOS-Konto: Mit welchem Systemkonto läuft OpenCode, und wer kann sich dort anmelden?
• Dateisystem: Welche Projektordner kann dieses Konto lesen oder verändern?
• Dienstverbindung: Mit welchem OpenCode-Server kommuniziert der Client, und wer darf diesen Server erreichen?

Prüfen Sie zuerst, welcher Benutzer angemeldet ist. Kontrollieren Sie danach, auf welchen Dienst der Client zeigt. Vergleichen Sie anschließend die angezeigten Sitzungen und die verwendete Konfiguration. Die offizielle Konfigurationsdokumentation beschreibt die Konfigurationsebenen; verwenden Sie sie, um festzustellen, welche Einstellungen in der konkreten Installation gelten. Übertragen Sie Ergebnisse aus einer einzelnen Testkonfiguration nicht ungeprüft auf andere OpenCode-Versionen oder Konten.

Welche Sitzungen und Einstellungen kann ein gemeinsamer Hintergrunddienst betreffen?

OpenCode 2.0 Shared-Backend-Service ist in diesem Zusammenhang keine Zusage, dass jede Person einen separaten privaten Anwendungsbereich erhält. Der relevante Prüfpunkt ist, ob alle Beteiligten dieselbe Benutzeridentität und denselben Dienstkontext verwenden. Wenn das der Fall ist, müssen Sie davon ausgehen, dass der Anwendungszustand nicht allein durch verschiedene Client-Fenster getrennt wird.

Vergleichen Sie für jede Testperson:

1. den angemeldeten macOS-Benutzernamen;
2. das konfigurierte Verbindungsziel;
3. die sichtbaren OpenCode-Sitzungen;
4. den Pfad und die Herkunft der Konfigurationsdateien.

Halten Sie die Beobachtungen pro Testkonto fest. Wenn zwei Personen dieselbe Sitzung oder Konfiguration sehen, stoppen Sie den Einsatz mit echten Forschungsdaten und klären Sie zunächst die Konto- und Dienstgrenzen. Wenn die Sitzungslisten unterschiedlich aussehen, ist damit noch keine Isolation der Projektdateien, Umgebungsvariablen oder Schlüssel bewiesen.

Getrennte Sitzungen schützen Projektdateien nicht automatisch

Eine Anwendungssitzung und ein Arbeitsverzeichnis sind zwei verschiedene Dinge. Auch wenn OpenCode unterschiedliche Sitzungen anzeigt, kann ein falsches Arbeitsverzeichnis Änderungen in einem fremden Repository verursachen. Umgekehrt verhindert eine getrennte Projektmappe nicht automatisch, dass ein Konto weitere, für dieses Konto zugängliche Daten lesen kann.

Prüfen Sie besonders diese typischen Fehlerquellen:

• Ein Client startet im Home-Verzeichnis statt im vorgesehenen Repository.
• Mehrere Personen bearbeiten denselben Arbeitsbaum oder dieselbe lokale Kopie.
• Ein Befehl schreibt Ausgaben in ein gemeinsames Verzeichnis außerhalb des Projekts.
• Die aktive Git-Branch entspricht nicht der erwarteten Forschungsaufgabe.
• Eine Sitzung wird fortgesetzt, obwohl sich das Team oder der Projektkontext geändert hat.

Für gemeinsam verwaltete Repositorys können getrennte Arbeitsbäume eine Option sein. Die Git-Dokumentation zu git worktree erläutert, wie mehrere Arbeitsverzeichnisse mit einem Repository verbunden werden. Das ist eine Versionsverwaltungsfunktion, keine Sicherheitsgrenze: Sie ersetzt weder getrennte macOS-Konten noch Dateirechte und Zugangskontrollen.

Testen Sie vor produktiver Nutzung mit einem Repository ohne vertrauliche Inhalte. Legen Sie darin eindeutig benannte Testdateien an, prüfen Sie den Startpfad, schreiben Sie eine Änderung und kontrollieren Sie anschließend Branch, Dateipfad und Git-Status. Wiederholen Sie den Test mit dem zweiten vorgesehenen Konto. Wenn die Personen denselben Arbeitsbaum verwenden sollen, vereinbaren Sie ein Verfahren für gleichzeitige Änderungen und sichern Sie den Zustand vor dem Test. Führen Sie keine „Isolationsprobe“ mit echten Proben-, Patienten- oder unveröffentlichten Forschungsdaten durch.

macOS-Konten, Befehlsrechte und Zugangsdaten sind getrennte Grenzen

Ein macOS-Benutzerkonto bestimmt mit, auf welche Dateien und Ressourcen ein angemeldeter Benutzer zugreifen kann. Teilen mehrere Personen dasselbe Konto, teilen sie damit auch dessen erreichbare Dateien und gespeicherte Geheimnisse. Eine Freigabe innerhalb der Anwendung macht aus einem gemeinsamen Betriebssystemkonto keine voneinander abgeschotteten Identitäten.

Apple beschreibt das Anlegen zusätzlicher Mac-Benutzer und die Datei- und Ordnerberechtigungen. Nutzen Sie getrennte Konten, wenn Forschende nicht auf die jeweils anderen Projektdateien zugreifen sollen. Prüfen Sie auch Gruppenmitgliedschaften, gemeinsam verwendete Ordner und die tatsächlichen Rechte der Projektverzeichnisse. Ein separates Konto allein genügt nicht, wenn sensible Dateien absichtlich für alle freigegeben sind.

Daneben sind die Berechtigungen von OpenCode zu prüfen. Die OpenCode-Dokumentation zu Berechtigungen behandelt die Anwendungsebene. Kontrollieren Sie, welche Aktionen und Werkzeuge in der installierten Version erlaubt sind und ob eine Änderung tatsächlich für das gewünschte Konto oder Projekt gilt. Setzen Sie diese Einstellungen nicht mit den macOS-Dateirechten gleich: Eine Anwendungsregel ist kein Ersatz für die Zugriffskontrolle des Betriebssystems.

Zugangsdaten erfordern eine eigene Bestandsaufnahme. Dazu zählen Schlüssel in Umgebungsvariablen, Konfigurationsdateien, Shell-Profilen und lokalen Speicherorten. Fragen Sie für jeden Eintrag: Wer hat ihn eingerichtet? Welcher Benutzer kann ihn lesen? Wird er von einem gemeinsam genutzten Dienstprozess geerbt? Wer darf ihn erneuern oder widerrufen? Geben Sie Zugangsdaten nicht in gemeinsam sichtbare Projektdateien ein und verwenden Sie keine Schlüssel, deren Zugriffsbereich Sie nicht nachvollziehen können.

Achtung: Eine OpenCode-Berechtigungseinstellung, ein Anmeldepasswort oder eine verschlüsselte Verbindung belegt für sich genommen weder eine vollständige Trennung der Forschungsdaten noch die Freigabe durch Datenschutzbeauftragte oder IT-Sicherheit. Stimmen Sie sensible Daten mit den geltenden Regeln Ihrer Hochschule ab.

Die praktische Prüfung sollte deshalb eine Kombination aus Identitäts- und Dateisystemtests sein. Melden Sie sich unter dem vorgesehenen Benutzer an, versuchen Sie den Zugriff auf ein bewusst nicht freigegebenes Testverzeichnis und dokumentieren Sie das Ergebnis. Prüfen Sie anschließend, welche Konfigurationsdateien, Schlüssel und Shell-Umgebungsvariablen der OpenCode-Prozess tatsächlich verwenden kann. Wenn Sie die Herkunft oder Zugriffsgrenze eines Geheimnisses nicht feststellen können, entfernen Sie es aus der gemeinsamen Umgebung und richten Sie einen kontrollierten, projektspezifischen Zugriff ein.

Fernzugriff braucht eine eigene Zugangskontrolle

Ein lokaler Client, ein Zugriff aus dem Hochschulnetz und ein Zugriff über das Internet sind nicht dasselbe. Mit jeder weiteren erreichbaren Netzwerkgrenze müssen Sie erneut prüfen, welcher Dienst lauscht, an welcher Adresse er erreichbar ist und wie zulässige Verbindungen begrenzt werden. Behandeln Sie einen Dienst nicht als lokal, nur weil er auf einem Mac im Labor läuft.

Die OpenCode-Dokumentation zum Web- und Fernzugriff beschreibt den Fernzugriff als Funktion, deren Aktivierung ausdrücklich geprüft werden muss. Kontrollieren Sie die Einstellungen der verwendeten Version, bevor Sie einen Dienst für andere Geräte erreichbar machen. Prüfen Sie insbesondere die konfigurierte Bind-Adresse, die Authentisierung und die erlaubten Netzwerkquellen. Verifizieren Sie die Grenze von einem Gerät, das nicht zugelassen sein soll; eine erfolgreiche Verbindung vom eigenen Rechner belegt nicht, dass andere Zugriffe ausgeschlossen sind.

Apple erläutert die Einrichtung der Dateifreigabe auf dem Mac. Wenn Sie zusätzlich Projektordner über eine Dateifreigabe zugänglich machen, prüfen Sie diese Freigabe getrennt vom OpenCode-Dienst. Eine sichere Konfiguration für den einen Dienst weist keine sichere Konfiguration für den anderen nach. Erfassen Sie, welche Konten freigegeben sind und welche Ordner tatsächlich erreichbar werden.

Für eine Remote-macOS-Umgebung der Forschungsgruppe gilt dieselbe Regel wie für einen Rechner im Labor: Entscheidend sind die eingerichteten Konten und Zugriffsrechte, nicht der Standort der Hardware. Ein Passwort oder eine verschlüsselte Übertragung kann einen Teil des Risikos adressieren, ersetzt aber keine Netzwerkfreigabe, institutionelle Sicherheitsprüfung oder DSGVO-Bewertung. Klären Sie vor der Freigabe, ob die Forschungsdaten dort verarbeitet und gespeichert werden dürfen.

Vor dem Einsatz mit Forschungsprojekten die Grenzen testen

Führen Sie die folgenden Prüfungen zunächst mit Testdaten durch. Halten Sie je Test fest: Benutzerkonto, OpenCode-Verbindungsziel, Projektpfad, verwendete Konfiguration und Ergebnis. So lässt sich später nachvollziehen, ob ein beobachtetes Verhalten an der Anwendung, am Konto oder an der Datei- und Netzwerkfreigabe liegt.

1. Konten abgleichen. Lassen Sie jede vorgesehene Person das eigene macOS-Konto verwenden. Notieren Sie, ob Konten individuell oder gemeinsam genutzt werden. Falls nur ein gemeinsames Konto vorhanden ist, behandeln Sie dessen zugängliche Dateien und Schlüssel bis zum Gegenbeweis als gemeinsam erreichbar.
2. Dienstziel kontrollieren. Prüfen Sie, ob der Client lokal, eigenständig oder mit einem angegebenen Server verbunden ist. Vergleichen Sie die Ziele für alle Personen. Ein unterschiedliches Fenster oder Gerät beweist nicht, dass die Verbindungen auf getrennte Dienstkontexte zeigen.
3. Sitzungen und Konfiguration vergleichen. Starten Sie eine Testsession pro vorgesehenem Zugang. Kontrollieren Sie, welche Sitzungen sichtbar sind und welche Konfiguration geladen wird. Testen Sie nicht mit vertraulichen Prompt-Inhalten oder echten Zugangsdaten.
4. Projektpfade und Schreibrechte verifizieren. Öffnen Sie das vorgesehene Testrepository, bestätigen Sie den absoluten Pfad und schreiben Sie eine harmlose Testdatei. Prüfen Sie anschließend, ob ein anderes Konto die Datei lesen oder verändern kann. Kontrollieren Sie auch Branch und Git-Status.
5. Befehlsausführung begrenzen. Lesen Sie die aktuellen OpenCode-Berechtigungseinstellungen und prüfen Sie, welche Befehle erlaubt sind. Überprüfen Sie, ob der Prozess auf Verzeichnisse außerhalb des Projekts zugreifen kann. Leiten Sie aus einem erfolgreichen Test keine pauschale Sicherheitsgarantie ab.
6. Zugangsdaten zuordnen. Erfassen Sie, welche Schlüssel oder Anbieterzugänge verwendet werden und welchem Konto sie gehören. Entfernen Sie Testgeheimnisse nach der Prüfung. Stimmen Sie den Umgang mit echten Schlüsseln mit der zuständigen IT- oder Datenschutzstelle ab.
7. Netzwerkgrenze testen. Prüfen Sie, ob Fernzugriff aktiviert ist und welche Geräte den Dienst erreichen können. Testen Sie auch eine nicht zugelassene Quelle. Wenn Sie den Ausschluss nicht bestätigen können, lassen Sie den Dienst nicht für weitere Geräte erreichbar.

Wie schränken Sie den Fernzugriff ein und prüfen die Verbindungsgrenze?

Beginnen Sie mit der Frage, ob der Fernzugriff für den Arbeitsablauf überhaupt benötigt wird. Falls nicht, lassen Sie ihn deaktiviert. Falls ja, dokumentieren Sie den Dienst, seine Bind-Adresse, die Authentisierung und die zugelassenen Quellen. Vergleichen Sie diese Werte mit der offiziellen Dokumentation der installierten Version und wiederholen Sie die Prüfung nach relevanten Änderungen.

Entscheidend ist ein Negativtest: Ein nicht zugelassenes Gerät darf nicht allein deshalb Zugriff erhalten, weil es sich im gleichen Netzwerk befindet. Führen Sie diesen Test mit Zustimmung der zuständigen Administration durch. Ändert ein Update die Dienst- oder Authentisierungslogik, testen Sie die Grenze erneut. Die Versionshinweise im offiziellen Änderungsprotokoll helfen, Änderungen zu erkennen; sie ersetzen nicht die Prüfung Ihrer tatsächlichen Konfiguration.

Entscheidung nach nachgewiesener Trennung treffen

Nutzen Sie diese Bedingungen als Entscheidungshilfe:

• Wenn eine Person den Mac verwendet und das Konto nur für dieses Projekt bestimmt ist, können Sie zunächst die dokumentierte Standardkonfiguration testen. Prüfen Sie trotzdem Verzeichnis, Berechtigungen und Zugangsdaten.
• Wenn mehrere Forschende jeweils eigene Projekte bearbeiten, verwenden Sie getrennte macOS-Konten und getrennte Arbeitsverzeichnisse, sofern die Hochschule das zulässt. Prüfen Sie zusätzlich, ob OpenCode-Dienst und Fernzugriff tatsächlich zu den vorgesehenen Konten passen.
• Wenn mehrere Personen denselben OpenCode-Dienst nutzen sollen, geben Sie ihn erst frei, nachdem Sie Sitzungen, Konfiguration, Dateizugriff, Befehlsrechte, Schlüssel und erlaubte Netzwerkquellen einzeln überprüft haben.
• Wenn sich eine Grenze nicht nachweisen lässt, teilen Sie weder dasselbe Benutzerkonto noch dieselbe Sitzung für unterschiedliche Forschungsprojekte. Wechseln Sie zu getrennten Konten oder einer getrennten Umgebung und wiederholen Sie die Tests.
• Wenn vertrauliche Daten oder institutionelle Vorgaben betroffen sind, holen Sie vor dem Betrieb die zuständige Freigabe ein. Eine gemietete oder entfernte Maschine ist keine automatische Datenschutz- oder Sicherheitsfreigabe.

Der Kosten- und Betriebsvergleich hängt vom konkreten Bedarf ab; ohne belegte Angebote lässt sich daraus kein allgemeiner Preisvorteil ableiten.

Wenn die Grenze unklar bleibt, nicht mit echten Projektdaten starten

Ein vorhandener Laborrechner ist oft der naheliegende erste Versuch. Er kann jedoch macOS nicht ersetzen, wenn das Team eine macOS-spezifische Umgebung benötigt. Ein neu gekaufter Mac bindet Budget und muss weiterhin administriert werden. Eine gemeinsame Remote-Maschine erleichtert den Zugriff von verschiedenen Arbeitsplätzen, schafft aber zusätzliche Fragen zu Konten, Netzwerkzugriff und zulässiger Datenverarbeitung. Keine dieser Varianten löst die Isolierung automatisch.

Wenn das Team eine interaktive macOS-Umgebung benötigt, aber vor einer Anschaffung erst Ablauf und Zugriffsgrenzen prüfen möchte, kann eine zeitlich begrenzte Nutzung von metalvnc eine praktische Alternative zum Kauf sein. Vergleichen Sie dazu die verfügbaren Mietoptionen und klären Sie vorab, wie die geplante Nutzung mit den Regeln Ihrer Hochschule vereinbar ist. Informationen zur Nutzung finden Sie in der metalvnc-Hilfe; wenn für die geplante Forschungsumgebung weitere technische Fragen offenbleiben, stehen die Kontaktmöglichkeiten von metalvnc zur Klärung bereit. Behandeln Sie die gemietete Hardware nicht als Mehrbenutzer-Sandbox: Legen Sie Konten und Projektverzeichnisse weiterhin bewusst fest und speichern Sie Forschungsdaten nur dort, wo es Ihre institutionellen Vorgaben erlauben.

Die Entscheidung für OpenCode 2.0 auf einem gemeinsamen Mac sollte deshalb an nachgewiesenen Grenzen hängen. Wenn Sie Sitzungen, Systemkonten, Projektordner, Zugangsdaten und Netzwerkzugriff nicht getrennt erklären und testen können, verwenden Sie keine gemeinsame Benutzersitzung für unabhängige Forschungsprojekte.