Copilot Computer Use: Klick-Rechte ohne API, Approval vor jedem Griff

Den Expense-Report, an dem ich neulich gescheitert bin, hätte ich gern an Copilot auf dem Desktop abgegeben, aber dazu hätte das Approval meiner Chefin gefehlt (und, ehrlich gesagt, ein Programm, das so etwas überhaupt zulässt).

Die Szene, falls Sie sie brauchen: ein Dienstagnachmittag, fünf Belege, ein Spesenformular in einer Software, die aussieht, als hätte sie Windows XP nie verlassen. Keine Schnittstelle, keine Kommandozeile, nur Felder und ein Absenden-Knopf. Ich tippte das Datum im falschen Format, das Formular verwarf stillschweigend drei Zeilen, und ich bemerkte es erst, nachdem ich auf Senden geklickt hatte. Der Report ging ohne Anhang raus. Die Buchhaltung antwortete in einem Ton, den ich als freundlich-enttäuscht beschreiben würde. Mein Kaffee war da längst kalt.

Am 1. Oktober 2026 hat GitHub im Changelog verkündet, dass Computer Use als Public Preview in der Copilot CLI und in der GitHub Copilot app läuft, auf macOS und Windows. Copilot kann demnach Desktop-Anwendungen im Auftrag der Nutzenden bedienen: zugängliche App-Inhalte und visuellen Kontext lesen, Steuerelemente anklicken, Text eingeben und bearbeiten, Tasten drücken, scrollen, ziehen und Abläufe über mehrere Anwendungen hinweg durchlaufen.

Besonders interessant finde ich den Zusatz: Das gilt laut GitHub auch für Legacy- und GUI-only-Software, die keine API, keine Kommandozeile und keine MCP-Integration anbietet. Genau meine Spesensoftware also. Ich halte das für einen ehrlichen Anwendungsfall, gerade weil er so unglamourös ist.

Um den Rest geht es hier: was Copilot dabei tatsächlich tut, wo das Approval sitzt und warum der Desktop trotzdem Ihrer bleibt. Wir bei digital-magazin.de lesen Changelogs gern zweimal, einmal für die Schlagzeile und einmal für das Kleingedruckte. Ein Spoiler: Das Kleingedruckte ist hier der interessantere Teil.

Der Desktop ist kein Spielplatz, und GitHub behandelt ihn auch nicht so. Copilot fragt vor dem Zugriff, und dieses Approval ist der Kern der Sache, nicht die Fußnote. Es ist, wenn man so will, der Grund, warum ich überhaupt weiterlese.

Copilot auf dem Desktop: die Public Preview, ohne Märchen

Fangen wir mit der Nüchternheit an. Public Preview heißt, dass GitHub die Funktion zum Ausprobieren freigibt, nicht, dass sie fertig geschliffen ist. Verfügbar ist sie in zwei Oberflächen, der Copilot CLI und der GitHub Copilot app, und auf zwei Betriebssystemen, macOS und Windows. Mehr steht nicht im Changelog, und ich schreibe auch nicht mehr hinein.

Was Copilot auf dem Desktop tun darf, listet GitHub konkret auf, und ich habe die Verben oben schon genannt. Das ist ein Werkzeug mit engem Auftrag, kein Geist im Rechner. Wer sich einen Agenten vorstellt, der magisch auf dem Desktop wohnt, alles sieht und alles weiß, wird im Text nirgends fündig. Stattdessen: ein Satz Computer-Use-Werkzeuge, die der Agent in Ihrem Namen bedient. Dass davor ein Approval wartet, kommt gleich.

Und die Zielgruppe? GitHub nennt Workflows in Legacy- und GUI-only-Software. Also das Zeug, für das niemand mehr eine Schnittstelle baut. Wer Systeme hat, die schon eine Schnittstelle anbieten, ist mit klassischer Automatisierung besser bedient; dazu passt unser Überblick über Workflow-Muster mit Zapier, Make und Asana, bei denen die Daten über Anschlüsse laufen und niemand Knöpfe drücken muss. Auf dem Desktop landet, was sonst nirgends ankommt, und Copilot soll dort klicken.

