Einstellungen und Anpassung

In CLYE AI kannst du Assistenten und Gruppen an ihren Einsatzzweck anpassen. Dafür musst du keine technischen Details kennen. Wichtig ist nur zu wissen, welche Arten von Einstellungen es gibt und wann sie sinnvoll sind.

Wichtig ist dabei: Du siehst nicht automatisch alle Einstellungsbereiche. Welche Punkte verfügbar sind, hängt vom Bereich und von deiner Rolle ab.

Wann Einstellungen wichtig werden

Einstellungen sind relevant, wenn:

• ein Assistent anders reagieren oder arbeiten soll
• Zugriffe angepasst werden müssen
• Wissen, Quellen oder Werkzeuge ergänzt werden
• Zusammenarbeit für ein Team sauber eingerichtet werden soll

Typische Einstellungsbereiche

Je nach Bereich können unter anderem diese Themen wichtig sein:

• Allgemeine Angaben wie Name, Beschreibung oder Zweck
• Persönlich für deinen eigenen Bereich, dein Profil oder individuelle Präferenzen
• Hinweise für Einführungen und Onboarding in einem Bereich
• Berechtigungen für Zugriff und Zusammenarbeit
• Datenbanken für angebundene strukturierte Daten, Tabellen und Auswertungen im jeweiligen Bereich
• Agent Plugins oder Werkzeuge für zusätzliche Fähigkeiten eines Assistenten
• Ablage oder RAG für den nutzbaren Wissenskontext
• Datenbanken oder Tabellenansichten für strukturierte Datenarbeit im passenden Bereich
• Automationen für wiederkehrende Abläufe
• Feedback oder Dashboard, wenn ein Assistent bereits produktiv genutzt wird
• Q&A oder ähnliche Bereiche für offene Rückfragen und kuratierte Antworten
• Einbettung oder Freigabeoptionen für die Nutzung außerhalb des direkten Arbeitsbereichs
• Änderungen oder Änderungshistorie für nachvollziehbare Anpassungen

Nicht jeder dieser Punkte ist in jedem Bereich sichtbar. Die genaue Auswahl ist meist ein Hinweis darauf, wofür dieser Bereich gedacht ist.

In der Oberfläche heißen diese Punkte oft genau so. Häufig begegnen dir also direkt Labels wie Allgemein, Persönlich, Hinweise, Berechtigungen, Datenbanken, Agent Plugins, RAG, Ablage, Automationen, Feedback, Dashboard, Einbetten oder Änderungen. Viele Einstellungsseiten nutzen dabei denselben Aufbau: Überschrift und Einordnung stehen oben, Aktionen oder Tabs sitzen rechts daneben und rutschen erst auf schmaleren Breiten unter die Beschreibung.

Wenn ihr mit feingranularen Regeln arbeiten wollt (z. B. „public“ oder „nur bestimmte Kunden/Projekte“), siehe Zugriffsfilter (Permission Filter).

Wenn in eurem Setup eingebaute Assistenten-Fähigkeiten verwaltet werden, findest du dort oft auch einen Bereich für Agent Plugins oder Werkzeuge. Wie du typische eingebaute Plugins nutzt, steht in Integrierte MCP-Server.

Wenn du einen extern gehosteten MCP-Server anbinden willst, ist derselbe Bereich ebenfalls relevant. Für Smithery-gehostete Server ist der übliche Weg: Agent Plugins öffnen, Plugin hinzufügen wählen, dort die eigene Konfiguration öffnen, Streaming HTTP auswählen und die Verbindungs-URL des Dienstes eintragen. Eine ausführliche Schritt-für-Schritt-Erklärung findest du unter Externe MCP-Server.

Bei der modernen Einstellungsoberfläche ist der Einstieg bewusst einfacher: Für viele externe MCP-Server reichen im ersten Schritt wenige Pflichtfelder. Zusätzliche technische Optionen liegen gesammelt unter Erweiterte Einstellungen, damit Standard-Setups schneller angelegt werden können.

Beim persönlichen Assistenten erreichst du diese Einstellungen je nach Oberfläche an zwei Stellen: Entweder über das Drei-Punkte-Menü direkt am Sidebar-Eintrag oder – in der älteren Oberfläche – über das Drei-Punkte-Menü oben rechts in der App-Leiste des geöffneten Assistenten. Deine persönlichen Account-Einstellungen liegen davon getrennt immer im User-Menü und führen je nach Oberfläche auf Account-Einstellungen, Einstellungen oder direkt auf Persönlich – nicht in die allgemeinen Agenten-Einstellungen des Assistenten.

Im eigenen persönlichen Space zeigt die Einstellungsnavigation außerdem bewusst nur die Bereiche, die dort ohne Bot-Konfiguration sinnvoll sind. Sichtbar bleiben vor allem Persönlich, Integrationen, Agent Plugins, Sandbox, Automationen, Berechtigungen und Events. Typische Bot-Bereiche wie Dashboard, Feedback, Einbetten, Q&A, Flow, Systemprompt, RAG, Ablage oder Änderungen erscheinen dort in der Navigation nicht mehr. Wenn du die Einstellungen direkt aus der Space-App-Leiste des persönlichen Assistenten öffnest, ist damit weiterhin die Agenten-Konfiguration des persönlichen Assistenten gemeint – nicht deine persönlichen Konto-Einstellungen.

