OpenCode Web im Browser: Port setzen und Zugriff schützen

OpenCode Web ist die Browser-Oberfläche des OpenCode-Servers. Sie eignet sich für eine Sitzungsübersicht, ein Projekt in einem Browser-Tab oder eine zweite Ansicht neben dem Terminal. Es bleibt ein lokaler Entwicklungsdienst und ist kein gehostetes Konto, das Provider-Zugangsdaten ersetzt.

Der erste Befehl sollte opencode web ohne Hostname-Override sein. Die offizielle Web-Dokumentation beschreibt 127.0.0.1, einen freien Port und das Öffnen des Standardbrowsers. So prüfen Sie Projektordner, Provider, Berechtigungen und Session-Verhalten, bevor Sie etwas freigeben.

Erst danach wählen Sie einen festen Port, einen Netzwerk-Hostname, mDNS oder eine CORS-Regel. Jede Option verändert den Kreis der möglichen Clients. Eine nicht ladende Seite weist meist auf Prozess oder Port hin; unerwünschte Erreichbarkeit ist eine Grenzfrage.

opencode web

Starten Sie den Befehl im Repository, das Sie bearbeiten möchten. OpenCode startet den Web-Server und öffnet den Browser. Lassen Sie das besitzende Terminal sichtbar, um Adresse, Port und Warnungen zu notieren. Eine offene Seite beweist noch nicht, dass Dateien und Modell stimmen.

Für eine wiederholbare Adresse verwenden Sie opencode web --port 4096. Ein fester Port hilft bei Lesezeichen, Scripts und opencode attach, kann aber mit einem anderen Prozess kollidieren. Ermitteln Sie den Besitzer des Ports, statt alle Ports zu veröffentlichen.

Die erste Web-Aufgabe sollte lesend sein: Projekt auflisten, eine kleine Datei zusammenfassen und Session oder Serverstatus prüfen. Danach Git status und Modell im selben Workspace kontrollieren. So bleiben Browser, Prozess, Repository und Provider unterscheidbar.

Ein Port ist eine Nummer am Host; der Hostname bestimmt, welche Interfaces Verbindungen annehmen. 127.0.0.1 ist lokal. --port 4096 ändert nur die Nummer, während --hostname 0.0.0.0 die Erreichbarkeit auf Netzwerkinterfaces erweitert.

mDNS ist in einem vertrauenswürdigen LAN bequem. Das offizielle Beispiel nutzt opencode web --mdns und veröffentlicht opencode.local; mit --mdns-domain lassen sich Instanzen trennen. Discovery verschlüsselt keinen Verkehr und ersetzt keine Anmeldung.

CORS legt fest, welche Browser-Origin Cross-Origin-Anfragen stellen darf. Das kann ein eigenes Frontend benötigen, macht einen freigegebenen Server aber nicht privat. Erlauben Sie nur die exakte Origin und testen Sie sie.

Die offizielle Warnung ist eindeutig: Ohne OPENCODE_SERVER_PASSWORD ist der Server ungeschützt. Für einen kurzen lokalen Test kann das vertretbar sein, nicht für einen Listener, den andere Geräte erreichen. Injizieren Sie das Passwort beim Start und speichern Sie es nicht in opencode.json, Verlauf, Screenshots oder einem committeten .env.

Der Standardbenutzer heißt opencode; OPENCODE_SERVER_USERNAME kann ihn ändern. Diese Zugangsdaten schützen den Web-Server, nicht Provider oder Repository. Prüfen Sie Provider-Schlüssel, OpenCode-Rechte, Mounts und Prozessbenutzer als getrennte Kontrollen.

Vor --hostname 0.0.0.0 prüfen Sie Firewall und Netzwerksegment. Nutzen Sie ein privates Netz, ein kurzlebiges Passwort und einen bekannten Port. Bei Proxy, VPN oder Frontend dokumentieren Sie, wo TLS endet und welche Schicht die Session sieht.

Die Web-Startseite zeigt aktive Sessions und kann neue starten. Prüfen Sie das Projekt vor jedem Prompt. Ein Tab kann nach Prozess- oder Repositorywechsel offen bleiben; kontrollieren Sie den Serverstatus deshalb erneut.

Der Serverstatus trennt Web-Prozess und Coding-Session. Bei fehlendem Modell prüfen Sie Provider und Modell-ID; bei fehlenden Dateien Arbeitsverzeichnis und Benutzer, bevor Sie Prompt oder CLI ändern.

Für beide Oberflächen starten Sie Web und führen in einem zweiten Terminal opencode attach http://localhost:4096 aus. Die offizielle Dokumentation beschreibt gemeinsame Sessions und Zustände. Lassen Sie nur einen klaren Prozess schreiben und prüfen Sie jeden kleinen Diff.

Die offizielle Web-Seite empfiehlt unter Windows WSL für bessere Datei- und Terminalintegration. Das ist wichtig, wenn das Repository auf einem Linux-Pfad liegt, Tools in WSL installiert sind oder PowerShell ein anderes PATH und Home verwendet.

Notieren Sie, wo der Befehl läuft, wo das Repository liegt und welcher Benutzer den Prozess besitzt. Ein Windows-Browser kann WSL erreichen, aber localhost, Firewall und Pfade überschreiten womöglich eine unsichtbare Grenze. Testen Sie zuerst lesend.

Wenn die Seite öffnet, aber Befehle fehlschlagen, vergleichen Sie opencode --version, Verzeichnis, Provider-Variablen und die Shell, die Web startet. Deployment-, VS-Code- und Berechtigungsleitfäden behandeln Nachbarfragen; hier geht es um den Browser-Server.

Beginnen Sie bei Prozess und URL und gehen Sie nach innen. Ein Verbindungsfehler betrifft Prozess, Port, Hostname, Firewall oder CORS. Eine geladene Seite ohne Session betrifft Projekt, Provider, Rechte oder Modell. Alles gleichzeitig zu ändern zerstört den Hinweis.

Bei einem festen Port prüfen Sie den Listener und die Portnummer in der gedruckten URL. Bei Netzwerk-Hostname testen Sie zuerst localhost und Passwort, dann das zweite Gerät. Bei mDNS vergleichen Sie angekündigten Namen und echte Adresse.

Bei unerwartetem Session-Verhalten sichern Sie Startbefehl, Verzeichnis, Modell-ID, Variablenquelle und Git status. Wiederholen Sie eine kurze Leseanfrage und eine kleine Dokumentationsänderung. Stoppen Sie bei Secrets, fremden Dateien oder Pfaden außerhalb des Worktrees.

Web passt, wenn der Browser Projekt und Gespräch leichter prüfbar macht, eine zweite Ansicht des laufenden Servers nötig ist oder ein Team eine reproduzierbare lokale URL braucht. Die TUI bleibt besser für Tastaturarbeit, Shell-intensive Abläufe oder Umgebungen ohne Browser.

Web ersetzt Provider-, Rechte- und Docker-Leitfäden nicht; es verändert nur den Zugang zum Server. Credentials, Dateirechte, Mounts, MCP-Werkzeuge und Git-Review brauchen weiterhin eigene Checks. Verlinken Sie die schmale Anleitung für die nächste Entscheidung.

Ein stabiler Ablauf ist: lokal starten, Projekt und Modell prüfen, vor erweitertem Hostname ein Passwort setzen, Port notieren, TUI nur bei Bedarf anhängen und den Server am Ende beenden. Ein Entwicklungs-Listener wird dadurch nicht zum öffentlichen Dienst.