GitHub zeigt dazu ein Video, dessen Unterschrift sinngemäß lautet: Copilot navigiert mit Computer-Use-Werkzeugen durch einen Expense-Report-Workflow in Safari. Das ist GitHubs Vorführung, kein Wert, den ich nachgemessen hätte. Ich nenne hier also keine Zahl, sondern nur die Szene, die GitHub selbst beschreibt. Wie schnell oder langsam der Ablauf bei Ihnen läuft, hängt von der Software, dem Rechner und Ihrer Beschreibung ab.

Mir ist an dieser Stelle wichtig, die Erwartung klein zu halten. Ich halte die Preview für einen sinnvollen Schritt, aber nicht für ein Versprechen, dass morgen jede Altlast von allein ihre Formulare ausfüllt. Wer Copilot einen Auftrag gibt, gibt ihm einen Auftrag auf dem eigenen Desktop, mit allen Macken der Oberfläche. Und wer das Approval wegklickt, ohne zu lesen, hat die Kontrolle schon abgegeben, bevor der erste Klick passiert.

Eine Randbemerkung zur Einordnung: Wir bei digital-magazin.de haben schon über Assistenten im Editor geschrieben, etwa über KI im Editor mit Agenten und Diktat. Dort arbeitet die Maschine in einer Umgebung, die für Maschinen gebaut wurde. Auf dem Desktop ist es umgekehrt: Die Oberfläche wurde für Menschen gebaut, und Copilot muss sich hineinfinden.

Approval, bevor Copilot den Desktop anfasst

Jetzt zum Kern. GitHub schreibt im Changelog: Copilot fragt um Approval, bevor es eine Anwendung steuert. Das ist ein einzelner Satz, und er trägt die ganze Konstruktion. Ohne ihn wäre die Funktion ein Fernsteuerungswerkzeug mit freundlichem Namen, mit ihm ist sie ein Auftrag, den Sie Schritt für Schritt erteilen.

Was heißt das praktisch? Der Agent bekommt nicht den ganzen Desktop geschenkt. Er bekommt die Anwendung, für die Sie das Approval erteilt haben. Ich lese den Changelog so, dass die Freigabe an die jeweilige App gebunden ist, denn GitHub spricht davon, dass Sie Apps prüfen und zurücksetzen können, die Sie dauerhaft erlaubt haben. Eine Liste einzelner Anwendungen setzt eine Freigabe pro Anwendung voraus. Das ist mein Schluss daraus aus dem Wortlaut, keine Zusage von GitHub.

Warum ich das für klug halte? Weil der Desktop der Ort ist, an dem alles zusammenliegt. Das Mailprogramm, die Spesensoftware, der Passwortmanager, das halb fertige Dokument mit dem Namen „final_neu_wirklich“. Ein Approval pro Anwendung zwingt zu einer Frage, die ich mir sonst nie stellen würde: Braucht Copilot für diese Aufgabe wirklich dieses Programm?

Das Approval als Gespräch, nicht als Hürde

Viele Menschen klicken Dialoge weg, ich auch. Das Approval-Fenster ist deshalb eine Prüfung für uns, nicht für die Maschine. Ich nehme mir vor, jedes Mal kurz zu lesen, welche Anwendung gemeint ist und was ich gerade beauftragt habe. Das kostet Sekunden. Eine versehentlich freigegebene App kann dagegen einen langen Nachmittag kosten.

Stellen Sie sich meine Spesensoftware vor. Ich sage Copilot: Trage diese fünf Belege ein. Das Approval erscheint, ich erlaube genau dieses Programm, und der Agent sieht Felder, Knöpfe und das Datumsformat, an dem ich gescheitert bin. Das Mailprogramm daneben bleibt außen vor, solange ich es nicht freigebe. So stelle ich mir einen vernünftigen Auftrag vor.

Dazu passt, was wir an anderer Stelle über Regeln, Rechte und Notaus geschrieben haben, nämlich dass Freigaben für Agenten mehr sind als ein Klick: Sie gehören in eine Struktur, in der klar ist, wer was erlauben darf und wie man es wieder abschaltet. Das Approval auf dem Desktop ist die kleinste Einheit dieser Struktur. Es sitzt direkt bei der Person, die am Rechner arbeitet.

Was das Approval nicht ist