Wenn du den Bereich Einstellungen direkt ohne Unterseite öffnest, landest du jetzt sofort auf einer passenden Standardseite. Beim persönlichen Assistenten ist das in der Regel Werkzeuge, in anderen Bereichen meist Allgemein. Dadurch erscheint die normale Einstellungsoberfläche direkt, statt erst kurz auf einer leeren Übersichtsseite oder einem großen Ladezustand zu bleiben. Auch beim direkten Aufruf oder Neuladen einer konkreten Unterseite – zum Beispiel Aufgaben MCP – bleibt die vorhandene Einstellungsoberfläche jetzt sichtbar. Die Seitenleiste erscheint sofort, und der eigentliche Seiteninhalt wird direkt gerendert, statt bis zum Abschluss aller Admin-Abfragen als vollflächiger Skeleton stehen zu bleiben.

Auch beim Wechsel zwischen Einstellungs-Tabs bleibt die bestehende Seitenhülle mit Navigation und Seitenleiste jetzt in der Regel sichtbar. Du siehst also nicht bei jedem Tab-Wechsel erneut einen kompletten großen Skeleton-Ladezustand, sondern nur noch dort einen kurzen Ladehinweis, wo Inhalte tatsächlich noch nachgeladen werden.

Auf Seiten mit Konfigurations-Karten, etwa unter Allgemein, können einzelne Karten dabei kurz einen lokalen Platzhalter zeigen, bis ihre Konfigurationsdaten nachgeladen sind. Der Rest der Unterseite bleibt in dieser Zeit aber normal benutzbar und sichtbar.

Das gilt auch für den persönlichen Assistenten: Unterseiten wie Allgemein, Systemprompt, RAG oder Erweiterte Einstellungen sollen nach dem Öffnen ihre vorhandenen Werte normal laden und bearbeitbar anzeigen. Wenn du dort bisher nur leere Karten oder dauerhaft sichtbare Platzhalter gesehen hast, entspricht das nicht mehr dem vorgesehenen Verhalten.

Die Seite Ereignisse im persönlichen Assistenten bleibt davon unabhängig normal erreichbar. Wenn andere Einstellungs-Unterseiten bereits Inhalte zeigen, sollte die Navigation also nicht nur auf diese eine Seite beschränkt sein.

In der modernen Einstellungsoberfläche sind viele Integrationen direkt in die Space-Einstellungen verschoben worden. Dazu gehören unter anderem API-Schlüssel, Aufgaben MCP und Space MCP Hub. Du findest sie in der Sidebar des Space unter Integrationen.

Die persönliche Kalender-Integration erreichst du dagegen wieder über das User-Menü → Account-Einstellungen. Dort bleibt sie als persönlicher Bereich von den eigentlichen Space-Integrationen getrennt.

Wichtig: Die technische Zuständigkeit ändert sich dadurch nicht automatisch. Andere Bereiche wie API-Schlüssel, Aufgaben MCP oder Space MCP Hub bleiben echte Space-Einstellungen.

Die bisher eingebaute GitHub-Integration ist nicht mehr Teil der Produktoberfläche. Eine eigene GitHub-Seite, gespeicherte GitHub-Tokens oder eingebaute GitHub-Sync-Typen verwaltest du daher nicht mehr über die CLYE-Einstellungen. Wenn du GitHub weiterhin anbinden willst, nutzt du dafür stattdessen einen passenden MCP-Server oder eine externe Integration.

Die frühere Clockify-Integration und das Clockify-Mapping sind nicht mehr Teil der eingebauten Produktfunktionen. Wenn du Clockify weiterhin nutzen willst, bindest du es stattdessen über einen eigenen oder externen MCP-Server an. Für Aufgaben bleibt die generische Zeiterfassung in Tasks im Produkt erhalten.

Je nach freigeschaltetem Funktionsumfang kannst du unter Agent Plugins jetzt auch lokale Ordner direkt im Browser verbinden. Dafür wählst du den Ordner über den Browser-Dateidialog aus und erlaubst den Zugriff. Eine ausführlichere Einordnung steht unter Externe MCP-Server; der CLI-Weg bleibt unter Share-Folder dokumentiert.

Wichtig für den persönlichen Bereich: Wenn du Agent Plugins in den persönlichen Einstellungen oder im eigenen persönlichen Space verwaltest, werden diese MCP-Server wieder bewusst auf Space-Ebene gespeichert. Bereits vorhandene persönliche Space-MCP-Server bleiben dort sichtbar und lassen sich weiter bearbeiten, bei Bedarf neu anmelden oder entfernen. Die Installation im Assistenten-Scope bleibt nur für normale Assistenten unverändert bestehen.

