GitHub Copilot steuert jetzt Desktop-Apps: Was Computer Use wirklich kann

Was GitHub am 1. Oktober veröffentlicht hat

GitHub hat Computer Use am 1. Oktober 2026 als öffentliche Vorschau für Copilot CLI und die GitHub-Copilot-App freigegeben. Verfügbar ist die Funktion laut offizieller Ankündigung auf macOS und Windows. Sie erweitert Copilot um die Fähigkeit, grafische Desktop-Anwendungen zu bedienen.

Damit richtet sich Copilot nicht mehr nur an Quellcode, Terminals und strukturierte Werkzeuge. GitHub nennt ausdrücklich ältere Programme und reine GUI-Anwendungen ohne API, Kommandozeile oder MCP-Anbindung als Einsatzgebiet. Ein Agent kann dadurch Arbeitsschritte übernehmen, die bisher nur über Maus, Tastatur und sichtbare Bedienoberflächen erreichbar waren.

Die Bezeichnung öffentliche Vorschau ist wichtig: GitHub erklärt, dass sich die Funktion noch ändern kann. Die Veröffentlichung belegt deshalb eine verfügbare Vorschau, aber weder allgemeine Produktionsreife noch fehlerfreie Automatisierung beliebiger Desktop-Prozesse.

Bestätigt ist eine öffentliche Vorschau in Copilot CLI und der Copilot-App auf macOS und Windows. Aussagen über Zuverlässigkeit, Geschwindigkeit oder Erfolgsquoten veröffentlicht GitHub in der Ankündigung nicht.

Welche Aktionen Computer Use ausführen kann

Nach GitHubs Dokumentation liest Computer Use Inhalte aus dem Accessibility-Baum des Betriebssystems und kann bei Bedarf visuellen Kontext über Bildschirmaufnahmen erfassen. Der Agent kann Schaltflächen anklicken, Text eingeben und bearbeiten, Tasten drücken, scrollen, Elemente ziehen und zwischen Anwendungen navigieren.

Als Beispiele nennt GitHub das Zusammenfassen von Informationen in einer Legacy-Anwendung, Änderungen an einer Präsentation, Dateneingaben in GUI-Software und mehrstufige Abläufe zwischen mehreren Programmen. Die Funktion ist damit ein Ausführungswerkzeug für visuelle Oberflächen, kein neues Sprachmodell und kein Ersatz für die Fachlogik der jeweiligen Anwendung.

GitHub empfiehlt weiterhin direkte Werkzeuge, wenn sie verfügbar sind. Eine API, ein MCP-Server, ein Terminalbefehl oder ein spezialisiertes Browserwerkzeug liefert meist strukturiertere Informationen und vorhersehbarere Ergebnisse als die Interpretation einer wechselnden Oberfläche.

• Zugängliche App-Inhalte und visuellen Kontext lesen
• Steuerelemente anklicken und Text bearbeiten
• Tasten drücken, scrollen und Elemente ziehen
• Arbeitsschritte über mehrere Anwendungen verbinden
• GUI- und Legacy-Software ohne direkte Schnittstelle bedienen

Aktivierung, Freigaben und Unternehmenskontrollen

Computer Use ist standardmäßig ausgeschaltet. In Copilot CLI lässt es sich mit dem Befehl /computer on aktivieren; in der App befindet sich die Einstellung im Bereich Computer Use. Vor der Steuerung einer Anwendung greifen die Werkzeugberechtigungen der jeweiligen Copilot-Oberfläche.

Nutzer können einen Zugriff für die aktuelle Sitzung erlauben, dauerhaft für eine bestimmte Anwendung speichern oder ablehnen. Dauerhafte Freigaben werden laut GitHub lokal gespeichert und gelten auf demselben Computer sowohl für die CLI als auch für die App. Sie lassen sich später in den Einstellungen wieder entfernen.

Für Organisationen gibt es eine zusätzliche Grenze: Administratoren können Computer Use über verwaltete Einstellungen deaktivieren. Eine lokale Aktivierung überstimmt diese Unternehmensrichtlinie nicht. Auf macOS werden außerdem Accessibility- und Screen-Recording-Berechtigungen des Betriebssystems benötigt.

Warum visuelle Automatisierung besondere Risiken trägt

Eine grafische Oberfläche ist weniger stabil als eine klar definierte Programmierschnittstelle. Schaltflächen können ihre Position ändern, Dialoge verspätet erscheinen und nicht standardisierte Bedienelemente für den Agenten schwer erkennbar sein. GitHub nennt ausdrücklich falsche Klicks, Texteingaben an der falschen Stelle, wiederholte Aktionen und abgebrochene Abläufe als mögliche Fehler.