Ein Approval ist keine Garantie, dass Copilot alles richtig macht. Es sagt nur: Ja, diese Anwendung darf bedient werden. Ob das Datum im richtigen Format landet, ob der Betrag stimmt, ob der Anhang wirklich hängt, bleibt Ihre Kontrolle. Die Freigabe ersetzt nicht den Blick aufs Ergebnis. Das klingt banal, aber ich habe mein Spesenformular auch schon abgeschickt, ohne aufs Ergebnis zu schauen.

Und noch etwas: Das Approval ist kein Weg, Schutzmechanismen auszuhebeln. Ich beschreibe hier keinen Trick, sondern das vorgesehene Verfahren. Wer an dieser Stelle nach Abkürzungen sucht, hat die Idee der Funktion missverstanden.

Was Copilot auf dem Desktop laut GitHub wirklich tut

Gehen wir die Verben noch einmal einzeln durch, denn sie sind der eigentliche Vertrag. Laut Changelog kann Copilot zugängliche App-Inhalte und visuellen Kontext lesen. Es kann Steuerelemente anklicken, Text eingeben und bearbeiten, Tasten drücken, scrollen und ziehen. Und es kann Abläufe über mehrere Anwendungen hinweg durchlaufen. Mehr steht dort nicht, und weniger auch nicht.

Das Lesen kommt zuerst, und das ist logisch. Bevor ein Agent klickt, muss er wissen, was auf dem Bildschirm steht. „Zugängliche App-Inhalte“ heißt in meiner Lesart: das, was die Anwendung nach außen sichtbar macht, dazu der visuelle Kontext, also das, was Sie auch sehen würden. Wie genau GitHub das technisch löst, steht im Changelog nicht, und ich rate nicht.

Das Handeln kommt danach. Klicken, tippen, Tasten drücken, scrollen, ziehen: Das sind die Handgriffe, die Sie selbst täglich machen, nur eben delegiert. Für das Ziehen denke ich an ein Element, das in einer Altanwendung von einer Liste in die andere gehört. Für das Scrollen an die endlose Tabelle, in der die richtige Zeile ganz unten steht. Alles Alltag, alles langweilig, und genau deshalb ein guter Fall.

Mehrere Anwendungen, ein Ablauf

Der interessanteste Punkt steht fast am Ende: Abläufe über mehrere Anwendungen hinweg. Eine Information aus dem Browser in ein Formular übertragen, ein Ergebnis aus einer Präsentation in eine andere Software tragen. GitHub nennt als Beispiele, Benachrichtigungen in einem Browser zusammenzufassen, Inhalte in einer Präsentation zu aktualisieren oder Informationen durch einen Workflow in einer Desktop-Anwendung zu bewegen.

Beachten Sie, was dabei passiert: Jede beteiligte Anwendung braucht ihr eigenes Approval. Der Ablauf ist am Ende nur so sicher wie die schwächste Freigabe in der Kette. Ich würde deshalb bei mehrstufigen Aufträgen vorher aufschreiben, welche Programme beteiligt sind, und nur diese erlauben.

Legacy ohne Schnittstelle

Der Satz, der mich am meisten überzeugt, betrifft Software ohne API, ohne Kommandozeile und ohne MCP-Integration. GitHub schreibt, dass sich die Aufgaben, bei denen Copilot helfen kann, damit erweitern. Wer die Welt der Anschlüsse kennt, versteht den Unterschied: Bei einer Erweiterung über Anschlüsse spricht der Assistent mit dem System. Das haben wir in unserem Beitrag über Copilot-Erweiterungen, die den Code-Assistenten mit anderen Diensten verbinden, beschrieben. Auf dem Desktop spricht Copilot nicht mit dem System, sondern bedient die Oberfläche.

Das ist langsamer als ein Anschluss, soweit ich es einschätze, und anfälliger für Änderungen am Layout. Aber es ist der einzige Weg, wenn kein Anschluss existiert. Ich traue der Methode zu, genau diese Lücke zu füllen, und nicht mehr. Wo es eine Schnittstelle gibt, nehme ich die Schnittstelle.

Was ich hier nicht behaupte

Der Changelog nennt keine Erfolgsquoten, keine Dauer, keine Vergleichswerte. Also gibt es hier auch keine. Die Safari-Szene im GitHub-Video ist eine Vorführung. Sie zeigt, dass ein Expense-Report-Ablauf möglich ist, und nicht, wie oft er bei Ihnen klappt. Wer sich auf ein Video verlässt, kauft die Katze im Sack, und ich sage das als jemand, der die Katze schon gekauft hat.

