Exec-Genehmigungen — erweitert

Fortgeschrittene Themen zu Ausführungsgenehmigungen: der safeBins-Schnellpfad, die Bindung von Interpretern/Laufzeitumgebungen und die Weiterleitung von Genehmigungen an Chat-Kanäle (einschließlich nativer Zustellung). Die grundlegende Richtlinie und den Genehmigungsablauf finden Sie unter Ausführungsgenehmigungen.

Sichere Binärdateien (nur stdin)

tools.exec.safeBins benennt ausschließlich über stdin arbeitende Binärdateien (beispielsweise cut), die im Allowlist-Modus ohne explizite Allowlist-Einträge ausgeführt werden. Sichere Binärdateien lehnen positionale Dateiargumente und pfadähnliche Token ab, sodass sie nur den eingehenden Datenstrom verarbeiten können. Betrachten Sie dies als einen eng begrenzten Schnellpfad für Datenstromfilter, nicht als allgemeine Vertrauensliste.

Standardmäßige sichere Binärdateien:

cut, uniq, head, tail, tr, wc

grep und sort sind nicht in der Standardliste enthalten. Wenn Sie sie aktivieren, behalten Sie explizite Allowlist-Einträge für deren Arbeitsabläufe ohne stdin bei. Geben Sie für grep im Safe-Bin-Modus das Muster mit -e/--regexp an; die positionale Musterform wird abgelehnt, damit Dateioperanden nicht als mehrdeutige positionale Argumente eingeschleust werden können.

Argv-Validierung und abgelehnte Flags

Die Validierung erfolgt deterministisch ausschließlich anhand der argv-Struktur (ohne Existenzprüfungen im Host-Dateisystem), wodurch ein Datei-Existenz-Orakel aufgrund unterschiedlicher Zulassungs-/Ablehnungsergebnisse verhindert wird. Dateiorientierte Optionen werden für standardmäßige sichere Binärdateien abgelehnt; lange Optionen werden nach dem Fail-Closed-Prinzip validiert (unbekannte Flags und mehrdeutige Abkürzungen werden abgelehnt). Erkannte schreibgeschützte boolesche Flags der standardmäßigen Binärdateien (beispielsweise wc -l, tr -d, uniq -c) werden akzeptiert, während unbekannte kurze Flags nach dem Fail-Closed-Prinzip behandelt werden und eine manuelle Genehmigung erfordern.

Nach Safe-Bin-Profil abgelehnte Flags:

• grep: --dereference-recursive, --directories, --exclude-from, --file, --recursive, -R, -d, -f, -r
• jq: --argfile, --from-file, --library-path, --rawfile, --slurpfile, -L, -f
• sort: --compress-program, --files0-from, --output, --random-source, --temporary-directory, -T, -o
• tail: --follow, --retry, -F, -f
• wc: --files0-from

Sichere Binärdateien erzwingen außerdem, dass argv-Token zur Ausführungszeit für ausschließlich über stdin arbeitende Segmente als Literaltext behandelt werden (kein Globbing und keine $VARS-Expansion), sodass Muster wie * oder $HOME/... nicht zum Einschleusen von Dateizugriffen verwendet werden können. awk, sed und jq werden als sichere Binärdateien immer abgelehnt, da ihre Semantik nicht auf eine ausschließliche stdin-Verarbeitung validiert werden kann: jq kann Umgebungsdaten lesen und jq-Code aus Modulen oder Startdateien laden. Verwenden Sie für diese Werkzeuge statt safeBins einen expliziten Allowlist-Eintrag oder eine Genehmigungsaufforderung.

Vertrauenswürdige Verzeichnisse für Binärdateien

Sichere Binärdateien müssen aus vertrauenswürdigen Verzeichnissen für Binärdateien aufgelöst werden (Systemstandards plus optional tools.exec.safeBinTrustedDirs). PATH-Einträgen wird niemals automatisch vertraut. Die standardmäßig vertrauenswürdigen Verzeichnisse sind bewusst minimal gehalten: /bin, /usr/bin. Wenn sich Ihre Safe-Bin-Ausführungsdatei in Paketmanager-/Benutzerpfaden befindet (beispielsweise /opt/homebrew/bin, /usr/local/bin, /opt/local/bin, /snap/bin), fügen Sie diese explizit zu tools.exec.safeBinTrustedDirs hinzu.