Für bereits installierte Plugins steht dort außerdem direkt am jeweiligen Eintrag ein Aktiv-Schalter bereit. Darüber kannst du ein Plugin für die KI temporär deaktivieren, ohne es zu deinstallieren. So bleibt die Einrichtung erhalten, während die zugehörigen Tools vorübergehend nicht mehr in den KI-Kontext übernommen werden.

In der modernen Einstellungsoberfläche bleibt die Navigation dabei wieder näher an der älteren Ansicht: Verweise aus der Agent-API führen auf API-Schlüssel, der Bereich Webhooks ist wieder direkt über die passenden Einstellungsseiten erreichbar und freigeschaltete Integrationen wie Aufgaben MCP oder Space MCP Hub erscheinen wieder nur dort, wo sie fachlich sinnvoll sind.

Bei Agent Plugins gilt zusätzlich: Hat ein Space keinen eigenen Assistenten-Bot, können geerbte Assistenten-Plugins trotzdem wieder in einem schreibgeschützten Abschnitt sichtbar sein. So erkennst du auch in solchen Spaces, welche Werkzeuge bereits über einen verknüpften Assistenten bereitgestellt werden, ohne sie dort versehentlich lokal zu verändern.

Für DocuWare gibt es einen von CLYE gehosteten, OAuth-geschützten MCP-Server. Die Einrichtung in DocuWare und die Anbindung im CLYE AI sind unter DocuWare MCP-Server beschrieben.

Für Shopware-Instanzen ab Version 6.7.11.0 verbindet der Shopware-Connector den CLYE AI direkt mit dem nativen MCP-Server der Shop-Installation.

Einstellungen für Assistenten

Bei Assistenten geht es meist darum, wie sie arbeiten sollen und mit welchem Wissen sie arbeiten können.

Sinnvolle Fragen sind:

• Wofür ist dieser Assistent gedacht?
• Welches Wissen soll er kennen?
• Welche Werkzeuge oder Quellen braucht er wirklich?
• Welche Arbeitsweise soll über Skills oder andere Vorgaben standardisiert werden?

Oft findest du dort zusätzlich Bereiche für:

• Quellen und hochgeladene Dateien
• Werkzeuge oder Integrationen
• Dashboard, Feedback oder Änderungen bei aktiv genutzten Assistenten
• Feedback, Fragen oder Änderungen
• Einbettung und Freigaben

Gerade in Bereichen wie Prompt, RAG, Versionen, Webhooks, API-Keys oder Q&A ist die Oberfläche jetzt konsistenter aufgebaut. Titel, Beschreibung, Tabs und Aktionsflächen bleiben besser ausgerichtet, auch wenn rechts zusätzliche Schalter oder Buttons eingeblendet werden.

In den Allgemeinen Einstellungen eines Assistenten stehen Name und Beschreibung und das Profilbild jetzt untereinander. Dadurch bleibt der Bereich „Mit KI generieren“ auch dann vollständig sichtbar, wenn daneben ein Demo-Chat geöffnet ist.

Wenn du unter Einstellungen → Allgemein ein Modell ergänzt oder bearbeitest, werden Änderungen im geöffneten Modell-Dialog jetzt auch dann zuverlässig übernommen, wenn du dort direkt noch Anzeigename oder Beschreibung eingibst und den Dialog mit Fertig, per Escape oder durch Klicken außerhalb schließt. Gerade frisch getippte Werte bleiben dabei erhalten und werden nicht mehr durch parallel nachgeladene Serverdaten überschrieben.

Der Bereich Support-Kontakt gehört jetzt ebenfalls fest zu den Allgemeinen Einstellungen eines Spaces oder Assistenten. Du musst also nicht erst auf eine zusätzliche Freischaltung warten, um diese Kontaktmöglichkeit dort zu sehen.

Wenn für eine Organisation ein Support-Kontakt gesetzt ist, erscheint in Admin-Übersichten dazu passend der Status „Support-Kontakt gesetzt“. Dieser Kontakt bleibt in der Mitgliederliste der Organisation sichtbar, damit ihr ihn dort weiter verwalten oder entfernen könnt. In den sichtbaren Zählwerten für Mitglieder, User zugeordnet und Aktive Nutzer wird er aber nicht als reguläres Mitglied mitgezählt.

Bei einem Space mit Bot findest du dort jetzt außerdem wieder die Abrechnung direkt im Bereich Allgemein – auch dann, wenn in eurem Setup noch die ältere Einstellungsansicht verwendet wird. In der Legacy-Ansicht erscheint die Karte unter dem Support-Kontakt. Für persönliche Bereiche wird diese Karte nicht angezeigt.

Unter Einstellungen → Allgemein → Funktionen können je nach Freigabe zusätzliche Assistenten-Funktionen als eigene Schalter erscheinen. Dazu gehört jetzt auch Chat-Starter: Ist die zugrunde liegende Funktion für eure Umgebung aktiviert, kannst du dort pro Assistent festlegen, ob unter einer leeren Chat-Eingabe kontextbezogene Gesprächseinstiege angezeigt werden.