Was die Doku dazu im Einzelnen sagt, lesen Sie am besten selbst nach: Sie finden sie unter GitHubs Dokumentation zu Computer Use in der CLI und der App. Der Changelog verweist mit „Learn more“ genau dorthin.

Approval zurückholen, Always-allow und der Organisationsschalter

Dieses Bild wurde komplett mit KI generiertProviderhiggsfieldModellgpt_image_2PromptPhotorealistic close photo of an adult hand hovering above a mouse without clicking, monitor out of focus and blank, no logos, no readable text, no watermarks, 16:9

Ein Approval, das sich nicht zurücknehmen lässt, wäre eine Einbahnstraße. GitHub schreibt, dass Sie Apps, für die Sie Always-allow gewählt haben, prüfen oder zurücksetzen können. Das ist die Gegenseite der Bequemlichkeit: Wer einmal dauerhaft erlaubt, kann später nachsehen, was er erlaubt hat, und es widerrufen.

Always-allow ist verführerisch. Wenn Copilot jedes Mal fragt, nervt das irgendwann, und die Versuchung ist groß, einmal „immer erlauben“ zu wählen. Hier kommt meine Einschätzung, und ich kennzeichne sie als solche: Für eine Legacy-Oberfläche mit Dauerfreigabe wäre ich vorsichtig. Solche Programme haben oft weitreichende Rechte, keine Rückfragen und keinen Papierkorb. Ein falscher Klick löscht dort, was kein Mensch wiederherstellt. GitHub warnt davor nicht ausdrücklich, das sage ich ausdrücklich dazu. Es ist meine Lesart, nicht die von GitHub.

Die Dauerfreigabe als Inventar

Ich würde die Liste der dauerhaft erlaubten Anwendungen wie ein Schlüsselbund behandeln: ab und zu durchsehen, jeden Schlüssel fragen, ob er noch gebraucht wird. Im Ernst, wer weiß schon nach einem halben Jahr, welche Programme er irgendwann einmal durchgewunken hat? Das Zurücksetzen ist der Moment, in dem aus einem vergessenen Klick wieder eine bewusste Entscheidung wird.

Eine einfache Gewohnheit hilft: Nach einem abgeschlossenen Projekt prüfe ich, was Copilot noch darf, und nehme zurück, was nicht mehr nötig ist. Das ist keine Raketenwissenschaft, nur Hygiene, wie das Aufräumen des Desktops nach der Steuererklärung. Die Belege landen in der Ablage, die Freigabe im Papierkorb.

Rechte auf dem Mac

Auf macOS führt die Funktion laut Changelog durch die nötigen Systemrechte. GitHub nennt Accessibility und Screen Recording. Das sind Rechte, die das Betriebssystem ohnehin verlangt, wenn ein Programm andere Programme lesen oder bedienen will. Dass Computer Use Sie dabei begleitet, spart Suchen in den Einstellungen. Mehr ist es nicht, und ich will es auch nicht größer machen: Das ist keine Bewertung der Sicherheit, sondern ein Hinweis, dass der Mac hier mitreden darf.

Für Windows nennt der Changelog keine solchen zwei Rechte, und ich erfinde keine. Wer Windows nutzt, sollte in der Doku nachsehen, was dort gilt. Ich lasse die Lücke lieber sichtbar, als sie mit Vermutungen zu füllen.

Der Schalter der Organisation

Zuletzt der Absatz für alle, die nicht allein am Rechner sitzen. Laut Changelog können organisationsverwaltete Einstellungen die Funktion abschalten. In welchem Menü das passiert, steht dort nicht, also steht es auch hier nicht. Wichtig ist das Prinzip: Selbst wenn Sie persönlich Copilot auf dem Desktop einsetzen wollen, kann Ihre Organisation entscheiden, dass es nicht geht.

Das finde ich richtig. Ein Desktop in einem Unternehmen enthält Dinge, die nicht allein den Nutzenden gehören: Kundendaten, interne Dokumente, Zugänge. Dass die administrierende Person hier einen Riegel hat, ist kein Misstrauen gegen Sie, sondern eine Absicherung, die Sie im Zweifel selbst schützt. Wer die Funktion vermisst, fragt am besten zuerst die zuständige Stelle, bevor er an den Einstellungen herumsucht.