Hinzu kommt der Inhalt auf dem Bildschirm. Unerwartete oder mehrdeutige Informationen können den Ablauf beeinflussen und Aktionen auslösen, die Geräte, Daten oder verbundene Konten betreffen. Sichtbare Fenster können zugleich personenbezogene, finanzielle oder unternehmensinterne Informationen enthalten.

GitHub betont deshalb, dass Computer Use menschliches Urteilsvermögen nicht ersetzt. Besonders vor Änderungen an Daten oder Aktionen mit Auswirkungen auf andere Personen sollten Zielanwendung, Berechtigungen und Ergebnis geprüft werden. Dauerhafte Freigaben sind für sensible oder folgenreiche Anwendungen ungeeignet.

Computer Use kann eine Oberfläche bedienen, versteht aber nicht automatisch alle fachlichen Folgen einer Aktion. Eine technisch erfolgreiche Eingabe kann geschäftlich trotzdem falsch sein.

Welche Prozesse sich für erste Tests eignen

Ein sinnvoller Pilot beginnt mit einem reversiblen, klar beobachtbaren Ablauf. Geeignet sind beispielsweise das Übertragen unkritischer Testdaten zwischen zwei Anwendungen, das Erstellen eines Präsentationsentwurfs oder das Auslesen einer Legacy-Maske in einer abgeschotteten Testumgebung.

Weniger geeignet sind zunächst Zahlungen, Massenänderungen, Personalakten, medizinische Daten oder produktive Administrationsoberflächen. Dort sind Fehlerfolgen hoch, Rücknahmen schwierig und sichtbare Informationen besonders sensibel. Auch eine dauerhafte Freigabe sollte nicht der Startpunkt eines Tests sein.

Teams sollten vorab festlegen, welche Anwendungen geöffnet werden dürfen, welche Daten sichtbar sein können, an welchen Stellen eine Bestätigung nötig ist und wie ein fehlerhafter Lauf gestoppt wird. In der Copilot CLI lässt sich eine laufende Operation laut GitHub mit zweimal Esc unterbrechen; in der App stehen Stop beziehungsweise Esc zur Verfügung.

• Mit Testdaten und reversiblen Arbeitsschritten beginnen
• Berechtigungen auf die notwendigen Anwendungen begrenzen
• Änderungen und externe Kommunikation vor der Ausführung bestätigen
• Abbruchweg und Wiederherstellung vor dem Pilotlauf testen
• Ergebnis nicht nur technisch, sondern fachlich kontrollieren

Was noch offen bleibt

Die öffentlichen GitHub-Seiten nennen keine belastbaren Erfolgsquoten für unterschiedliche Anwendungen. Ebenso fehlen vergleichbare Messwerte zu Bearbeitungszeit, Fehlerhäufigkeit und Ressourcenverbrauch. Wie zuverlässig ein Prozess funktioniert, muss deshalb für die konkrete Software und den konkreten Fensterzustand geprüft werden.

Die Ankündigung nennt auch keinen eigenen Preis nur für Computer Use. GitHub schreibt, dass die Vorschau in Copilot CLI und der Copilot-App verfügbar ist; für konkrete Plan-, Nutzungs- und Abrechnungsgrenzen bleiben die jeweils aktuellen Copilot-Bedingungen maßgeblich.

Unklar bleibt zudem, wie gut nicht standardisierte Oberflächen, virtuelle Desktops und stark dynamische Anwendungen in der Praxis funktionieren. Die offizielle Dokumentation warnt selbst davor, dass Unterschiede zwischen App-Versionen, Betriebssystemen und Fensterzuständen zu abweichenden Ergebnissen führen können.

Die MindrAils-Einordnung

Computer Use schließt eine reale Lücke: Viele betriebliche Abläufe hängen noch an Programmen ohne brauchbare Schnittstelle. Ein Agent, der solche Oberflächen bedienen kann, erweitert den erreichbaren Automatisierungsraum deutlich und kann Übergangslösungen ermöglichen, während bessere Integrationen fehlen.

Gerade diese Flexibilität macht das Werkzeug aber weniger vorhersehbar als eine API-basierte Automatisierung. Für wiederkehrende Kernprozesse bleibt eine strukturierte Schnittstelle meist die robustere Wahl. Computer Use eignet sich eher als kontrollierte Ergänzung, für seltene GUI-Schritte oder als Brücke in Altsystemen.

Der entscheidende Fortschritt ist daher nicht vollautonome Desktop-Arbeit, sondern ein zusätzlicher Werkzeugtyp unter klaren Berechtigungen. Wer ihn einführt, sollte Erfolg nicht an spektakulären Demos messen, sondern an reproduzierbaren Abläufen, begrenzten Fehlerfolgen und überprüfbaren Ergebnissen.