Shell-Verkettung, Wrapper und Multiplexer

Shell-Verkettung (&&, ||, ;) ist zulässig, wenn jedes Segment der obersten Ebene die Allowlist erfüllt (einschließlich sicherer Binärdateien oder automatischer Skill-Zulassung). Umleitungen werden im Allowlist-Modus weiterhin nicht unterstützt. Befehlssubstitution ($() / Backticks) wird bei der Allowlist-Analyse abgelehnt, auch innerhalb doppelter Anführungszeichen; verwenden Sie einfache Anführungszeichen, wenn Sie literalen $()-Text benötigen.

Bei Genehmigungen über die macOS-Begleit-App wird unverarbeiteter Shell-Text, der Shell-Steuerungs- oder Expansionssyntax enthält (&&, ||, ;, |, `, $, <, >, (, )), als fehlender Allowlist-Treffer behandelt, sofern die Shell-Binärdatei selbst nicht auf der Allowlist steht.

Bei Shell-Wrappern (bash|sh|zsh ... -c/-lc) werden anfragespezifische Umgebungsüberschreibungen auf eine kleine explizite Allowlist reduziert (TERM, LANG, LC_*, COLORTERM, NO_COLOR, FORCE_COLOR).

Bei allow-always-Entscheidungen im Allowlist-Modus speichern transparente Dispatch-Wrapper (beispielsweise env, flock, nice, nohup, stdbuf, timeout) den Pfad der inneren Ausführungsdatei statt des Wrapper-Pfads. Shell-Multiplexer (busybox, toybox) werden für Shell-Applets (sh, ash usw.) auf dieselbe Weise entpackt. Wenn ein Wrapper oder Multiplexer nicht sicher entpackt werden kann, wird nicht automatisch ein Allowlist-Eintrag gespeichert.

Wenn Sie Interpreter wie python3 oder node auf die Allowlist setzen, verwenden Sie vorzugsweise tools.exec.strictInlineEval=true, damit die Inline-Auswertung weiterhin eine explizite Genehmigung erfordert. Im strikten Modus kann allow-always weiterhin unbedenkliche Interpreter-/Skriptaufrufe speichern, Inline-Auswertungsträger werden jedoch nicht automatisch gespeichert.

Sichere Binärdateien im Vergleich zur Allowlist

Konfigurationsort:

• safeBins stammt aus der Konfiguration (tools.exec.safeBins oder pro Agent agents.list[].tools.exec.safeBins).
• safeBinTrustedDirs stammt aus der Konfiguration (tools.exec.safeBinTrustedDirs oder pro Agent agents.list[].tools.exec.safeBinTrustedDirs).
• safeBinProfiles stammt aus der Konfiguration (tools.exec.safeBinProfiles oder pro Agent agents.list[].tools.exec.safeBinProfiles). Profilschlüssel pro Agent überschreiben globale Schlüssel.
• Allowlist-Einträge befinden sich in der lokalen Genehmigungsdatei des Hosts unter agents.<id>.allowlist (oder über Control UI / openclaw approvals allowlist ...).
• openclaw security audit warnt mit tools.exec.safe_bins_interpreter_unprofiled, wenn Interpreter-/Laufzeitbinärdateien ohne explizite Profile in safeBins erscheinen.
• openclaw doctor --fix kann fehlende benutzerdefinierte safeBinProfiles.<bin>-Einträge als {} vorbereiten (anschließend prüfen und einschränken). Interpreter-/Laufzeitbinärdateien werden nicht automatisch vorbereitet.

Beispiel für ein benutzerdefiniertes Profil: OC_I18N_900000

Interpreter-/Laufzeitbefehle

Durch Genehmigungen abgesicherte Interpreter-/Laufzeitausführungen sind bewusst konservativ:

• Der exakte argv-/cwd-/env-Kontext wird immer gebunden.
• Direkte Shell-Skript- und direkte Laufzeitdateiformen werden nach bestem Bemühen an einen konkreten lokalen Dateischnappschuss gebunden.
• Gängige Paketmanager-Wrapperformen, die weiterhin zu genau einer direkten lokalen Datei aufgelöst werden (beispielsweise pnpm exec, pnpm node, npm exec, npx), werden vor der Bindung entpackt.
• Wenn OpenClaw nicht genau eine konkrete lokale Datei für einen Interpreter-/Laufzeitbefehl identifizieren kann (beispielsweise Paketskripte, Auswertungsformen, laufzeitspezifische Loader-Ketten oder mehrdeutige Formen mit mehreren Dateien), wird die genehmigungsgestützte Ausführung abgelehnt, statt eine nicht vorhandene semantische Abdeckung zu behaupten.
• Bevorzugen Sie für solche Arbeitsabläufe Sandboxing, eine separate Host-Grenze oder eine explizit vertrauenswürdige Allowlist beziehungsweise einen vollständigen Arbeitsablauf, bei dem der Betreiber die umfassendere Laufzeitsemantik akzeptiert.

Wenn Genehmigungen erforderlich sind, gibt das Exec-Werkzeug sofort eine Genehmigungs-ID zurück. Verwenden Sie diese ID, um später auftretende Systemereignisse der genehmigten Ausführung (Exec finished und, sofern konfiguriert, Exec running) zuzuordnen. Wenn vor Ablauf des Zeitlimits keine Entscheidung eintrifft, wird die Anfrage als Genehmigungszeitüberschreitung behandelt und als endgültige Ablehnung des Host-Befehls gemeldet. Bei asynchronen Genehmigungen des Haupt-Agenten mit einer Ursprungssitzung setzt OpenClaw diese Sitzung außerdem mit einer internen Folgemeldung fort, damit der Agent erkennt, dass der Befehl nicht ausgeführt wurde, anstatt später ein fehlendes Ergebnis zu reparieren. Ausstehende Exec-Genehmigungen laufen standardmäßig nach 30 Minuten ab.

Verhalten der Folgezustellung

Nachdem eine genehmigte asynchrone Exec-Ausführung abgeschlossen ist, sendet OpenClaw eine nachfolgende agent-Runde an dieselbe Sitzung. Abgelehnte asynchrone Genehmigungen verwenden für den Ablehnungsstatus denselben Folgemeldungspfad der Hauptsitzung, registrieren jedoch keine Übergaben an eine privilegierte Laufzeitumgebung und führen den Befehl nicht aus. Ablehnungen ohne fortsetzbare Hauptsitzung werden entweder unterdrückt oder über einen sicheren direkten Pfad gemeldet, sofern ein solcher vorhanden ist.

• Wenn ein gültiges externes Zustellungsziel vorhanden ist (zustellbarer Kanal plus Ziel to), verwendet die Folgezustellung diesen Kanal.
• Bei reinen Webchat- oder internen Sitzungsabläufen ohne externes Ziel bleibt die Folgezustellung auf die Sitzung beschränkt (deliver: false).
• Wenn ein Aufrufer ausdrücklich eine strikte externe Zustellung verlangt, aber kein externer Kanal aufgelöst werden kann, schlägt die Anfrage mit INVALID_REQUEST fehl.
• Wenn bestEffortDeliver aktiviert ist und kein externer Kanal aufgelöst werden kann, wird die Zustellung auf eine reine Sitzungszustellung herabgestuft, anstatt fehlzuschlagen.

Weiterleitung von Genehmigungen an Chat-Kanäle

Sie können Exec-Genehmigungsaufforderungen an jeden Chat-Kanal (einschließlich Plugin-Kanälen) weiterleiten und mit /approve genehmigen. Dabei wird die normale Pipeline für ausgehende Zustellungen verwendet.

Konfiguration: OC_I18N_900001 Antwort im Chat: OC_I18N_900002 Der Befehl /approve verarbeitet sowohl Exec-Genehmigungen als auch Plugin-Genehmigungen. Wenn die ID keiner ausstehenden Exec-Genehmigung entspricht, werden stattdessen automatisch die Plugin-Genehmigungen geprüft. Dieser Fallback ist auf Fehler der Art „Genehmigung nicht gefunden“ beschränkt; bei einer tatsächlichen Ablehnung oder einem Fehler einer Exec-Genehmigung erfolgt nicht stillschweigend ein erneuter Versuch als Plugin-Genehmigung.

Weiterleitung von Plugin-Genehmigungen

Die Weiterleitung von Plugin-Genehmigungen verwendet dieselbe Zustellungspipeline wie Exec-Genehmigungen, verfügt jedoch unter approvals.plugin über eine eigene unabhängige Konfiguration. Das Aktivieren oder Deaktivieren der einen Funktion wirkt sich nicht auf die andere aus. Informationen zum Verhalten bei der Plugin-Erstellung, zu Anfragefeldern und zur Entscheidungssemantik finden Sie unter Plugin-Berechtigungsanfragen. OC_I18N_900003 Die Konfigurationsstruktur ist identisch mit approvals.exec: enabled, mode, agentFilter, sessionFilter und targets funktionieren auf dieselbe Weise.

Kanäle, die gemeinsame interaktive Antworten unterstützen, zeigen sowohl für Exec- als auch für Plugin-Genehmigungen dieselben Genehmigungsschaltflächen an. Kanäle ohne gemeinsame interaktive Benutzeroberfläche greifen auf Klartext mit /approve-Anweisungen zurück. Bei Plugin-Genehmigungsanfragen können die verfügbaren Entscheidungen eingeschränkt sein: Genehmigungsoberflächen verwenden die in der Anfrage deklarierte Entscheidungsmenge, und das Gateway lehnt Versuche ab, eine nicht angebotene Entscheidung zu übermitteln.

Genehmigungen im selben Chat auf jedem Kanal

Wenn eine Exec- oder Plugin-Genehmigungsanfrage von einer Chat-Oberfläche stammt, über die Nachrichten zugestellt werden können, kann sie standardmäßig in demselben Chat mit /approve genehmigt werden. Dies gilt zusätzlich zu den bestehenden Abläufen der Web-Benutzeroberfläche und Terminal-Benutzeroberfläche für Slack, Matrix, Microsoft Teams und ähnliche Chats, über die Nachrichten zugestellt werden können. Dabei wird das normale Kanalauthentifizierungsmodell für diese Unterhaltung verwendet. Wenn der ursprüngliche Chat bereits Befehle senden und Antworten empfangen kann, benötigen ausstehende Genehmigungsanfragen nicht mehr allein zu diesem Zweck einen separaten nativen Zustellungsadapter.

Discord, Telegram und QQ bot unterstützen ebenfalls /approve im selben Chat. Diese Kanäle verwenden jedoch auch bei deaktivierter nativer Genehmigungszustellung weiterhin ihre aufgelöste Liste der Genehmigungsberechtigten zur Autorisierung.

Native Genehmigungszustellung

Einige Kanäle können auch als native Genehmigungsclients fungieren: Discord, Slack, Telegram, Matrix und QQ bot. Native Clients ergänzen den gemeinsamen /approve-Ablauf im selben Chat um Direktnachrichten an Genehmigungsberechtigte, eine Verteilung an den ursprünglichen Chat und eine kanalspezifische interaktive Bedienoberfläche für Genehmigungen.

Wenn native Genehmigungskarten oder -schaltflächen verfügbar sind, ist diese native Benutzeroberfläche der primäre Pfad für den Agenten. Der Agent sollte nicht zusätzlich einen doppelten /approve-Befehl im normalen Chat ausgeben, sofern das Werkzeugergebnis nicht angibt, dass Chat-Genehmigungen nicht verfügbar sind oder eine manuelle Genehmigung der einzige verbleibende Pfad ist.

Wenn ein nativer Genehmigungsclient konfiguriert ist, aber für den ursprünglichen Kanal keine native Runtime aktiv ist, hält OpenClaw die lokale deterministische /approve-Aufforderung sichtbar. Wenn die native Runtime aktiv ist und eine Zustellung versucht, aber kein Ziel die Karte empfängt, sendet OpenClaw im selben Chat einen Fallback-Hinweis mit dem exakten Befehl /approve <id> <decision>, damit die Anfrage weiterhin bearbeitet werden kann.

Allgemeines Modell:

• Die Exec-Richtlinie des Hosts entscheidet weiterhin, ob eine Exec-Genehmigung erforderlich ist
• approvals.exec steuert die Weiterleitung von Genehmigungsaufforderungen an andere Chat-Ziele
• channels.<channel>.execApprovals steuert, ob kanalspezifische native Clients für Discord, Slack, Telegram, QQ bot und ähnliche Kanäle aktiviert sind
• Slack-Plugin-Genehmigungen können den nativen Genehmigungsclient von Slack verwenden, wenn die Anfrage aus Slack stammt und Slack-Plugin-Genehmigungsberechtigte aufgelöst werden können; approvals.plugin kann Plugin-Genehmigungen außerdem an Slack-Sitzungen oder -Ziele weiterleiten, selbst wenn Slack-Exec-Genehmigungen deaktiviert sind
• Native Genehmigungskarten von Google Chat verarbeiten Exec- und Plugin-Genehmigungen, die aus Google-Chat-Spaces oder -Threads stammen, wenn stabile users/<id>-Genehmigungsberechtigte aus dm.allowFrom oder defaultTo aufgelöst werden können; sie verwenden keine Reaktionsereignisse für Entscheidungen
• Die Zustellung von WhatsApp- und Signal-Reaktionsgenehmigungen wird durch approvals.exec und approvals.plugin gesteuert; sie verfügen über keine channels.<channel>.execApprovals-Blöcke

Native Genehmigungsclients aktivieren die Zustellung vorrangig per Direktnachricht automatisch, wenn alle folgenden Bedingungen erfüllt sind:

• Der Kanal unterstützt die native Genehmigungszustellung
• Genehmigungsberechtigte können aus expliziten execApprovals.approvers oder einer Eigentümeridentität wie commands.ownerAllowFrom aufgelöst werden
• channels.<channel>.execApprovals.enabled ist nicht festgelegt oder auf "auto" gesetzt

Setzen Sie enabled: false, um einen nativen Genehmigungsclient ausdrücklich zu deaktivieren. Setzen Sie enabled: true, um seine Aktivierung zu erzwingen, wenn Genehmigungsberechtigte aufgelöst werden können. Die öffentliche Zustellung an den ursprünglichen Chat bleibt über channels.<channel>.execApprovals.target explizit konfiguriert. Wenn das native target die Zustellung an den ursprünglichen Chat aktiviert, enthalten Genehmigungsaufforderungen den Befehlstext.

FAQ: Warum gibt es zwei Exec-Genehmigungskonfigurationen für Chat-Genehmigungen?

• Discord: channels.discord.execApprovals.*
• Slack: channels.slack.execApprovals.*
• Telegram: channels.telegram.execApprovals.*
• QQ bot: channels.qqbot.execApprovals.*
• Google Chat: Konfigurieren Sie stabile Genehmigungsberechtigte mit channels.googlechat.dm.allowFrom oder channels.googlechat.defaultTo; ein execApprovals-Block ist nicht erforderlich
• WhatsApp: Verwenden Sie approvals.exec und approvals.plugin, um Genehmigungsaufforderungen an WhatsApp weiterzuleiten
• Signal: Verwenden Sie approvals.exec und approvals.plugin, um Genehmigungsaufforderungen an Signal weiterzuleiten

Für native Clients spezifische Weiterleitung:

• Telegram verwendet standardmäßig Direktnachrichten an Genehmigungsberechtigte (target: "dm"). Wechseln Sie zu channel oder both, um Genehmigungsaufforderungen auch im ursprünglichen Telegram-Chat oder -Thema anzuzeigen. Bei Telegram-Forenthemen behält OpenClaw das Thema sowohl für die Genehmigungsaufforderung als auch für die anschließende Nachricht nach der Genehmigung bei.
• Genehmigungsberechtigte für Discord und Telegram können explizit angegeben (execApprovals.approvers) oder aus commands.ownerAllowFrom abgeleitet werden; nur aufgelöste Genehmigungsberechtigte können genehmigen oder ablehnen.
• Slack-Genehmigungsberechtigte können explizit angegeben (execApprovals.approvers) oder aus commands.ownerAllowFrom abgeleitet werden. Direktnachrichten für Slack-Plugin-Genehmigungen verwenden Slack-Plugin-Genehmigungsberechtigte aus allowFrom und die Standardweiterleitung des Kontos, nicht die Genehmigungsberechtigten für Slack-Exec. Native Slack-Schaltflächen bewahren die Art der Genehmigungs-ID, sodass plugin:-IDs Plugin-Genehmigungen ohne eine zweite lokale Slack-Fallback-Ebene bearbeiten können.
• Native Google-Chat-Karten bewahren den manuellen /approve-Fallback im Nachrichtentext, aber Rückrufe von Kartenschaltflächen übertragen nur undurchsichtige Aktionstoken; die Genehmigungs-ID und die Entscheidung werden aus dem serverseitigen ausstehenden Zustand wiederhergestellt.
• WhatsApp-Emoji-Genehmigungen verarbeiten sowohl Exec- als auch Plugin-Aufforderungen, wenn die entsprechende Weiterleitungsfamilie auf oberster Ebene an WhatsApp weiterleitet. Aufforderungen nativen Ursprungs werden direkt gebunden; bei der Zustellung im gemeinsamen Zielmodus werden dieselben typisierten Genehmigungsmetadaten an die akzeptierte WhatsApp-Empfangsbestätigung gebunden.
• Signal-Reaktionsgenehmigungen verarbeiten Exec- und Plugin-Aufforderungen nur, wenn die entsprechende Weiterleitungsfamilie auf oberster Ebene aktiviert ist und an Signal weiterleitet. Direkte Signal-Exec-Genehmigungen im selben Chat können den lokalen /approve-Fallback ohne explizite Genehmigungsberechtigte unterdrücken; die Auflösung von Signal-Reaktionen erfordert weiterhin explizite Signal-Genehmigungsberechtigte aus channels.signal.allowFrom oder defaultTo.
• Die native Matrix-Weiterleitung per Direktnachricht oder Kanal sowie Reaktionskürzel verarbeiten sowohl Exec- als auch Plugin-Genehmigungen; die Plugin-Autorisierung stammt weiterhin aus channels.matrix.dm.allowFrom. Native Matrix-Aufforderungen enthalten beim ersten Aufforderungsereignis benutzerdefinierte com.openclaw.approval-Ereignisinhalte, sodass OpenClaw-kompatible Matrix-Clients strukturierte Genehmigungszustände lesen können, während Standardclients den Klartext-Fallback /approve beibehalten.
• Native Genehmigungsschaltflächen von Discord und Telegram übertragen in transportprivaten Rückrufdaten eine explizite Eigentümerart für Exec oder Plugin und lösen nur diesen Eigentümer auf. Ältere /approve-Steuerelemente ohne Art bleiben ein begrenzter Kompatibilitätspfad: Sie versuchen nur Eigentümerarten, die der Akteur genehmigen darf, fahren nur nach dem Ergebnis „Genehmigung nicht gefunden“ fort und leiten die Eigentümerschaft niemals aus der Genehmigungs-ID ab.
• Die anfragende Person muss nicht genehmigungsberechtigt sein.
• Wenn keine Bedienoberfläche oder kein konfigurierter Genehmigungsclient die Anfrage annehmen kann, greift die Aufforderung auf askFallback zurück.

Sensible, ausschließlich Eigentümern vorbehaltene Gruppenbefehle wie /diagnostics und /export-trajectory verwenden eine private Eigentümerweiterleitung für Genehmigungsaufforderungen und endgültige Ergebnisse. OpenClaw versucht zunächst eine private Route auf derselben Oberfläche, auf der der Eigentümer den Befehl ausgeführt hat. Wenn diese Oberfläche über keine private Eigentümerroute verfügt, greift OpenClaw auf die erste verfügbare Eigentümerroute aus commands.ownerAllowFrom zurück. Dadurch kann ein Discord-Gruppenbefehl die Genehmigung und das Ergebnis weiterhin an die Telegram-Direktnachrichten des Eigentümers senden, wenn Telegram als primäre private Oberfläche konfiguriert ist. Der Gruppenchat erhält nur eine kurze Bestätigung.

Siehe:

• Discord
• Telegram
• QQ bot

Offizielle mobile Bedien-Apps

Die offiziellen iOS- und Android-Apps können außerdem ausstehende Exec-Genehmigungen im Besitz des Gateways prüfen, wenn eine operator.admin-Verbindung verwendet wird oder wenn das gekoppelte operator.approvals-Gerät ausdrücklich als Ziel der Anfrage angegeben wurde. Sie lesen denselben bereinigten, dauerhaften Datensatz, den die Control UI verwendet, übermitteln eine Entscheidung unter Berücksichtigung der Art und zeigen das kanonische Ergebnis der ersten Antwort des Gateways an. Die Apple Watch spiegelt diese Genehmigungsaufforderungen über das gekoppelte iPhone und bietet Aktionen zum einmaligen Zulassen und Ablehnen. Im direkten Watch-Gateway-Modus werden Genehmigungen nicht geprüft.

Eine verloren gegangene Bestätigung der Bearbeitung macht die übermittelte Auswahl nicht maßgeblich: Die App deaktiviert die Steuerelemente und liest den Datensatz erneut. Wenn eine andere Oberfläche zuerst war, zeigt die App die dort erfasste Entscheidung an. Ausstehende Aufforderungen bleiben an das Gateway gebunden, das sie ausgegeben hat. Daher kann der Wechsel des aktiven Gateways eine alte Genehmigungs-ID nicht umleiten.

macOS-IPC-Ablauf

OC_I18N_900004 Sicherheitshinweise:

• Unix-Socket-Modus 0600, Token in exec-approvals.json gespeichert.
• Überprüfung auf dieselbe UID.
• Challenge-Response (Nonce + HMAC-Token + Anfrage-Hash) + kurze TTL.

FAQ

Wann werden accountId und threadId für ein Genehmigungsziel verwendet?

Verwenden Sie accountId, wenn für den Kanal mehrere Identitäten konfiguriert sind und die Genehmigungsaufforderung über ein bestimmtes Konto gesendet werden muss. Verwenden Sie threadId, wenn das Ziel Themen oder Threads unterstützt und die Aufforderung innerhalb dieses Threads statt im Chat auf oberster Ebene verbleiben soll.

Ein konkreter Telegram-Fall ist eine Betriebs-Supergruppe mit Forenthemen und zwei Telegram-Bot-Konten. Der Wert to bezeichnet die Supergruppe, accountId wählt das Bot-Konto aus und threadId wählt das Forenthema aus: OC_I18N_900005 Mit dieser Einrichtung werden weitergeleitete Exec-Genehmigungen durch das Telegram-Konto ops-bot im Thema 77 des Chats -1001234567890 veröffentlicht. Ein Ziel ohne accountId verwendet das Standardkonto des Kanals, und ein Ziel ohne threadId veröffentlicht am Ziel auf oberster Ebene.

Kann jede Person in einer Sitzung dort eingehende Genehmigungen erteilen?

Nein. Die Sitzungszustellung steuert nur, wo die Aufforderung erscheint. Sie autorisiert nicht von sich aus alle Teilnehmenden dieses Chats zur Genehmigung.

Für das allgemeine /approve im selben Chat muss die absendende Person bereits für Befehle in dieser Kanalsitzung autorisiert sein. Wenn der Kanal explizite Genehmigungsberechtigte bereitstellt, können diese die /approve-Aktion autorisieren, auch wenn sie ansonsten in dieser Sitzung nicht zur Ausführung von Befehlen autorisiert sind.

Einige Kanäle sind strenger. Discord, Telegram, Matrix, native Direktnachrichten für Slack-Genehmigungen und ähnliche native Genehmigungsclients verwenden ihre aufgelösten Listen der Genehmigungsberechtigten zur Genehmigungsautorisierung. Beispielsweise kann eine Genehmigungsaufforderung in einem Telegram-Forenthema für alle Personen im Thema sichtbar sein, aber nur numerische Telegram-Benutzer-IDs, die aus channels.telegram.execApprovals.approvers oder commands.ownerAllowFrom aufgelöst wurden, können sie genehmigen oder ablehnen.

Verwandte Themen

• Exec-Genehmigungen — zentrale Richtlinie und Genehmigungsablauf
• Exec-Werkzeug
• Erweiterter Modus
• Skills — durch Skills unterstütztes automatisches Zulassungsverhalten