CLI und App: Copilot einschalten, der Desktop bleibt Ihrer

Nun zum praktischen Teil, und ich halte mich eng an den Changelog. Es gibt zwei Einstiege. In der Copilot CLI schalten Sie die Funktion mit einem Befehl ein, in der GitHub Copilot app über die Einstellungen. Beides ist schnell erledigt.

• In der Copilot CLI führen Sie /computer on aus. Mit /computer show prüfen Sie den Status, mit /computer off schalten Sie die Funktion ab.
• In der GitHub Copilot app öffnen Sie Settings, wählen Computer Use und aktivieren Enable Computer Use. Alternativ geht dort ebenfalls /computer on.

Das sind alle Schalter, die der Changelog nennt. Ich erfinde keine weiteren, auch wenn ich mir manchmal einen Befehl für „alles zurück auf Anfang“ wünschen würde. Zwei Dinge fallen mir auf. Erstens gibt es einen eigenen Befehl, um den Status zu zeigen, was ich für ehrlich halte: Man soll nachsehen können, ob der Agent gerade mitlesen darf. Zweitens gibt es einen klaren Aus-Schalter, und der gehört in jedes Werkzeug dieser Art.

Ein Einschalten, das noch nichts freigibt

Wichtig ist die Reihenfolge. Das Einschalten der Funktion ist nicht das Approval. Erst wenn Copilot eine konkrete Anwendung steuern will, fragt es nach. Der Schalter öffnet die Tür einen Spalt, das Approval entscheidet, wer hindurchgeht. Ich vergleiche das gern mit dem Einschalten des Herds: Er ist an, aber noch kocht nichts.

Wenn Sie mit der Funktion nicht arbeiten, lassen Sie sie aus. Mit /computer off ist das eine Sache von Sekunden. Ich würde den Schalter nach der Arbeit auch wieder umlegen, zumindest in der Anfangszeit, in der man noch lernt, wie sich Copilot auf dem eigenen Desktop verhält.

Der Desktop bleibt Ihrer

Der Titel dieses Abschnitts ist mehr als eine Überschrift. GitHub schreibt: You remain in control. Sie behalten die Kontrolle. Das stimmt aber nur, solange Sie sie auch ausüben. Der Agent klickt, aber Sie entscheiden, welche Anwendung, welcher Auftrag, wie lange. Wer während eines Laufs den Bildschirm im Blick behält, sieht, wenn etwas schiefgeht, und kann eingreifen.

Das ist die kurze Version der Verantwortung. Die lange Version lautet: Sie sind für alles verantwortlich, was in Ihrem Namen passiert. Das gilt für den Kollegen, dem Sie Ihr Passwort leihen, und es gilt für einen Agenten, den Sie auf Ihren Desktop lassen. Mehr als ein Hilfsmittel wird auch Copilot nicht, und wenn etwas schiefgeht, steht am Ende Ihr Name unter dem Spesenbericht.

Mir ist beim Schreiben aufgefallen, wie leicht man vergisst, dass hier jemand mit Ihren Rechten arbeitet. Nicht jemand mit eigenen, sondern mit Ihren. Das Approval macht diesen Unterschied kurz sichtbar. Danach liegt es an Ihnen, ihn im Kopf zu behalten.

Ohne Outcome bleibt das Approval ein teurer Kreis

Jetzt der Teil, der klingt einfach, ist es aber nicht: der Auftrag selbst. GitHub schreibt, Computer Use funktioniere am besten, wenn Sie das gewünschte Ergebnis beschreiben, die beteiligten Anwendungen nennen und wichtige Randbedingungen angeben. Outcome, Anwendungen, Constraints. Drei Bausteine, und ohne sie dreht sich der Agent im Kreis, während Sie ein Approval nach dem anderen erteilen.

Dazu ein Gedankenexperiment, ausdrücklich keine Messung und ohne jede Zahl aus der Praxis. Nehmen wir an, ich sage Copilot nur: Mach meine Spesen. Kein Ergebnis, keine Programme, keine Grenzen. Dann kann derselbe Expense-Report dreimal scheitern, jedes Mal anders. Einmal wird das falsche Datumsformat gewählt, einmal ein Beleg vergessen, einmal die falsche Kostenstelle erwischt. Und jedes Mal frage ich mich, ob ich nicht besser selbst geklickt hätte.

