4b163382bc
Remote Control blocked `/previews/*`, so a phone or browser paired through the tunnel had no web preview at all: the entry was hidden and the agent's dev server stayed out of reach. Previews now work there, behind a host setting that is on by default. A preview's sandboxed document sends neither the device cookie nor a usable `Origin`, so the Remote Control gate admits a live `/previews/<token>/…` capability on its token alone, as local listeners already do, while the host's Web previews switch is on. The ingress, which refused every WebSocket, now admits preview upgrades only: `admitRemoteUpgrade()` parses the target exactly as the preview proxy does and the manager hands the socket to the application's path-preview upgrade handler, never to the shared upgrade event (so `/previews/<token>/../../sidecars/…` cannot reach another handler). Every other upgrade still gets 404. The switch lives in Settings → Remote Access → Remote Control. Only the host can change it (`PUT /api/remote-control/previews`); the registry stores only the opt-out. Turning it off refuses later preview requests, including the Referer-based root-relative asset fallback, and closes live preview WebSockets; remote `/api/meta` then reports `previewsUnavailable`, which hides Open web preview on paired devices. Exposing previews through a public tunnel makes their address a bearer credential, so path-proxied preview responses now carry `Content-Security-Policy: sandbox` with the iframe's own flags (one shared constant, `previews/sandbox.ts`) and `Referrer-Policy: same-origin`, on every content type. A preview document opened outside its iframe stays an opaque origin instead of running with CodeNomad's origin and device cookie, and the capability path stays out of Referer headers to other sites. Such a standalone document then behaves like the preview iframe: its root-relative resources rely on the runtime bridge's path rewriting, without the Referer fallback. The per-token preview.localhost host keeps its own origin and headers. Help (Remote Control, mobile and client overview pages, all ten locales), dev-docs/REMOTE_CONTROL.md, architecture.md and UI_SHELL.md describe the behavior; the switch label and caption are translated in all locales. Validation: a Remote Control surface test drives the real application through the ingress: a preview page and an `Origin: null` form post work without a device cookie and carry the sandbox and referrer headers, unknown tokens and non-preview or dot-segment upgrades get 404, a preview WebSocket upgrades, a paired device cannot change the switch, and turning it off closes the live WebSocket, refuses the preview and its Referer asset fallback, and flags the metadata. Registry, metadata and proxy tests cover persistence of the opt-out, the flag and the headers per entry point; browser tests cover the switch and the conversation header with previews on and off.
7.9 KiB
CodeNomad-Hilfe
Diese Anleitung beschreibt die Bedienung des aktuellen CodeNomad-Desktop- oder Browser-Arbeitsbereichs mit Ihrem OpenCode-Dienst. Im Mittelpunkt stehen die Bedienelemente, Ausführungsgrenzen und Wiederherstellung von CodeNomad – keine Einführung in die OpenCode-Konfiguration und kein Versionsarchiv.
Zuerst lesen
CodeNomad verbindet Ihren Arbeitsbereich mit einem gemeinsam genutzten OpenCode-Hintergrunddienst. Sitzungen und Nachrichten gehören zu OpenCode; Tabs, Eingabeentwürfe und Layout zum CodeNomad-Client. Das Schließen eines Projekt-Tabs schließt das Projekt in CodeNomad; Sitzungen laufen in OpenCode weiter und sind nach erneutem Öffnen des Projekts wieder verfügbar. CodeNomad zu schließen beendet nicht OpenCode.
- Prüfen Sie die Host-Anforderungen und die OpenCode-Einrichtung.
- Öffnen Sie ein Projekt und wählen Sie dann Agent, Modell und Denkaufwand der Unterhaltung.
- Prüfen Sie vor Änderungen an Zugangsdaten, Dienstneustarts oder dem Löschen von Verlauf den betroffenen Geltungsbereich. Andere Clients können denselben nativen Dienst verwenden.
Die öffentliche Hilfe funktioniert ohne CodeNomad, dessen Backend oder Anmeldung. Hilfe → CodeNomad-Hilfe auf dem Desktop und Hilfe öffnen in der Befehlspalette öffnen sie separat in der aktuellen Oberflächensprache. Sprachänderungen übersetzen keine gespeicherten Unterhaltungen.
Einstellungen öffnet in einem lokalen Desktop-Client das native Fenster Einstellungen; Browser- und Remote-Clients verwenden eingebettete Einstellungen. Pfade wie Einstellungen → Anbieter bezeichnen auf beiden Oberflächen denselben Einstellungsbereich.
Für einen eigenständigen Browser-Arbeitsbereich auf einem vorbereiteten Host erklärt die Server-Anleitung diesen Start sowie die Anforderungen an Authentifizierung und TLS:
npx @neuralnomads/codenomad --generate-token --launch
Client auswählen
| Funktion | Lokaler Desktop | Direkter Browser oder Remote-Server-Fenster | Gekoppeltes Fernsteuerungsgerät |
|---|---|---|---|
| Projekte, Unterhaltungen, Dateien und Verlauf | Ordner und native Sitzungen des Backends | Ordner und Sitzungen des verbundenen Servers | Autorisierte Arbeitsbereichsoberflächen des Hosts |
| Native Einstellungen und Desktop-Fenster | Verfügbar | Browser-/Remote-Einstellungen bleiben im Client | Nur auf dem Host verfügbare Desktop-Steuerung nicht verfügbar |
| Browser-Vorschau der Sitzung | Nativ in Electron und Windows-Tauri; iframe auf anderen Tauri-Plattformen | iframe, soweit verfügbar | iframe, solange der Host Web-Vorschauen erlaubt (Standard) |
| Native Desktop-/Browser-Automatisierung | Zugeordnete lokale Fenster/Vorschauen | Kein Ersatz für native Desktop-Automatisierung | Nur auf dem Host verfügbare Automatisierungs-Endpunkte nicht verfügbar |
| Authentifizierung | Lokale Ersteinrichtung oder Passwortsitzung | Server-Passwortsitzung | Zugangsdaten des gekoppelten Geräts |
| PWA-Installation | Native App oder Browser verwenden | Browserabhängig; sicherer Kontext erforderlich | Browserabhängig; Kopplung weiterhin erforderlich |
Die genauen Grenzen erläutern Browser-Vorschauen und SideCars, Fernsteuerung und Mobil/PWA. Ein Remote-Fenster macht das Dateisystem Ihres Geräts nicht zum Server-Arbeitsbereich.
Zuständigkeit für den Zustand verstehen
| Begriff | Bedeutung in CodeNomad |
|---|---|
| Projekt-Tab / Arbeitsbereich / Instanz | Eine CodeNomad-Verbindung zu einem ausdrücklich geöffneten Ordner; mehrere Tabs können den gemeinsamen Dienst nutzen. |
| Unterhaltung / Sitzung | Nativer OpenCode-Verlauf und Ausführung, die einem Verzeichnis zugeordnet sind. |
| Familie | Eine Unterhaltung mit ihren rekursiven Untersitzungen; relevant für Verschieben, Aktivität, Yolo und Missionssteuerung. |
| Worktree | Ein zugehöriger Repository-Checkout, der zum Durchsuchen oder als Sitzungsort ausgewählt wurde. Ihn zu durchsuchen verschiebt keine Unterhaltung. |
| Location | Der verzeichnisbezogene native Laufzeitkontext von OpenCode; das Schließen eines Projekt-Tabs schließt das Projekt nur in CodeNomad und entfernt keine native Location. |
| CodeNomad-Backend | Der Server für Arbeitsbereiche, Git, Authentifizierung und Client-Verbindungen. Sein Konto und seine Umgebung bestimmen den Dateisystemzugriff des Backends. |
| Konfiguration | CodeNomad-Einstellungen im Konfigurationsverzeichnis des Servers; globale/projektbezogene OpenCode-Einstellungen haben ihren eigenen nativen Geltungsbereich. |
| Fenster | Eigene Tabs, Navigation, Entwürfe und wiederhergestellte Ansicht. Der native Verlauf wird gemeinsam genutzt, nicht für jedes Fenster kopiert. |
| Desktop-Datenprofil | In den Einstellungen gewählter nativer/Client-Speicher; isoliert nicht automatisch OpenCode-Sitzungen oder jede gemeinsam genutzte Konfiguration. |
Das Arbeitsbereichs-Stammverzeichnis begrenzt, welche Ordner CodeNomad öffnet; es ist keine Agenten-Sandbox. Lesen Sie die Sicherheitshinweise, bevor Sie einen Host zugänglich machen oder umfassenden Werkzeugzugriff erlauben.
Nach Aufgabe erkunden
| Aufgabe | Anleitung |
|---|---|
| Arbeitsbereich installieren oder bereitstellen | Installation, Server-Referenz, Netzwerk und TLS |
| Über Checkouts und Unterhaltungen hinweg arbeiten | Projekte, Unterhaltungen, Dateien |
| Verlauf finden oder sicher bereinigen | Verlauf |
| Native Fragen und Berechtigungsanfragen beantworten | Berechtigungen |
| Begrenzte oder tägliche Arbeit koordinieren | Missionen |
| Ausführung und Integrationen konfigurieren | OpenCode, Anbieter, Integrationen |
| Weiteres Gerät verbinden | Fernsteuerung, Sicherheit, Mobil |
| Arbeitsbereich anpassen | Einstellungen, Tastenkürzel, Sprache, Erweiterungen |
| Native Anwendung verwalten | Desktop, Browser-Vorschauen und SideCars, Updates |
| Probleme untersuchen oder beitragen | Fehlerbehebung, Support und Quellcode-Builds |
Arbeit beobachten, ohne sie zu verändern
Das Status-Panel zeigt die Anbieternutzung und nativen Hintergrund-Shells der aktiven Sitzung. Unterhaltungsstatus und Unteraktivität kennzeichnen arbeitende, komprimierende und auf Eingaben wartende Sitzungen. Eine Hintergrund-Shell zu beobachten ist etwas anderes, als im Eingabefeld eine Shell-Anfrage zu senden oder einen separat gehosteten Terminal-SideCar zu verwenden.
- Öffnen Sie Status → Hintergrund-Shells für die Location der ausgewählten Unterhaltung (oder den geöffneten Arbeitsbereich, wenn keine Unterhaltung ausgewählt ist).
- Prüfen Sie Befehl, Shell, Verzeichnis, Status, PID und Exit-Code, soweit vorhanden; wählen Sie Ausgabe anzeigen für die verfügbare native Ausgabe.
- Zum Entfernen verwenden Sie während der Ausführung Stoppen und entfernen oder nach dem Ende Entfernen und bestätigen das Ziel.
Das Entfernen einer laufenden Shell beendet diesen Prozess; das Schließen ihres Ausgabefensters nicht. Aktualisieren/Wiederverbinden liest den aktuellen nativen Zustand, statt verpasste Ausgabeereignisse zu rekonstruieren.
Anzeigeschnappschüsse werden nach nativen Änderungen, Wiederverbindungen und bei sichtbarem Bedarf aktualisiert. Sie sind keine garantierten Wiederholungsprotokolle. Ist ein Ergebnis ungewiss, aktualisieren Sie vor dem Wiederholen einer Änderung den maßgeblichen Zustand; senden Sie nicht allein wegen einer verpassten Benachrichtigung oder eines verpassten Ereignisses erneut.