Wichtig ist dabei: Dieser Schalter allein reicht nicht aus. Die Funktion wird nur sichtbar und wirksam, wenn zusätzlich das Feature-Flag chatStarter in eurer Umgebung freigegeben ist. Erst wenn beide Schalter aktiv sind, erscheinen die Vorschläge im Chat.

Wenn ein Assistent auch außerhalb des normalen Arbeitsbereichs erreichbar sein soll, lohnt sich ein Blick auf Einbetten oder ähnliche Freigabeoptionen. Für einen gezielten, kontrollierten Einstieg ist dabei oft ein Assistant Access Link der richtige Weg.

Wenn ein Assistent bereits von mehreren Personen genutzt wird, lohnt sich meist zuerst ein Blick auf Zweck, Wissen und Berechtigungen, bevor weitere Optionen angepasst werden.

Feature-Flags und Rollout-Stufen

Wenn in eurem Setup Feature-Flags in der Oberfläche verwaltet werden, zeigt die Übersicht pro Flag die gesetzte Rollout-Stufe und zusätzlich die Zielgruppe an. Die bisherige Eigenschaft Freigabe ist in /admin/testing nicht mehr Teil der Oberfläche. Sichtbarkeit und Rollout werden jetzt nur noch über Zielgruppe und Rollout-Stufe abgebildet.

Die optionale Zielgruppe schränkt zusätzlich ein, für wen ein Flag überhaupt sichtbar sein darf. In /admin/testing erscheint dafür die Spalte Zielgruppe mit deutschen Labels. Möglich sind derzeit Admin, Tester, Entwickler und Support. Ist keine Zielgruppe gesetzt, gilt das Flag aus Nutzersicht als für alle Endnutzer offen, sofern auch die übrigen Freigaben passen.

Wichtig dabei: Ein Flag wird nur sichtbar, wenn beide Prüfungen erfolgreich sind:

1. die gewählte Zielgruppe passt zum aktuellen Nutzer
2. die gesetzte Rollout-Stufe erlaubt das Flag ebenfalls

Wenn ihr auf /admin/testing mit Tabellenfiltern arbeitet, stehen dafür weiterhin Filter wie Rollout, Zielgruppe oder Review offen bereit. Einen separaten Filter Freigabe gibt es dort nicht mehr.

Über Verlauf anzeigen seht ihr pro Flag jetzt außerdem klarer, wer eine Änderung ausgelöst hat. Bei Freigaben, Änderungen der Rollout-Stufe und eingehendem Feedback zeigt der Verlauf den Namen oder ersatzweise die E-Mail des Akteurs an. Fehlen diese Angaben, erscheint weiterhin System.

Dieselbe Akteursangabe wird auch im Release-Kalender verwendet. Wenn ein Flag zum Beispiel auf Released gesetzt oder über einen Release-Sync übernommen wurde, ist dort derselbe Name beziehungsweise dieselbe E-Mail sichtbar wie im Detailverlauf des Flags.

Diese Freigabelogik gilt nicht nur für sichtbare Oberflächen, sondern auch für Funktionen mit Server- oder API-Zugriff über Feature-Flags. Wenn ein Feature für bestimmte Nutzergruppen oder Rollout-Stufen freigeschaltet ist, soll dieselbe Prüfung auch an den zugehörigen Endpunkten greifen.

Das betrifft jetzt auch den Space-MCP-Hub, wenn ihr ihn mit einem Space-Admin-API-Key ansprecht. Für solche API-Keys werden dabei die Test-Overrides des Key-Erstellers mit ausgewertet. Ein in /admin/testing aktiviertes Feature gilt damit auch für MCP-Hub-Aufrufe über diesen Key, statt am Endpoint fälschlich mit 403 zu scheitern.

Wichtig für Versionen eines Flags: Eine bereits gesetzte Rollout-Stufe bleibt auch dann wirksam, wenn die interne Feature-Version erhöht wird. Ein Versionssprung setzt Released also nicht automatisch zurück. Die bisherige Stufe bleibt als Ausgangsbasis aktiv, bis für die neue Version ausdrücklich eine andere Stufe gesetzt wird.

Wenn du ein bereits auf Released gesetztes Flag wieder auf Tester oder Dev zurückstufen willst, verlangt die Oberfläche eine ausdrückliche Bestätigung. Das soll verhindern, dass ein Feature versehentlich wieder für Endnutzer verschwindet.

Zusätzlich wertet die Oberfläche Feature-Flags bei laufender Anmeldung stabiler aus: Solange eine vorhandene Sitzung im Hintergrund noch nachgeladen oder aktualisiert wird, bleibt die bisherige Benutzerzuordnung für die Flag-Auswertung erhalten. Für eingeloggte Nutzer mit einer Rollout-Gruppe wie Alpha oder Beta bleibt damit auch diese Gruppenzuordnung beim Neuladen oder bei einem Session-Refetch erhalten, solange der Server weiterhin dieselbe Freigabe liefert. Dadurch kippen freigeschaltete Funktionen nicht kurz auf Released zurück.

Praktisch bedeutet das:

1. Version erhöht: Die bisherige Rollout-Stufe bleibt zunächst erhalten.
2. Neue Stufe bewusst setzen: Erst dann ändert sich die Freigabe für die neue Version.
3. Zielgruppe prüfen: Zusätzlich muss die gesetzte Zielgruppe zum aktuellen Nutzer passen.
4. Downgrade von Released: Dafür ist eine zusätzliche Bestätigung nötig.
5. Session wird aktualisiert: Bereits sichtbare Flag-abhängige Bereiche bleiben währenddessen stabil und flackern nicht kurz aus.

Wenn ihr im Admin-Bereich den Review-Stand eines Flags prüft, wertet die Oberfläche diesen Stand jetzt pro Flag aus. Maßgeblich ist also nicht mehr nur eine globale Liste der zuletzt eingegangenen flag.*-Ereignisse, sondern der jeweils letzte passende Stand genau dieses Flags. Dadurch verschwinden falsche Hinweise wie „Update blockiert“, wenn ein Flag für seine aktuelle Version bereits freigegeben wurde und zwischenzeitlich andere Flag-Ereignisse, Test-Overrides oder ältere Migrationsereignisse angefallen sind.

Wichtig bleibt: Ein echter Versionssprung eines Flags kann weiterhin bewusst blockierend wirken, bis der neue Stand erneut geprüft oder freigegeben wurde.

Session-Test-Overrides und Whitelabel-Freigaben können dieses Zielgruppen-Gate weiterhin gezielt umgehen. Wenn du auf /admin/testing für einen Login gezielt Test-Overrides setzt, sind diese Overrides jetzt auch während der Anmeldung und in der laufenden Sitzung verbindlich maßgeblich. Manuelle Session-Overrides haben dabei Vorrang vor Whitelabel-Booleans, Rollout-Stufen und Zielgruppe.

Praktisch ist das vor allem für Tests und Abnahmen wichtig: Flag-abhängige Bereiche wie ein Eintrag in der Sidebar, Einführungsdialoge oder Hinweise zur Ablage sollen nach dem Login denselben Override-Stand zeigen wie die Sitzung selbst. Wenn die Oberfläche die Client-Flags noch lädt, warten solche Hinweise deshalb zunächst, statt kurz im falschen Zustand aufzuspringen.

Auf /admin/testing kann zusätzlich der Button Entfernungs-Prompt erscheinen. Er erzeugt einen Prompt für einen Agenten, der veraltete Feature-Flags zur Bereinigung vorbereitet. Berücksichtigt werden dabei nur Flags ohne Aktivität seit mehr als 60 Tagen, die nicht als permanent markiert sind.

Für die vorgeschlagene Bereinigung gilt:

• Released: Das Flag soll auf Bake-in true gesetzt und anschließend entfernt werden.
• Nicht released: Das Flag soll auf Bake-in false gesetzt und anschließend entfernt werden.
• Alpha und Beta: Diese Zwischenstufen werden derzeit nicht automatisch umgestellt, sondern im Prompt nur als Hinweis aufgeführt.

Wenn ihr Änderungen an Feature-Flags plant, prüft nach einem Versionssprung trotzdem kurz die Flag-Übersicht. Nutzt den Entfernungs-Prompt nur als Arbeitsgrundlage und kontrolliert insbesondere Hinweise zu Alpha- und Beta-Flags noch einmal manuell. Wenn ihr auf /admin/testing mit Filtern wie Review offen arbeitet, gelten Karten oberhalb der Tabelle und Tabelleninhalt jetzt auf derselben gefilterten Flag-Menge. Blockierte Flags außerhalb des aktiven Filters erscheinen damit nicht mehr zusätzlich in der Blocker-Karte. Testet bei Nutzer-Flags zusätzlich einen Reload im eingeloggten Zustand oder einen Tab-Wechsel mit anschließendem Fokus. So seht ihr sofort, ob die gewünschte Freigabe auch während einer Session stabil sichtbar bleibt.

Wenn in eurem Setup die Feature-Flag adminUpdatesOverview freigeschaltet ist, erscheint in der Admin-Oberfläche unter /admin zusätzlich die Karte Updates. Sie führt zur Seite /admin/updates.

Dort seht ihr eine Übersicht der verfügbaren Container-Images für Deployments – zum Beispiel main, datumsbasierte main-YYYYMMDD-HHmmss-Tags und Images mit direktem Commit-SHA. Intern genutzte main-*-Images erscheinen dabei in der primären Liste bewusst vor reinen SHA-Tags, damit typische Kandidaten für ein Deployment schneller sichtbar bleiben. Zu jedem Eintrag zeigt die Oberfläche den aktuellen Gesamtstatus und macht die Gründe für eine Freigabe oder Blockade sichtbar.

Typischerweise prüft die Seite dabei:

1. den allgemeinen Status des Images
2. vorhandene CI-Checks
3. den Stand der E2E-Tests
4. blockierende Feature-Flags, die einem Live-Einsatz noch im Weg stehen

Praktisch bedeutet das:

• Grün: Das Image darf aus Sicht der Oberfläche eingespielt werden.
• Rot: Das Image ist noch blockiert; die Oberfläche nennt die konkreten Gründe direkt am Eintrag.
• Die Image-Referenz ist kopierbar, damit ihr sie direkt für Deployments oder Rückfragen übernehmen könnt.
• Verlinkungen zur E2E-Ansicht und zur Testing-Seite helfen beim schnellen Nachprüfen offener Blocker.

Die Übersicht lädt dafür mehrere Registry-Seiten und fragt zusätzlich die OCI-Tag-Liste der Registry ab. So verdrängen viele Digest- oder SHA-Tags die relevanten main-*-Einträge nicht aus der sichtbaren Liste, und typische Release-Kandidaten bleiben auch dann sichtbar, wenn sie nicht über die erste Tag-Seite der Registry auftauchen.

Für den Abruf nutzt die Oberfläche dieselben Forgejo-Zugangsdaten wie andere Registry-Ansichten: entweder ein konfiguriertes Token oder eine Kombination aus Benutzername und Passwort. Wenn in eurem Setup mehrere Package-Owner oder Registry-Abfragen nötig sind, berücksichtigt die Updates-Seite auch diese Varianten, damit die erwarteten main-*-Tags vollständig gefunden werden.

Wenn zu einem main-*-Image kein direkter Commit-Tag vorliegt oder die Registry keine passenden main-*-Tags liefert, ordnet die Oberfläche den passenden Commit über die zeitlich nächstliegenden E2E-Läufe zu. Der SHA-basierte Fallback greift also nur noch dann, wenn die Registry selbst keine besser passende main-*-Zuordnung liefern kann.

Wenn die Karte Updates oder die Seite /admin/updates bei euch fehlt, prüft zuerst:

1. ob die Feature-Flag adminUpdatesOverview für euren Nutzer sichtbar ist
2. ob ihr euch im Admin-Bereich und nicht nur in normalen Einstellungen befindet
3. ob in eurem Setup die nötigen Datenquellen für Registry-, Status- oder E2E-Informationen verfügbar sind

Wenn in eurem Setup die Feature-Flag imgproxyAdminSettings freigeschaltet ist und ein Imgproxy-Endpunkt konfiguriert wurde, erscheint in der Admin-Oberfläche unter /admin im Bereich Infrastruktur & Events zusätzlich die Karte Icon Assets. Sie führt zur Seite /admin/assets.

Dort könnt ihr zentral kleine Bilddateien für Symbole und ähnliche Assets verwalten. Die Übersicht lädt vorhandene Bilder direkt aus dem tatsächlichen Imgproxy-MCP-Speicher und zeigt die zuletzt geänderten Dateien zuerst an.

Typischerweise gehört dazu:

1. vorhandene Icon-Assets anzeigen
2. neue Dateien hochladen
3. nicht mehr benötigte Assets löschen
4. für ein vorhandenes Asset einen direkt nutzbaren Imgproxy-Link erzeugen

Beim Erzeugen eines Links arbeitet die Oberfläche mit der hochgeladenen Datei selbst. Imgproxy-Key und Salt werden dabei weiterhin nur für signierte Vorschau- und Transformations-URLs genutzt. Es ist keine separate Asset-Registrierung in einer Datenbank nötig.

Wenn die Karte Icon Assets in eurer Admin-Übersicht fehlt oder die Liste leer bzw. fehlerhaft bleibt, prüft zuerst:

1. ob die Feature-Flag imgproxyAdminSettings für euren Nutzer sichtbar ist
2. ob die Imgproxy-Umgebung in eurem Setup überhaupt konfiguriert wurde
3. ob im Imgproxy-MCP-Speicher bereits passende Bilddateien vorhanden sind
4. ob ihr euch in der Admin-Oberfläche und nicht nur in den normalen Space-Einstellungen befindet

Startseiten für persönliche Bereiche, Assistenten und Gruppen anpassen

Wenn in eurem Setup das Feature-Flag agentOsHome aktiv ist, ist die Startseite nicht mehr nur ein fester Einführungs- oder Hinweisbereich, sondern eine editierbare Home-Oberfläche.

Wichtig ist die Unterscheidung nach Kontext:

• Persönliche Startseite: Du bearbeitest dein eigenes Home-Layout direkt auf der Startseite selbst.
• Assistenten: Admins pflegen unter Einstellungen → Startseite das Default-Template des Assistenten.
• Gruppen: Admins pflegen unter Einstellungen → Startseite ebenfalls das Default-Template für alle Mitglieder.

Für Mitglieder eines Spaces gilt dabei: Sie sehen dieselbe Space-Startseite wie die anderen Mitglieder. Eine gesonderte Endnutzer-Unterseite /settings/home zur eigenen Aktivierung oder Deaktivierung der Startseite gibt es dafür nicht mehr. Assistenten- und Gruppen-Spaces zeigen diese Startseite jetzt direkt, sobald die Home-Oberfläche verfügbar ist. Die frühere Ablage oder ein alter Zwischenzustand blitzen dabei beim Öffnen nicht mehr kurz dahinter auf.