Beschreibe ich dagegen den Outcome (alle Belege eingetragen und angehängt, Report im System gespeichert, aber noch nicht abgesendet), nenne die Anwendungen (nur die Spesensoftware, daneben der Ordner mit den Belegen) und die Randbedingungen (Datum im Format der Software, keine Änderung an bestehenden Reports), dann hat der Agent eine Landkarte. Das ist kein Zaubertrick, sondern gute Delegation, wie Sie sie von Menschen kennen.

Warum „teurer Kreis“

Der Titel sagt „teurer Kreis“, und ich meine das nicht in Geld, denn Preise nennt der Changelog nicht. Ich meine Aufmerksamkeit. Ein schlecht beschriebener Auftrag erzeugt Rückfragen, neue Läufe, neue Freigaben und am Ende doch Handarbeit. Jedes Approval kostet einen Moment Konzentration, und wer sie verschwendet, hat bald keine mehr für die Fälle, in denen sie zählt.

Darum der Satz, den ich mir über den Schreibtisch hängen würde: Erst das Ergebnis beschreiben, dann freigeben. Nicht umgekehrt. Wer zuerst erlaubt und dann überlegt, was der Agent tun soll, hat die Reihenfolge verdreht. Das Approval ist das Ende der Planung, nicht ihr Anfang.

Ein Auftrag, der trägt

Was gehört in eine gute Beschreibung? Aus dem Changelog lässt sich das gut ableiten. Das Ziel in einem Satz. Die Anwendungen beim Namen. Dann die Grenzen, die für Sie nicht verhandelbar sind: was nicht gelöscht, nicht abgeschickt, nicht überschrieben werden darf. Dazu vielleicht eine Anweisung, bei Unsicherheit nachzufragen, statt zu raten. Ob jeder Agent so etwas zuverlässig befolgt, kann ich nicht versprechen, aber die Chance steigt mit der Klarheit.

Ein Beispiel aus GitHubs eigener Liste: Benachrichtigungen im Browser zusammenfassen. Das lässt sich klar fassen. Welcher Browser, welche Seite, welcher Zeitraum, in welcher Form die Zusammenfassung erscheinen soll. Wer das offenlässt, bekommt eine Antwort, die irgendwie passt und doch nicht stimmt.

Und die Kontrolle danach? Sie bleibt. Ich schaue mir immer das Ergebnis an, bevor etwas Endgültiges passiert. Bei meinem Spesenbericht heißt das: Der Agent speichert, ich sende ab. So bleibt der letzte Klick bei mir, und die Buchhaltung bekommt keine freundlich-enttäuschte Antwort mehr, zumindest nicht von mir.

Public Preview bleibt Public Preview

Ein letzter Gedanke zur Einordnung. Der Changelog sagt „public preview“, und mehr nicht. Meine Einschätzung, ausdrücklich als solche: Ich rechne damit, dass sich an Bedienung und Umfang noch etwas verändert, denn so ist das bei Vorabversionen meistens. Das ist keine Aussage von GitHub, und ich behaupte nicht, wann oder wie oft das passiert. Ich rate nur dazu, Abläufe, die auf dieser Funktion beruhen, nicht als fest verdrahtet zu betrachten.

Was bleibt am Ende? Copilot kann auf Ihrem Desktop klicken, tippen und lesen, auch in Programmen, die niemand mehr mit einer Schnittstelle versieht. Das Approval sitzt vor jeder Steuerung, Always-allow lässt sich prüfen und zurücksetzen, und Organisationen können die Funktion abschalten. Der Rest ist Ihre Sorgfalt: ein klarer Auftrag, ein offener Blick auf das Ergebnis und keine Dauerfreigabe aus reiner Bequemlichkeit.

Wir bei digital-magazin.de bleiben deshalb bei einer nüchternen Haltung. Probieren Sie es an einer Aufgabe aus, die Sie im Zweifel selbst in Ruhe nacharbeiten können, und nicht an der Software, in der ein falscher Klick eine Buchung auslöst. Mein nächster Versuch gilt wieder dem Spesenformular, diesmal mit einem klaren Auftrag, einem bewusst erteilten Approval und einem Kaffee, der warm bleibt.