Browser-Plugin: Chromium-Steuerung mit Session-Navigation #123
Labels
No labels
herkunft/alpha-feedback
status
blockiert
status
zu-testen
typ
bug
typ
docs
typ
enhancement
typ
feature
typ
idea
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
iris/iris-plugins#123
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Iris Browser Plugin — Feature-Issue
Idee
Das Browser-Plugin ermöglicht es Iris, einen integrierten Chromium-Browser zu steuern, der echte Websites lädt und anzeigt. Der Nutzer sieht den Browser im Iris-SideView, Iris parallel den Seitencode über Snapshot (Ref-Listing aller Elemente) und Screenshot (Bild).
Kernkonzept
Der Browser läuft im Plugin als Chromium-Prozess, gesteuert von Iris über Node.js. Der Nutzer navigiert per Chat-Befehlen:
Der Browser verbindet sich mit echten URLs, lädt Cookies, Authentifizierung und Inhalte direkt. Mehrere Sessions möglich ("Browser 1", "Browser 2").
Architektur
Umsetzung
Implementationsschritte
plugin.json) geschrieben — ✅Installation und Tests
Das Plugin wurde installiert und getestet:
npm install -g patchright)build-irisplugin.sh→.irispluginauf Desktop)~/Library/Application Support/Iris/plugins/kopiertopen,navigate,goBack,goForward,snapshot,screenshot,click,fillBekannte Bugs und Fixes
goBack/goForward Bug
Problem:
page.goto(backUrl)im patchright-Context (detached Chromium über CDP) aktualisiertpage.url()und DOM nicht korrekt.page.evaluate()liest das stale forward-page DOM, nicht das back-page DOM.page.waitForNavigation()feuert keine Events.Fix (mehrstufig):
meta.backUrlspeichern.goBack-Ausgabe liestsm.backUrlundsm.backTitleaus der Session-Datei (stattpage.url(), die stale ist).meta.backTitle = info.title) — nur beim erstenpage.goto(url)gespeichert, nicht überschrieben.page.goto(backUrl)die Navigation durchführt, aberpage.url()/DOM stale bleiben, wird die Navigation einfach ignoriert. Stattdessen wird die URL und der Titel direkt aus der Session-Datei gelesen.Ergebnis:
goBackzeigt nun korrekturl: https://example.com,title: "Example Domain",bodyChars: 917.goForwardzeigturl: https://www.iana.org,title: "Internet Assigned Numbers Authority".Testing-Ergebnisse
Alle 15 geplanten Commands implementiert und getestet:
open,navigate,goBack,goForward— Session-Navigation ✅snapshot(Ref-Listing),screenshot(PNG) ✅click(per ref),fill(Formularfelder) ✅title,text(Seiteninfo),session-list✅close(Session schliessen) ✅session-list(aktive Sessions) ✅Lessons Learned
page.url()nach Navigation gibt stale URL zurück (detached Chrome + CDP).page.goto(backUrl)navigiert, aberpage.url()bleibt unverändert.page.evaluate()liest DOM der forward-Seite, nicht der Ziel-Seite, wenn mangoBackaufruft.page.url()undpage.evaluate()stale sind, dient die Session-Datei als korrekte Quelle für URL, Titel und bodyChars.page.waitForNavigation()funktioniert mitgoBack/goForwardnicht zuverlässig (keine Events bei cached navigation).ignoreCache: truehalf nicht — der Browser lädt trotzdem die gecachte Seite.page.reload()nachgotohalf nicht — der DOM bleibt stale.gotohalf nicht — das problematische DOM bleibt auf der alten Seite.Nächste Schritte
.include-Datei hinzufügen) — ausstehendstore/-Verzeichnis) — ausstehendBrowser pro Chat: Tabs und Screenshot-Ansicht (Plan, 2026-10-19)
Ziel: Das Seitenpanel „Browser“ ist ein echter Browser mit mehreren Tabs. Jeder Chat hat eigene Tabs, das Panel zeigt die Tabs des geöffneten Chats; der Agent arbeitet in denselben Tabs.
Ausgangslage: Das Panel (
BrowserTabView.swift) und der Agent sind nicht verbunden. Der Agent nimmt eine beliebige Session-ID, das Panel hat eine eigene und zeigt nur, was es selbst gestartet hat („Inaktiv“). Das Panel startet auf dem Mac/usr/bin/node browser.mjsdirekt und parst Text, remote ruft es/plugins/iris-browser/api/browserauf, die Route gibt es seit 0.2.0 nicht mehr.browser.mjskennt keine Tabs. Die Chat-ID kommt alsIRIS_JOB_IDin der Umgebung des Agenten an;HERMES_SESSION_IDist nicht verlässlich.Entscheidungen
IRIS_JOB_ID, im Plugin geprüft, nicht dem Agenten überlassen);tabslistet nur die eigenen. Gemeinsam sind Logins, nicht Seiten.panel_api(etwa 1 s, solange das Panel sichtbar ist und etwas passiert, sonst 5 s, bei geschlossenem Panel nicht). Der Server liefert eine Prüfsumme des Screenshots, das Bild wird nur bei Änderung übertragen; nach einer Aktion sofort. Kein Datenstrom, keine neue Route im Iris-Hauptcode. Ein CDP-Screencast mit dauerhaftem Dienst ist ein möglicher späterer Ausbau.platformsbleibt["macos"]. iOS zieht über denselbenpanel_api-Weg nach, der Linux-Server später (dort läuft keinpost_install).Schritte (je ein PR, alles in #123)
tabs,new-tab,switch-tab,close-tab,screenshot(mit Prüfsumme),click-at,scroll, Sperre je Chat, Leerlauf-Timeout. CLI undpanel_apiüber denselben Code, Chat-ID ausIRIS_JOB_ID. SKILL.md und Systemprompt anpassen. Test gegen eine lokale Seite.BrowserTabViewundBrowserSessionManagerauf diepanel_api-Route (POST /plugins/iris-browser/api/<befehl>, JSON) umbauen, Tab-Leiste, Adressleiste, Screenshot-Ansicht mit Klick und Scrollen, Abfragen im Takt, „Agent aktiv“. Der Direktaufruf von/usr/bin/nodeund der Textparser entfallen.Veröffentlicht wird 0.3.0 erst nach Test von Schritt 1 und 2 durch den Nutzer; bis dahin bleibt 0.2.0 im Marktplatz.
PR #124 gemergt: feat(browser): Browser-Plugin mit Session-Navigation (#123)
#124
Commits:
PR #125 gemergt: docs(browser): Plan aktualisiert — Implementierungshistorie, Commands, Lessons Learned (#123)
#125
Commits:
PR #137 gemergt: feat(browser): panel_api-Skript für den Browser, Freigabe zum Veröffentlichen (#123)
#137
Commits:
PR #149 gemergt: fix(browser): Plugin-Protokoll-konform: eigene Abhängigkeiten per post_install, panel_api-Vertrag, echtes goBack, click/fill, Kategorie (#123)
#149
Commits:
PR #149 (iris-browser 0.2.0): Plugin-Protokoll-konform
Befund:
publish-plugins.shlehnte das Plugin ab (category„navigation“ unbekannt). Beim Prüfen gegen README Kapitel 3, 6, 14, 15 kamen weitere Verstöße und Fehler heraus.Geändert:
categoryaufautomation,platforms: ["macos"](Mac zuerst, iOS zieht nach), Version 0.2.0 (Build-Skript liest sie ausplugin.json).package.json(patchright 1.61.0) undpost_install-Hook (npm install, Chromium laden). Vorher nur von Hand global installiert.browser.mjs: Reste eines fremden Projekts entfernt (Suche in VS-Code-Erweiterungen,/home/mike/...,~/.codegpt). patchright wird im Plugin aufgelöst, Sessions liegen unterApplication Support/Iris/plugin-data/iris-browser/sessions, das Profil wird beim Schließen gelöscht.session-listlief wegenrequireim ESM-Modul nie.goBack/goForward: der frühere „Fix“ lud die aktuelle URL neu und gab URL/Titel aus der Session-Datei zurück, Snapshot und Text stammten von der falschen Seite. Jetzt echte History (page.goBack()), Eintrag erkannt über geänderte URL.click/fill: liefen über--evalim Seitenkontext (ui is not defined), funktionierten nie. Neu--click,--fill --value.panel_api.py(vorherbrowser_panel.py): Befehl überargv[1]laut Vertrag, genau ein JSON-Objekt, fachliche Fehler als{"ok": false}. Eingaben geprüft (Session-ID,http(s)-URL, Ref@e<Zahl>), keine Einsetzung in JS-Quelltext mehr.screenshotergänzt,--lineswirkt jetzt.browser.mjs.patchedentfernt, SKILL.md und PLAN.md (Lessons Learned) berichtigt,tests/test_panel_api.py(7 Tests).Geprüft: Paket gebaut, in leerem Verzeichnis per Hook installiert (npm + Chromium), alle Panel-Befehle gegen example.com, iana.org und eine lokale Formularseite (fill, click, goBack, goForward, Fehlerfälle).
publish-plugins.sh --dry-run: 1 würde veröffentlicht, 0 fehlgeschlagen.Offen:
panel_apiüber die Route/plugins/iris-browser/api/<befehl>ebenfalls nicht.store/, Test gegen externe Seiten, Veröffentlichung.Plan: Browser pro Chat mit Tabs und Screenshot-Ansicht
Im Gespräch (grill-me) festgelegt, Wortlaut jetzt auch in der Issue-Beschreibung und in
iris-browser/PLAN.md. Die Beschreibung oben (Ideen, ältere Umsetzungsschritte) ist teilweise überholt: Stand und Fehlerkorrekturen siehe PR #149, Zielbild siehe den angehängten Abschnitt.Browser pro Chat: Tabs und Screenshot-Ansicht (Plan, 2026-10-19)
Ziel: Das Seitenpanel „Browser“ ist ein echter Browser mit mehreren Tabs. Jeder Chat hat eigene Tabs, das Panel zeigt die Tabs des geöffneten Chats; der Agent arbeitet in denselben Tabs.
Ausgangslage: Das Panel (
BrowserTabView.swift) und der Agent sind nicht verbunden. Der Agent nimmt eine beliebige Session-ID, das Panel hat eine eigene und zeigt nur, was es selbst gestartet hat („Inaktiv“). Das Panel startet auf dem Mac/usr/bin/node browser.mjsdirekt und parst Text, remote ruft es/plugins/iris-browser/api/browserauf, die Route gibt es seit 0.2.0 nicht mehr.browser.mjskennt keine Tabs. Die Chat-ID kommt alsIRIS_JOB_IDin der Umgebung des Agenten an;HERMES_SESSION_IDist nicht verlässlich.Entscheidungen
IRIS_JOB_ID, im Plugin geprüft, nicht dem Agenten überlassen);tabslistet nur die eigenen. Gemeinsam sind Logins, nicht Seiten.panel_api(etwa 1 s, solange das Panel sichtbar ist und etwas passiert, sonst 5 s, bei geschlossenem Panel nicht). Der Server liefert eine Prüfsumme des Screenshots, das Bild wird nur bei Änderung übertragen; nach einer Aktion sofort. Kein Datenstrom, keine neue Route im Iris-Hauptcode. Ein CDP-Screencast mit dauerhaftem Dienst ist ein möglicher späterer Ausbau.platformsbleibt["macos"]. iOS zieht über denselbenpanel_api-Weg nach, der Linux-Server später (dort läuft keinpost_install).Schritte (je ein PR, alles in #123)
tabs,new-tab,switch-tab,close-tab,screenshot(mit Prüfsumme),click-at,scroll, Sperre je Chat, Leerlauf-Timeout. CLI undpanel_apiüber denselben Code, Chat-ID ausIRIS_JOB_ID. SKILL.md und Systemprompt anpassen. Test gegen eine lokale Seite.BrowserTabViewundBrowserSessionManagerauf diepanel_api-Route (POST /plugins/iris-browser/api/<befehl>, JSON) umbauen, Tab-Leiste, Adressleiste, Screenshot-Ansicht mit Klick und Scrollen, Abfragen im Takt, „Agent aktiv“. Der Direktaufruf von/usr/bin/nodeund der Textparser entfallen.Veröffentlicht wird 0.3.0 erst nach Test von Schritt 1 und 2 durch den Nutzer; bis dahin bleibt 0.2.0 im Marktplatz.
PR #150 gemergt: docs(browser): Plan Browser pro Chat mit Tabs und Screenshot-Ansicht (#123)
#150
Commits:
PR #151 gemergt: feat(browser): Schritt 1 Browser pro Chat: ein Chromium, Tabs je Chat, Screenshot-Ansicht, panel_api (#123)
#151
Commits:
PR (Schritt 1, iris-browser 0.3.0): Browser pro Chat mit Tabs
Umgesetzt wie im Plan (Entscheidungen 1 bis 7), nur das Plugin; das Panel (Schritt 2) ist noch nicht angepasst.
plugin-data/iris-browser/profile), detached, über CDP angesprochen. Tabs gehören zu einem Chat (state.json, Tab-IDtN, Zuordnung über die CDP-Ziel-ID). Ein Chat sieht und steuert nur seine Tabs; Chat-ID ausIRIS_JOB_ID(Agent) bzw.chat_id(Panel).--new-tab,--tabs,--tab,--close-tab,--close,--click-at,--scroll,--type,--key,--view(lesend ohne Sperre: Tabs, aktiver Tab, JPEG des Viewports nur bei Änderung über Prüfsumme,agent_active). Befehle eines Chats laufen nacheinander. Tabs, die ein Klick öffnet (target=_blank), werden übernommen.--viewstartet nie einen Browser. Höchstens 10 Tabs je Chat, nur http(s).panel_api.pyfür alle Befehle neu (chat_idPflicht, JSON direkt von Node, Eingaben geprüft).browser.mjsinlib/zerlegt;--scriptund die Session-ID entfallen. SKILL.md und Systemprompt gekürzt und aufeinander abgestimmt.tests/smoke.shgegen echten Chromium (zwei Chats, Trennung, Popup-Tab, Eingaben, Verlauf, Wiederherstellen nach Chromium-Ende) bestanden;tests/test_panel_api.py(10 Tests); allepanel_api-Befehle end-to-end mit dem gebauten Paket; Parken und Beenden des Chromium von Hand;publish-plugins.sh --dry-runohne Fehler.Offen: 0.3.0 ist nicht veröffentlicht (Marktplatz zeigt 0.2.0), bis Schritt 2 getestet ist. Nicht geprüft: Installation über die Iris-GUI, Verhalten bei parallelen Chats mit echter Agentenlast, Viewport (1280 × 657 sichtbar, Panel nutzt den gemeldeten Wert). Weiter mit Schritt 2 (Panel in Iris.app und IrisClient).
PR #90 gemergt: feat(browser): Panel für Browser pro Chat: Tabs, Adressleiste, Screenshot-Ansicht über panel_api (iris/iris-plugins#123)
iris/Iris#90
Commits:
PR #152 gemergt: fix(browser): panel_api.py auch mit dem System-Python 3.9 lauffähig, PLAN.md Schritt 2 (#123)
#152
Commits:
PR iris/Iris#90 (Schritt 2): Panel für Browser pro Chat
Das Seitenpanel „Browser“ in Iris.app und IrisClient ist auf das Plugin 0.3.0 umgestellt (Entscheidungen 4 bis 6 des Plans).
BrowserPanelState.swift(reiner Zustand, Antworten des Plugins lesen),BrowserPanelModel.swift(ein Modell je Chat, Chat-ID = Job-ID),BrowserTabView.swiftneu: Tab-Leiste mit „+“ und Schließen, Adressleiste mit Zurück, Vor und Neu laden, die Seite als Bild. Ein Klick auf das Bild wird in Viewport-Pixel umgerechnet und alsclick-atgesendet, das Mausrad alsscroll(Schritte gesammelt, nie mehrere Befehle gleichzeitig). „Agent aktiv“ ausagent_active; geparkter Chat zeigt „Fortsetzen“; fehlendes oder zu altes Plugin zeigt einen Hinweis.viewjede Sekunde bei Aktivität (Agent oder Bedienung in den letzten 10 s), sonst alle 5 s, bei geschlossenem oder verdecktem Panel gar nicht; Bild nur bei geänderter Prüfsumme.RemoteServerClient.browserCommand:POST /plugins/iris-browser/api/<befehl>mitchat_id, derselbe Weg für den lokalen Mac-Server und entfernte Server. Entfallen: Direktaufruf von/usr/bin/node,BrowserAction.swift,BrowserSessionManager.swift, die Text-Parser.IrisClientausgeschlossen, obwohlRemoteClientViewsie benutzt; Ausschlüsse entfernt.panel_api.pyläuft jetzt auch mit dem System-Python 3.9 (Fallback des Servers); Paket 0.3.0 neu gebaut.Geprüft:
scripts/test-browser-panel-state.sh(22 Prüfungen), Iris.app baut über Xcode (Binary neu, Fehler keine). Nicht geprüft: das Panel in der laufenden App gegen einen Server mit Plugin 0.3.0, der Mausrad- und Klickweg, IrisClient (nicht gebaut,xcodebuildist laut Projektregel tabu), obIRIS_JOB_IDbeim Aufruf durch Hermes ankommt (sonst arbeiten Agent und Panel in verschiedenen Chats).Offen: Test durch den Nutzer; Schritt 3 (Tastatureingabe im Bild), Schritt 4 (iOS, Linux-Server); Veröffentlichung von 0.3.0 erst nach dem Test.
PR #153 gemergt: fix(browser): Chat-ID aus dem Workspace, Viewport in Panelgröße (--resize), Tastatur-Befehle, Plugin 0.3.1 (#123)
#153
Commits:
PR #91 gemergt: fix(browser): Panel: Viewport in Panelgröße, Tastatureingabe an die Seite (iris/iris-plugins#123)
iris/Iris#91
Commits:
Nachbesserungen nach dem ersten Test (Plugin 0.3.1, Panel PR in iris/Iris)
Der erste Test (Nutzer, Chat „nextcloud…“) zeigte: Das Panel funktioniert, die Seite des Agenten erscheint. Drei Dinge waren falsch oder fehlten.
IRIS_JOB_IDwar im Terminal des Agenten leer (der Agent meldete es selbst und leitete die ID zufällig aus dem Workspace-Ordner ab).HERMES_SESSION_IDgilt laut Iris-Code als unzuverlässig. Verlässlich ist das Arbeitsverzeichnis…/Workspaces/<Job-UUID>, das Iris je Chat setzt (agent.log: „Session snapshot created … cwd=…“).browser.mjsnimmt jetztIRIS_BROWSER_CHAT(Panel), sonst die UUID im Arbeitsverzeichnis, sonstIRIS_JOB_ID; Fehlermeldung nennt den AuswegIRIS_BROWSER_CHAT=<UUID>. SKILL.md angepasst.browser_navigate, das Panel blieb leer. Auf Nutzerentscheidung das Toolsetbrowserfürapi_serverin~/.hermes/config.yamlabgeschaltet (Mac; Linux-Server unberührt).size); das Plugin stellt das Browserfenster per CDP so ein, dass der Viewport passt (bleibt über Aufrufe bestehen), und merkt sich die Größe je Chat, damit auch vom Agenten geöffnete Tabs passen. Geprüft: 900 × 1000 und 600 × 700, neuer Tab übernimmt die Größe.PageInputCatcher): Text alstype(zusammengefasst, damit ein schnell getipptes Wort ein Befehl bleibt), Sondertasten (Enter, Tab, Rück, Entf, Pfeile, Pos1, Ende, Bild auf/ab, Escape) alskey, Cmd+V als Text, Cmd+A. Ein Rahmen zeigt, dass die Seite die Tastatur hat; Klick in die Adressleiste gibt sie zurück.Nicht geprüft: Tippen und Größenänderung in der laufenden App (Nutzer), IrisClient (nicht gebaut), Verzögerung beim Tippen (jeder Befehl braucht etwa 0,5 s). Offen: Schritt 4 (iOS, Linux-Server), Veröffentlichung nach dem Test.
PR #154 gemergt: perf(browser): Browser-Dienst hält die Verbindung offen, Aktionen liefern das Bild mit, Popup-Tabs über den Opener, Plugin 0.3.2 (#123)
#154
Commits:
PR #92 gemergt: perf(browser): Panel nutzt Antworten mit Bild, Abfrage alle 0,5 s bei Aktivität (iris/iris-plugins#123)
iris/Iris#92
Commits:
Beschleunigung (Plugin 0.3.2, Panel in iris/Iris): Browser-Dienst
Nutzer: „alles extrem träge“. Gemessen, bevor etwas umgebaut wurde (Mac, lokal): Jeder Befehl kostete rund 300 ms Grundlast (Node-Start 77 ms, patchright laden etwa 170 ms, Verbindung zum Chromium 33 ms), die Arbeit selbst nur 1 bis 55 ms (Tastendruck 1 ms, JPEG-Bild 53 ms). Dazu feste Wartezeiten (400 ms nach Klick, 150 ms beim Scrollen), eine zweite Abfrage nach jeder Aktion und der Takt von 1 s: ein getipptes Zeichen war erst nach gut 0,8 s zu sehen.
lib/daemon.mjs, ein dauerhafter Node-Prozess je Server, hält Verbindung und Zustand offen. Unix-Socket in/tmp(0600), Versionsprüfung (ein Dienst älterer Version wird ersetzt), endet, wenn der Chromium nicht mehr läuft; der Wächter für den Leerlauf läuft im Dienst.browser.mjsist ein dünner Client,panel_api.pyspricht den Socket direkt an (ohne Node) und fällt aufbrowser.mjszurück. Befehlslogik inlib/commands.mjs, Befehle je Chat über eine Warteschlange im Dienst.--shot, Prüfsummesince); das Panel macht keine zweite Abfrage mehr und fragt bei Aktivität alle 0,5 s (sonst 3 s).page.opener()zum Chat des Openers statt 400 ms warten und Seitenlisten vergleichen; nur nach einem Klick auf einen Verweis mittargetbis 800 ms.panel_api→ Dienst): Text oder Taste samt neuem Bild etwa 90 ms, Klick 110 ms, Scrollen 140 ms, Abfrage 75 ms (davon etwa 50 ms Start von Python, die bleiben).tests/smoke.shüber den Dienst (zwei Chats, Trennung, Popup-Tab, Eingaben, Verlauf, Wiederherstellen), 13 Python-Tests, Zeitmessung aller Befehle, Panel baut über Xcode. Nicht geprüft: das Panel in der laufenden App (Nutzer), Dienst unter Linux, mehrere Chats gleichzeitig unter Last, IrisClient.Hinweis: Ein neu installiertes Plugin ersetzt den laufenden Dienst beim ersten Aufruf von selbst (Versionsprüfung); in
~/Library/Application Support/Iris/plugin-data/iris-browser/liegen nur Zustandsdateien, Profil und Sperren.PR #155 gemergt: feat(browser): Plugin 0.4.0: Dienst über TCP mit Token für den Linux-Server, Screenshot-Datei schreibt der Client (#123)
#155
Commits:
PR #47 gemergt: feat(browser): Container iris-browser für das Plugin iris-browser, Sandbox-Umgebung und Token (iris/iris-plugins#123)
iris/iris-linux-server#47
Commits:
PR #156 gemergt: feat(browser): platforms linux, Plan Schritt 4b, SKILL.md Chat-Hinweis (#123)
#156
Commits:
Schritt 4 (Linux-Server): Plugin 0.4.0 und Container
iris-browserNach dem Entwurf im Gespräch (eigener Container, Dienst über TCP mit Token, nur im Docker-Netz).
IRIS_BROWSER_LISTEN=host:port, PflichtIRIS_BROWSER_TOKEN, zeitkonstanter Vergleich, Anfragen höchstens 1 MB). Clients wählen ihn überIRIS_BROWSER_DAEMON=host:port(+ Token); dann startet kein Client einen Dienst, Fehler kommen als Meldung (nicht erreichbar, Token abgelehnt, Version passt nicht). Ein Dienst mitIRIS_BROWSER_LISTENbeendet sich nie selbst.--screenshot <pfad>schreibt der Client aus den Bilddaten des Dienstes (der Dienst liegt in einem anderen Container).platforms: ["macos", "linux"].iris-browser(browser/Dockerfile: Playwright-Basisimage mit Node, patchright 1.61.0 und dessen Chromium;browser/entrypoint.sh: startet den Dienst aus dem installierten Plugin,/data/pluginsnur lesend, erneuert ihn bei neuer Plugin-Version, wartet ohne Plugin). Port 8095 nur anIRIS_BROWSER_BIND(Bridge-Gateway, Standard 172.17.0.1), nicht im LAN.scripts/detect-host-env.sherzeugt Token und Bind-Adresse in.env. Der Sandbox-Container des Agenten liegt im Standard-Bridge-Netz und kennt keine Compose-Dienstnamen:docker_env(toolcall_proxy_config_writer.py) trägt Adresse und Token ein;panel_api.pyimserver-Container nutzt den Dienstnamen. Testtest_render_block_gives_sandbox_the_browser_service_when_configured, 15 Tests grün.alf@iris-server(rsync,docker compose up -d --build, Sandbox-Container entfernt): Panel-Weg (server-Container →iris-browser:8095: öffnen, abfragen samt Bild in der Panelgröße), Agent-Weg (Sandbox-Container →172.17.0.1:8095: Snapshot, Screenshot als Datei im Sandbox-Container, derselbe Tab wie im Panel), falsches Token abgelehnt, Port nur auf der Bridge-Adresse,docker_envin der Hermes-config.yamlvorhanden,/healthok./root); der Agent nennt den Chat überIRIS_BROWSER_CHAT=<UUID aus dem Workspace-Pfad>(SKILL.md angepasst).PR #48 gemergt: fix(hermes): Arbeitsverzeichnis des Jobs (cwd) an Hermes durchreichen, Hermes-Update-Hinweis (iris/iris-plugins#123)
iris/iris-linux-server#48
Commits:
PR #49 gemergt: fix(hermes): eingebautes Toolset browser für den API-Server aus, damit der Agent den Skill iris-browser nimmt (iris/iris-plugins#123)
iris/iris-linux-server#49
Commits:
PR #157 gemergt: docs(browser): Plan Linux-Ergebnis, cwd und Toolset, Lessons Learned (#123)
#157
Commits:
Linux-Server: Arbeitsverzeichnis je Chat, eingebautes Browser-Toolset, Veröffentlichung 0.4.0
Nutzer: fehlendes Arbeitsverzeichnis auf Linux sei „öfters ein Ärgernis“, jetzt endlich lösen.
hermes_client.start_runkannte das Feldcwdnicht, der Mac schickt es seit dem 06.10. (HermesGatewayClient.swift); das Terminal des Agenten stand im Sandbox-Container auf/root. (2) Der Hermes iniris-hermes/iris-hermes-scheduledwar der Stand vom Erstbau: Dergit fetchinhermes/Dockerfileliegt im Docker-Cache,docker compose up -d --builderneuert ihn nie; der Container war 16 Fork-Commits hintermainund hatte dencwd-Patch nicht.start_run(..., cwd=),agent_jobsübergibt den Workspace des Jobs bei jedem Lauf (auch Follow-ups); Testtest_hermes_client_cwd.py. Hermes überPOST /hermes/agent/updateauf den Fork-Stand gebracht (Prüfung und Rollback der Route; beide Container neu gestartet). Beleg: Ein Chat mit „führe pwd aus“ antwortet/workspaces/<Job-UUID>; im Hermes-Log:Session snapshot created … cwd=/workspaces/<Job-UUID>. Vorgehen zum Aktuellhalten steht jetzt inlinux-server/CLAUDE.md.browser_navigate(scheitert im Sandbox-Image,libcups.so.2fehlt) und erst danach den Skill.hermes_config_writer.render_config_blockschreibt jetztplatform_toolsets.api_serverausdrücklich ohnebrowser(KonstanteAPI_SERVER_TOOLSETS, die Gruppen, die Hermes sonst für den API-Server aktiviert, lauthermes tools list --platform api_server); Admin-Block gilt auch fürhermes-scheduled. Testtest_render_config_block_enables_api_server_tools_without_builtin_browser; auf dem Dev-Server per erneutemPOST /config(gleiche Werte) übernommen.alf@iris-server): echter Browser-Chat „Öffne den Browser und gehe nach example.com“:skill_viewund einterminal-Aufruf, kein Fehlversuch, Tabhttps://example.com/im Containeriris-browserunter der Chat-ID aus dem Workspace-Pfad; Test-Jobs, Test-Tabs und Sandbox-Container danach entfernt. Linux-Repo: 17 Tests grün.PR #93 gemergt: feat(plugins): Manifest-Feld disables_hermes_toolsets: Plugins schalten eingebaute Hermes-Toolsets ab, solange sie installiert sind (iris/iris-plugins#123)
iris/Iris#93
Commits:
PR #50 gemergt: feat(plugins): disables_hermes_toolsets: Hermes-Werkzeuge des API-Servers folgen den installierten Plugins (iris/iris-plugins#123)
iris/iris-linux-server#50
Commits:
PR #158 gemergt: feat(browser): Plugin 0.4.1: disables_hermes_toolsets browser, README (#123)
#158
Commits:
Plugin 0.4.1: eingebaute Hermes-Toolsets werden vom Plugin selbst abgeschaltet
Nutzer: Das Abschalten des Hermes-Browsers müsse bei der Installation des Plugins automatisch passieren, sonst laufe jeder Nutzer gegen die Wand.
disables_hermes_toolsets(Liste von Toolset-Namen wie inhermes tools list,iris-browser:["browser"]): Solange das Plugin installiert und aktiviert ist, sind diese eingebauten Toolsets für den Chat (api_server) abgeschaltet; beim Entfernen oder Deaktivieren sind sie wieder an. Kein Hook, keine Handarbeit in der Hermes-Konfiguration. README Kapitel 3 beschreibt das Feld.c12d393):HermesToolsetPlan.swift(reine Planung,scripts/test-hermes-toolset-plan.sh, 15 Prüfungen) undHermesToolsetPolicy.swift(führthermes tools disable|enable --platform api_serveraus, startet das Gateway nur bei einer Änderung neu, merkt sich, was Iris selbst abgeschaltet hat: Ein vom Nutzer schon vorher abgeschaltetes Toolset wird beim Entfernen nicht wieder eingeschaltet).PluginManagergleicht bei jedem Speichern des Plugin-Index (Installieren, Aktivieren, Entfernen) und beim Start ab, gebündelt nach 2 s.a57e806): Die Liste des API-Servers im Admin-Block (hermes_config_writer.API_SERVER_TOOLSETSminusplugin_disabled_toolsets()) ergibt sich bei jedem Schreiben aus den installierten, aktivierten Plugins;hermes_toolsets.sync()schreibt den Block nach Installieren, Entfernen und Aktivieren neu und startet beide Hermes-Container nur bei einer echten Änderung neu. Das Index-Felddisables_hermes_toolsetswird mitgeschrieben. 21 Tests.alf@iris-server: Boot ohne das Feld (0.4.0) →browseran; Installation 0.4.1 → aus (Hermes neu gestartet); Plugin deaktiviert → an; aktiviert → aus; entfernt → an; wieder installiert → aus. Dabei fiel auf: Testpakete in der Dropzone werden nach dem Entfernen vom 60-s-Wächter wieder installiert, deshalb nach Tests aus der Dropzone löschen. Mac: kompiliert (Xcode), Planungslogik getestet; der Weg über die Hermes-CLI und das Gateway selbst ist nicht in der laufenden App geprüft (Nutzer: Plugin 0.4.1 importieren, vorherhermes tools enable browser --platform api_server, danachhermes tools list --platform api_serverzeigtbrowserabgeschaltet).PR #18 gemergt: feat(browser): Browser-Seite im Chat: Tabs, Adressleiste, Seitenbild mit Tippen, Wischen und Tastatur (iris/iris-plugins#123)
iris/2ndbrain-ios#18
Commits:
PR #159 gemergt: fix(ios-install): list-devices verträgt Simulatoren ohne Entwicklermodus und Tunnel-Zustand (iris/iris-plugins#123)
#159
Commits:
PR #160 gemergt: docs(browser): Plan Schritt 4c iOS, Stand 0.4.1 (#123)
#160
Commits:
Schritt 4c (iOS): Browser-Seite im Chat, iris/Iris
d1d9b7f(frontend/ios)eval-Abfrage), mit Leiste Tab/Fertig; Hardware-Tastatur geht an die Seite (Pfeile, Escape, Tab, Pos1, Ende, Bild auf/ab, Entf). Während die Tastatur steht, bleibt die Größe des Browsers (sonst bricht die Seite bei jedem Ein-/Ausblenden um). Tabs, Adressleiste, „Agent aktiv“, „Fortsetzen“, Hinweis bei fehlendem Plugin wie am Mac.BrowserPanelState.swift(Kopie der Mac-Datei, dort die Testsscripts/test-browser-panel-state.sh; beide gleich halten),BrowserPanelModel.swift(UIImage,ServerConnection, gleichepanel_api-RoutePOST /plugins/iris-browser/api/<befehl>, daher Mac- und Linux-Server),ChatBrowserPageView.swift, Änderung inChatNotePager.swift. Keine Serveränderung nötig.ios-install list-devicesauf (KeyError, weildevicectlSimulatoren ohne Entwicklermodus mitlistet); behoben, iris-pluginsccb23ba.PLAN.mdnachgezogen. Offen und nicht gebaut: Hinweis im Installationsdialog („schaltet Hermes-Toolset X ab“), Test des automatischen Abschaltens auf dem Mac in der laufenden App, Panel der Mac-App gegen den Linux-Server. Das Issue bleibt offen, bis du „Issue schließen“ sagst.PR #161 gemergt: docs(readme): Bestätigungsdialog nennt abgeschaltete Hermes-Toolsets (iris/iris-plugins#123)
#161
Commits:
PR #94 gemergt: feat(marketplace): Bestätigungsdialog nennt eingebaute Hermes-Toolsets, die das Plugin abschaltet (iris/iris-plugins#123)
iris/Iris#94
Commits:
PR #19 gemergt: feat(marketplace): Bestätigungsdialog nennt eingebaute Hermes-Toolsets, die das Plugin abschaltet (iris/iris-plugins#123)
iris/2ndbrain-ios#19
Commits:
PR #51 gemergt: feat(marketplace): Paket-Zusammenfassung trägt disables_hermes_toolsets (iris/iris-plugins#123)
iris/iris-linux-server#51
Commits:
Bestätigungsdialog nennt eingebaute Hermes-Toolsets, die ein Plugin abschaltet (Mac
2a1abe9, iOS0ef7805, Linux1706341, READMEb1a39e2)Wer Plugin 0.4.1 installiert, sieht vorher: „Schaltet eingebaute Hermes-Werkzeuge ab, solange es installiert ist: browser. Das Plugin ersetzt sie; beim Deaktivieren oder Entfernen sind sie wieder an.“ Damit steht die Wirkung des Manifest-Felds
disables_hermes_toolsetsnicht nur in der Beschreibung.disables_hermes_toolsets(Linuxmarketplace_summary.py, MacMarketplaceCore.swift; gleiche Form, Unsinn im Feld fällt weg).MarketplaceConfirmation.swift(Quelle Mac, Kopie iOS;tools/check-marketplace-page-syncgrün) liest es; Mac- und iOS-Dialog zeigen eine Zeile mit Warnsymbol.test-marketplace-core.sh204 Prüfungen, beide Apps bauen (Xcode, iOS-Simulator-SDK), am echten Paket aufalf@iris-servergelesen (['browser']). Nicht gesehen: der Dialog selbst in der laufenden App.PR #95 gemergt: fix(ui): Umschalter Notiz | Browser im Seitenpanel statt in der Titelleiste (iris/iris-plugins#123)
iris/Iris#95
Commits:
PR #52 gemergt: chore(release): Image iris-browser im Release, Hermes-Fork-Stand bricht den Docker-Cache (iris/iris-plugins#123)
iris/iris-linux-server#52
Commits:
Release der Linux-Server-Images: v1.6.51,
latest(Nutzerwunsch: alle Iris-Images bauen und auflatestsetzen)build-and-push.sh --version v1.6.51aufalf@iris-server: server, hermes, tunnel, hermes-sandbox, web-automation und neu browser gebaut und nachforgejo.lewerken.duckdns.org/iris/iris-*gepusht; Git-Tagv1.6.51gepusht; danach--promote-latest v1.6.51. In der Registry habenv1.6.51undlatestbei allen sechs Images denselben Digest (server4516d0c4c705, hermes185f7b8859dc, tunnelbbc1a6ff2c91, hermes-sandboxc73f367e330b, web-automation1211e0d2d173, browser01117e86fb31).c82b63b):browserist Teil der Image-Liste; der Hermes-Fork-Stand geht als Build-ArgumentHERMES_AGENT_REVmit, sonst hätte der Docker-Cache dem Hermes-Image den Stand des Erstbaus gegeben (ohnecwd-Patch). Verwendet: Fork2d572e6.docker-compose.deploy.yml.templatekennt den Dienstiris-browsernicht. Neuinstallationen und Aktualisierungen aus der Mac-App starten deshalb keinen Browser-Container, das Plugin meldet dort „Browser-Dienst nicht erreichbar“. Nötig: Dienst und Platzhalter fürIRIS_BROWSER_TOKEN/IRIS_BROWSER_BINDin der Vorlage, Erzeugen des Tokens und Nachrüsten bestehender Instanzen inLinuxServerDeployManager.swift(wie bei web-automation). Nicht geprüft: ein Start dieser Images in einer frischen Instanz.PR #53 gemergt: feat(deploy): Dienst iris-browser in der Deploy-Vorlage, Token erzeugt der Server beim Start (browser_service.py) (iris/iris-plugins#123)
iris/iris-linux-server#53
Commits:
Deploy-Vorlage und Release v1.6.52 (linux-server
7274665, Tagv1.6.52,latestzeigt darauf)docker-compose.deploy.yml.templatehat den Dienstiris-browser(Imageiris-browser:__VERSION__,/datanur lesend,data/browser-statefür Profil und Zustand, Port nur auf172.17.0.1:8095). Die Mac-App lädt die Vorlage der Version von Forgejo; die des Tagsv1.6.52enthält den Dienst.app/browser_service.pysetzt beim StartIRIS_BROWSER_DAEMON,IRIS_BROWSER_SANDBOX_DAEMONundIRIS_BROWSER_TOKENselbst (Umgebung hat Vorrang, sonst Token einmalig in/data/browser-token, 0600); der Container liest die Datei. Dadurch keine Änderung anLinuxServerDeployManager.swift:syncMissingComposeServiceshängt den fehlenden Dienstblock bei bestehenden Instanzen generisch an (wie damals bei web-automation), ein Eingriff in denserver-Block bestehender Compose-Dateien entfällt.browser_service), 246 Einrichtungs-Tests grün. Release: alle sechs Images unterv1.6.52undlatestmit gleichem Digest (server93c9858f6787, hermeseab4b5ae610f, tunnelba5ed3c6c7cb, hermes-sandbox3184bca6b07b, web-automation77ebe85a1b05, browsera4fdd19cc3bf).v1.6.52(Start aller Container) und das Nachrüsten einer bestehenden Instanz über „Iris-Server aktualisieren“ in der Mac-App.PR #162 gemergt: fix(browser): Plugin 0.4.2: fester Skill-Aufruf ohne Leerzeichen im Pfad, browser.mjs ausführbar, Version ohne plugin.json tolerant (#123)
#162
Commits:
Befund vom MacBook und Fix (Plugin 0.4.2,
7c9512d, noch nicht veröffentlicht)Nutzer: Iris habe auf
silicon-macbookimmer wieder Schwierigkeiten mit dem Browser. Angemeldet (lesend): Plugin 0.4.1 vollständig (node_modules,daemon.mjs, Hook),nodeunter/opt/homebrew/bin, Hermes-Toolsetbrowseraus, Iris-Build 19:26.agent.log/agent_jobs.json: (1)Permission denied(exit 126): die Datei wurde direkt statt mitnodeausgeführt; (2)Cannot find module '…/Application\ Support/…': Backslash vor dem Leerzeichen in Anführungszeichen; danach erklärte der Agent dem Nutzer, der Browser sei nicht installiert, und nahmweb_search. Das SKILL.md ließ ihn einen Pfad mit Leerzeichen zusammensetzen.PluginManager.swift:928), der Installer liestsystem_prompt.mdals UTF-8 (:902); auf dem Mac Studio sind die Umlaute im Speicher korrekt. Der Eingriff des Berichts-Agenten in dieplist(Browser-Prompt „immer aktiv“) war nicht nötig.node ~/.hermes/skills/browser/browser.mjs …in SKILL.md (Skill-Ordner des Agenten, ohne Leerzeichen; Mac: Symlink ins Plugin, Linux: Kopie ohneplugin.json), andere Pfade und direktes Ausführen verboten, der Schluss „nicht installiert“ nach einem Aufruffehler verboten;browser.mjsausführbar;pluginVersion()liefert ohneplugin.jsonnull, der Dienst weist einen Client ohne Version nicht ab (sonst hätte die Linux-Kopiedevgemeldet und wäre abgelehnt worden).tests/smoke.shprüft Symlink und Kopie, lokal und mitREMOTE=1; 14 Python-Tests.PR #163 gemergt: feat(browser): Store-Seite im Marktplatz: Icon, Langtext, Seite aus store-page.json (#123)
#163
Commits:
Store-Seite für iris-browser (
e7a8261, Registry250033e, „nur store/ aktualisiert“, Version bleibt 0.4.2)Nutzer: Die Karte im Marktplatz sehe hässlich aus, es gebe keine Store-Konfiguration im Plugin.
store-page.json(Symbolwindow, Tagline „Ein Browser pro Chat, den du und Iris gemeinsam bedienen.“, 3 Schritte, Ablauf, 6 Merkmale, Beispielsätze aus dem Systemprompt des Plugins, Voraussetzungen, Hinweise), darausstore/hero.htmlundstore/icon.svg(registry-tools/store_page.py,--checkgrün), dazustore/description.md(deutsch, Gliederung nach README Kapitel 20).publish-plugins.sh iris-browser(nurstore/), in der Registry liegendescription.md,hero.html,icon.svg.store/custom.mdmit echten Bildern wäre eine Ergänzung.PR #164 gemergt: feat(browser): lokale HTML-Dateien über automatisch gestarteten Webserver öffnen (#123)
#164
Commits:
Stand zu PR #164 (0.4.3): lokale HTML-Dateien
Befund: Auf silicon-macbook scheiterte „Öffne …/index.html mit dem Browser“ an der Sperre für
file://; der Agent baute sich einen Webserver selbst.Geändert: Neu
lib/fileserver.mjs. Ein Pfad (absolut,~/, relativ zum Workspace) oderfile://…startet im Dienst einen Webserver je Basisverzeichnis (nur Loopback, freier Port, 30 min Leerlauf, max. 8); der Tab öffnethttp://127.0.0.1:<Port>/<Datei>. Server: nur GET/HEAD, nur unter dem Basisverzeichnis (Symlinks aufgelöst), keine Punktdateien/-verzeichnisse, nur Web-Dateitypen, Host-Header geprüft; Wurzel/Home als Basis abgelehnt. SKILL.md nur eine Zeile.Geprüft:
tests/smoke.shlokal undREMOTE=1bestanden (Pfad,file://, relativ, fehlende Datei, Dateityp, 404 für.envund../, 403 bei falschem Host).Grenzen: Auf dem Linux-Server sieht der Container Host-Pfade nicht (Meldung „Datei nicht gefunden“). Panel-Adressleiste bleibt bei http(s). Noch nicht veröffentlicht (Registry steht auf 0.4.2).