Typische Möglichkeiten im Startseiten-Editor sind:

• Widgets hinzufügen, entfernen und verschieben
• die Anordnung im Raster anpassen
• pro Widget Titel ausblenden und – je nach Widget-Typ – auch eine eigene Schriftgröße festlegen
• eingefügte Widgets bei Bedarf über die obere Werkzeugleiste des Editors zurücksetzen
• Standard-Module auch mehrfach verwenden
• vorhandene MDX- oder Dashboard-Widgets weiterverwenden
• im Widget-Katalog direkt erkennen, aus welcher Quelle ein Eintrag stammt
• bei Bedarf ein E-Mail-Postfach als Widget ergänzen
• zusätzliche Startseiten-Widgets wie Kontext-Rückblick, Tagesüberblick, Notiz, RSS-Feed, Forgejo, Stripe oder Wetter direkt aus dem Widget-Katalog hinzufügen
• bei KI-Widgets den erzeugten JavaScript-Code vor dem Speichern direkt prüfen und anpassen

Für das E-Mail-Widget wählst du zunächst den passenden MCP-Zugang wie IMAP, Google Workspace oder Microsoft 365. Danach lässt du die benötigte Automations-Funktion erzeugen und testen, bevor das Widget gespeichert wird.

Auch auf der persönlichen Startseite kannst du bei einzelnen Widgets jetzt direkt in den Widget-Einstellungen die Schriftgröße anpassen. Die Änderung gilt jeweils nur für das gerade bearbeitete Widget und nicht für die komplette Startseite.

Wenn du die Widget-Einstellungen öffnest, zwischen Widgets wechselst oder den Dialog erneut aufrufst, zeigt CLYE AI dabei immer die Werte des aktuell bearbeiteten Widgets. Bereits geöffnete Einstellungen eines anderen Widgets werden dabei nicht versehentlich übernommen. Dieselbe Bearbeitung gilt jetzt auch für die neuen Widgets RSS-Feed, Forgejo, Stripe und Wetter.

Für ein KI-Widget gibst du zuerst Titel und Beschreibung an. Anschließend erzeugt CLYE AI im rechten Setup-Sheet ein passendes JavaScript-Datenskript. Prüfe oder bearbeite diesen Code vor dem Hinzufügen. Nach dem Speichern verwendet das Widget bei späteren Aktualisierungen direkt dieses Skript.

Für die neuen externen Widgets gilt:

• RSS-Feed: Trage eine oder mehrere HTTPS-Feed-Adressen ein und wähle zwischen Liste und Vollbild.
• Forgejo: Hinterlege die Forgejo-URL und einen API-Schlüssel. Das Widget zeigt offene Pull Requests und aktuelle Konto-Aktivitäten.
• Stripe: Wähle den Stripe-MCP-Schlüssel und filtere auf Wunsch nach Alle, Bezahlt, Offen oder Verloren.
• Wetter: Gib eine Postleitzahl an und entscheide, ob nur das aktuelle Wetter oder zusätzlich eine Vorhersage erscheinen soll.

Die zusätzlichen Plattform-Widgets Kontext-Rückblick, Tagesüberblick und Notiz lassen sich ohne weitere Einrichtung sofort hinzufügen. Kontext-Rückblick zeigt neue Antworten, geänderte Dateien und erledigte Aufgaben seit deinem letzten Besuch. Tagesüberblick bündelt die wichtigsten Aufgaben und offenen Projekte für den Tag. Notiz ist eine kleine persönliche Textablage auf der Startseite.

Längere Widget-Listen auf der Startseite öffnen keine zusätzliche Mehr anzeigen-Ansicht mehr. Stattdessen bleibt die Karte in ihrer Grundhöhe, und der Inhalt scrollt innerhalb des Widgets. Das sorgt für ein einheitlicheres Kartenraster über verschiedene Listen-Widgets hinweg.

Nicht mehr Teil dieser Startseiten-Verwaltung sind:

• eine dauerhafte Einführungstour
• Hinweis- oder Versionsleisten auf der Startseite
• ein separates Aktivieren oder Deaktivieren der Startseite für Mitglieder
• ein Parameter-Chat zum Ausfüllen einzelner Tool-Eingaben für das E-Mail-Widget

Einstellungen für Gruppen oder gemeinsame Bereiche

Bei Gruppen und gemeinsamen Bereichen ist oft wichtiger:

• wer Zugriff hat
• welche Inhalte dort gemeinsam gepflegt werden
• welche Regeln oder Standards für das Team gelten

Gruppen haben nicht immer dieselben Einstellungsbereiche wie Assistenten. Wenn kein eigener Assistent dahinter liegt, stehen eher Zusammenarbeit, Berechtigungen und gemeinsamer Kontext im Mittelpunkt als direkter Chat-Betrieb.

Einstellungen im persönlichen Bereich

Dein persönlicher Bereich hat oft einige eigene Punkte, die in Gruppen so nicht vorkommen. Dazu gehören zum Beispiel persönliche Angaben, Hinweise oder dein individueller Arbeitskontext. Diese Bereiche helfen dir vor allem dabei, CLYE AI auf deine tägliche Nutzung abzustimmen, nicht auf einen Teamprozess.

Typisch sind dort:

• persönliches Wissen und eigene Vorlagen
• individuelle Dateien oder Notizen
• Anpassungen, die nicht sofort für ein ganzes Team gelten sollen
• persönliche Hinweise und Präferenzen für deinen Arbeitsalltag
• persönliche Agent Plugins, falls sie in eurem Setup dafür freigeschaltet sind

Wenn dir ein Bereich fehlt

Nicht jede Person darf alles anpassen. Wenn du eine Quelle, Integration oder Freigabe brauchst, aber die passende Einstellung nicht siehst, kläre zuerst:

1. Bist du im richtigen Assistenten, Space oder persönlichen Bereich?
2. Hast du dort die nötige Rolle?
3. Ist der gewünschte Bereich überhaupt für diesen Kontext vorgesehen?

Nicht alles auf einmal anpassen

Viele Probleme entstehen nicht durch zu wenig Konfiguration, sondern durch zu viel davon. Ein gutes Vorgehen ist:

1. erst den Einsatzzweck klären
2. nur die nötigen Einstellungen aktiv anpassen
3. im Alltag prüfen, was wirklich hilft
4. Änderungen bei Bedarf schrittweise ergänzen

Hinweise und Einführungen erneut nutzen

Wenn du einen Bereich neu erklären, selbst noch einmal sauber durchgehen oder Onboarding-Hinweise erneut sehen willst, findest du je nach Bereich auch Einstellungen für Hinweise oder Einführungen. Das ist besonders praktisch bei persönlicher Ablage, Gruppen-Ablagen, Assistenten-Ablagen und Skills.

Typischerweise heißt dieser Bereich Hinweise. Dort kannst du Einführungen zurücksetzen, damit sie beim nächsten Besuch erneut angezeigt werden.

Feedback und Verbesserung

Auch Rückmeldungen aus der Nutzung gehören indirekt zu guter Anpassung. Wenn ein Assistent wiederholt unpassend reagiert, lohnt sich meist ein Blick auf:

• das zugrunde liegende Wissen
• bestehende Skills
• genutzte Werkzeuge oder Quellen
• die grundsätzliche Beschreibung des Einsatzzwecks

Kurz gesagt

Einstellungen in CLYE AI sollen Assistenten und Gruppen klarer, nützlicher und passender machen. Passe deshalb vor allem Zweck, Wissen, Zugriff und Zusammenarbeit an, und beachte dabei immer, was in deinem Bereich und mit deiner Rolle tatsächlich sinnvoll freigegeben ist.

Kommandozeilen-Tool (CLI)

Für technische Nutzer:innen gibt es die CLYE CLI (clye). Sie kann genutzt werden, um z. B. eine Verbindung zu einer CLYE-AI-Instanz herzustellen, Tools aufzurufen oder Konnektoren lokal als MCP-Server zu starten.

In vielen Umgebungen wird das Tool zusätzlich unter den Aliasen ai-hub-cli und ai-hub installiert.

• Offizielle Dokumentation & Installation: https://ai-hub-cli.s3.de.io.cloud.ovh.net/index.html

App-Name, Link-Vorschau und Symbole

Die Anwendung verwendet die Bezeichnung CLYE AI konsistent. Dadurch sind Seitentitel, Link-Vorschauen, App-Name, Vorschaubilder und App-Symbole in Browsern und bei installierter Web-App einheitlich.

Auch die öffentliche Changelog-Seite unter /changelog erscheint mit derselben App-Shell wie die Hauptanwendung. Dadurch wirken Browser-Tab, geteilte Links, Mobilansichten und installierte Web-App konsistent. Die Seite wird dabei als vollständiges HTML-Dokument der Anwendung ausgeliefert, inklusive <!DOCTYPE html>, <html lang="de" translate="no" class="notranslate …">, Sprachkennzeichnung, deaktivierter Auto-Übersetzung, hellem und dunklem theme-color, Manifest, Discovery-Link, Open-Graph-Metadaten mit rechteckigem und quadratischem Vorschaubild, Apple-Web-App-Angaben wie mobile-web-app-capable, apple-mobile-web-app-title und apple-mobile-web-app-status-bar-style, dem vorab geladenen App-Symbol /ai-hub.svg, Favicon- und Touch-Icons in mehreren Varianten sowie direkt eingebundenen Stylesheets und vorab geladenen JavaScript-Chunks der Haupt-App.

Wenn du noch ältere Bezeichnungen, Vorschauen oder Symbole siehst:

1. aktualisiere die Seite im Browser
2. schließe die Web-App vollständig und öffne sie erneut
3. installiere oder hefte die Web-App bei Bedarf neu an, damit aktuelle Symbole und der Name CLYE AI übernommen werden

Eine Übersicht der sichtbaren Änderungen findest du im Changelog.