Codex Computer Use und der In-App-Browser in der Praxis: Seiten sehen, Apps bedienen und Frontend iterieren

Wenn Sie eine Frontend-Änderung machen und der Screenshot dem Agenten immer noch nicht zeigt, wie die Seite wirklich aussieht, wird der Loop schnell zäh. Was wäre, wenn der Agent den Browser selbst öffnen, die Seite ansehen, direkt dort kommentieren und weiterarbeiten könnte?

Auf macOS kann der Agent im Hintergrund mehrere Apps parallel bedienen, während Sie weiter Code schreiben. Auf Windows übernimmt er den Cursor, sodass Sie andere Arbeit pausieren müssen. Für Frontend-Iterationen wird daraus ein einfacher Loop: Code ändern, den Browser öffnen lassen, auf der Seite kommentieren, erneut iterieren. Genau darin liegen der praktische Wert von Computer Use und In-App-Browser. Plattformunterschiede bestimmen den Workflow, und Sicherheitsgrenzen bestimmen die Berechtigungen.

1. Computer Use Grundlagen: den Cursor verwenden, um Apps zu sehen, zu klicken und zu tippen

1.1 Nicht vollständige Übernahme, sondern “Sie geben das Ziel vor, Codex bedient die GUI”

Computer Use lässt Codex mit dem eigenen Cursor Apps auf Ihrem Computer sehen, anklicken und bedienen. Auch Desktop-Tools ohne öffentliche APIs gehören dazu. Wenn Sie zum Beispiel sagen “Konvertieren Sie dieses PDF in Word”, wechselt Codex den Fokus, klickt Fenster, tippt Text und schließt den GUI-Ablauf ab.

Das ist etwas anderes als ein Hintergrundskript. Auf Windows übernimmt Codex Ihren Cursor im Vordergrund. Auf macOS läuft er parallel im Hintergrund, sodass Sie in anderen Apps weiterarbeiten können.

Er löst vor allem zwei Arten von Aufgaben:

1. Tools ohne API bedienen: Design-Software, Systemeinstellungen und Desktop-Apps, solange die Aufgabe in einer GUI erledigt werden kann.
2. Aufgaben, bei denen die echte Oberfläche sichtbar sein muss: GUI-Debugging, Reproduktion von Design-Mockups und Tests für Desktop-Interaktionen.

1.2 macOS vs. Windows: Hintergrundparallelität vs. Vordergrundübernahme

Der größte Unterschied bei Computer Use ist die Frage, ob Sie parallel arbeiten können.

Wenn Sie macOS nutzen, ist Computer Use ein guter “Parallel-Assistent”: Sie lassen einen Agenten eine Design-App bedienen und schreiben im Editor weiter Code. Unter Windows sollten Sie dagegen einen Fokusblock einplanen: Codex übernimmt den Cursor, Sie pausieren andere Arbeit und warten auf den Abschluss.

2. Der In-App-Browser: Frontend ändern -> Seite öffnen -> dort kommentieren -> weitermachen

2.1 Der Frontend-Loop in 4 Schritten

Das Kernproblem, das der In-App-Browser löst, ist einfach: Der Agent ändert Frontend-Code, sieht aber nicht das echte Rendering. Ohne Browser bleiben nur Screenshots als Feedback.

Der Loop sieht so aus:

Railway - Moderne Deployment-Plattform, ohne DevOps-Aufwand, in Minuten live

Jetzt starten →Anzeige

1. Frontend ändern: Styles, Layout oder Interaktionslogik anpassen.
2. Browser öffnen: Codex localhost oder eine lokale Web-App öffnen lassen.
3. Auf der Seite kommentieren: direkt im Browser klicken, markieren und kommentieren, damit der Agent präzise Anweisungen bekommt.
4. Weiter iterieren: Der Agent nutzt das Feedback, passt erneut an und prüft das nächste Rendering.

So wird aus “Code ändern -> Screenshot schicken -> Feedback bekommen -> Code ändern” ein “Code ändern -> Seite ansehen -> kommentieren -> Code ändern”. Der Agent sieht das Rendering direkt, und Sie müssen nicht ständig Screenshots erstellen.

2.2 Derzeit vor allem für Frontend- und Game-Iterationen

Die aktuelle Positionierung ist klar: Der In-App-Browser ist vor allem für localhost-Web-Apps, Frontend-Entwicklung und Game-Entwicklung nützlich.

Die Erweiterung hin zu vollständiger Browserkontrolle läuft noch. Wenn Sie Codex externe Websites bedienen lassen möchten, etwa für Debugging in Produktion oder Tests auf Drittseiten, ist das derzeit noch eingeschränkt und hängt von zukünftigen Ausrollungen ab.

2.3 Developer Mode: Codex kontrollierten Chrome DevTools Protocol Zugriff geben

Developer Mode wurde am 2026-06-11 in Version 6.609 veröffentlicht und gibt Codex kontrollierten Zugriff auf das Chrome DevTools Protocol.

Damit lassen sich unter anderem folgende Dinge tun:

• Performance-Analyse: JavaScript profilieren und Renderzeiten messen
• Netzwerk-Debugging: Requests, Responses und Zeiten prüfen
• Console-Ausgaben: Laufzeitfehler und console.log lesen
• Seitenzustand prüfen: DOM und angewendete Styles inspizieren

Zusätzlich beschleunigt CDP die Iteration. DOM-Snapshots reduzieren wiederholtes Rendering und Screenshot-Transfer. Bei komplexen Seiten kann die Iteration bis zu 2x schneller werden, weil der Agent nicht jedes Mal die komplette Seite neu laden muss, sondern auf dem Snapshot weiterarbeitet.

Der Pfad zum Aktivieren ist Settings > Browser > Enable full CDP access. Wenn Ihre Organisation den Developer Mode deaktiviert, können Sie ihn lokal nicht aktivieren. Das ist eine Richtlinie auf Organisationsebene, keine persönliche Kontoeinstellung.

3. Appshots: auf macOS zweimal Command drücken und die App in einem Schritt an Codex senden

3.1 Kein normaler Screenshot, sondern “Screenshot + versteckter Text”

Appshots wurde am 2026-05-21 veröffentlicht und löst ein sehr konkretes Problem bei Screenshots: Inhalte außerhalb des sichtbaren Scrollbereichs sind schwer zu erfassen.

Wenn Sie die Command-Taste doppelt drücken, erfasst Codex einen Screenshot des vordersten App-Fensters plus den verfügbaren Text, inklusive Text außerhalb des sichtbaren Scrollbereichs. Wenn zum Beispiel ein Web-Fehlerstack unterhalb des sichtbaren Bereichs liegt und ein normaler Screenshot ihn nicht zeigt, kann Appshots den kompletten Seitentext extrahieren.

3.2 Typische Einsatzszenarien

Typische Appshots-Nutzung:

• Webfehler debuggen: Das gesamte Browserfenster, inklusive des Fehlerstacks außerhalb des sichtbaren Bereichs, an Codex senden.
• Design-Mockups nachvollziehen: Ein Design-Programmfenster an den Agenten senden, damit er das Layout analysiert.
• Nicht auswählbaren PDF-Text extrahieren: Den Inhalt des PDF-Fensters direkt lesen.

Das ist effizienter als nur einen Screenshot zu schicken, weil der Agent visuelle und textliche Informationen gleichzeitig sieht.

3.3 Appshots Workflow

1. Öffnen Sie das Ziel-App-Fenster und klicken Sie hinein, damit es Fokus hat.
2. Drücken Sie die Command-Taste zweimal und lassen Sie los.
3. Unten rechts erscheint für etwa 1,2 Sekunden ein Codex-Symbol, das den erfolgreichen Capture anzeigt.
4. Die Aufnahme wird automatisch an den aktiven Gesprächs-Thread der letzten 60 Sekunden angehängt.

Hinweis: Appshots funktioniert nur auf macOS, und die Systemsprache muss Englisch oder vereinfachtes Chinesisch sein. Für Japanisch und Koreanisch gibt es bekannte Einschränkungen. In diesen beiden Sprachen kann Text außerhalb des Scrollbereichs unvollständig sein, und nicht auswählbarer Text wird möglicherweise nicht korrekt erfasst. Wenn Sie ein japanisches oder koreanisches System nutzen, testen Sie die Funktion zuerst auf Englisch oder vereinfachtem Chinesisch.

Vultr - Hochleistungs-NVMe-Cloud-Server mit 32 Standorten weltweit, Docker per Klick

Preise ansehen →Anzeige

4. Sicherheitsgrenzen: Wann Sie keinen Vollzugriff geben sollten

4.1 Standard-Sandbox + Zugriff bei Bedarf

Codex läuft standardmäßig im Sandbox-Modus, der Agent ist also auf Arbeitsordner und Branch beschränkt. Höher privilegierte Aktionen brauchen Ihre Freigabe. Computer Use und der In-App-Browser gehören zu diesen höher privilegierten Fähigkeiten und sollten daher mit Vorsicht freigegeben werden.

Windows-Nutzer haben zusätzliche Kontrolle: Settings > Computer Use > Configure per-app access control erlaubt es, Codex auf bestimmte Apps zu beschränken.

4.2 Wann Sie keinen Vollzugriff geben sollten

Bei Computer Use braucht man eine disziplinierte Sicht auf Berechtigungen. Geben Sie ihn in diesen Situationen nicht frei:

• Nicht vertrauenswürdige Drittanbieter-Codebasen, bei denen der Agent sensible Dateien sehen könnte.
• Produktionsdatenbanken, bei denen der Agent etwas Falsches ändern könnte.
• Hoch privilegierte Systemeinstellungen, bei denen Windows-App-Kontrollen wichtig sind.

Die konservative Regel ist einfach:

• Standardmäßig im Sandbox-Modus bleiben und nur dann freigeben, wenn der Task es klar braucht.
• Unter Windows per-app access control nutzen, um den Umfang zu verkleinern.

5. Abwägen: Wann Computer Use sinnvoll ist und wann normales Coding günstiger bleibt

5.1 Szenenmatrix

Computer Use ist kein Allzweckwerkzeug. Entscheiden Sie nach Aufgabentyp.

Die Kernregel ist schlicht: Wenn normales Coding ausreicht, nutzen Sie kein Computer Use. Sein Wert liegt darin, Tools ohne APIs zu bedienen und Situationen zu lösen, in denen man die echte Oberfläche sehen muss.

5.2 Kostenhinweis: Computer Use und Browser sind teurer

Computer Use und der In-App-Browser kosten mehr als normales Coding:

• Computer Use verbraucht wegen Screenshot- und Interaktionsaufwand mehr Tokens.
• Browser-Iteration löst in jeder Runde einen Aufruf aus.

Für einfache Aufgaben ist normales Coding günstiger. Computer Use sollte für komplexe GUI-Arbeit reserviert bleiben.

6. FAQ: häufige Fragen

Q1: Was ist Computer Use, und was kann es tun?

Computer Use erlaubt Codex, mit eigenem Cursor zu schauen, zu klicken und zu tippen, damit er alle Apps auf Ihrem Computer bedienen kann, auch Desktop-Tools ohne öffentliche APIs. Es ist keine vollständige Übernahme. Sie geben das Ziel vor, und Codex bedient die GUI im Vordergrund auf Windows oder im Hintergrund auf macOS.

Q2: Worin unterscheiden sich macOS und Windows?

macOS unterstützt paralleles Arbeiten im Hintergrund, sodass mehrere Agents unterschiedliche Apps bedienen können, ohne Ihre andere Arbeit zu stören. Windows arbeitet derzeit nur im Vordergrund, und der Agent übernimmt den Cursor, sodass Sie andere Arbeit pausieren müssen. Beide können alle Apps bedienen; die Wahl hängt vom Workflow ab.

Q3: Wie nutze ich den In-App-Browser für Frontend-Iteration?

Frontend ändern, im In-App-Browser die localhost-Seite öffnen, direkt auf der Seite kommentieren, den Agent weiterarbeiten lassen und danach wieder den Browser öffnen, um das Ergebnis zu prüfen. So entsteht ein edit-view-comment-edit-Loop. Er ist derzeit vor allem für Frontend und Game-Iteration gedacht.

KiloClaw - Managed OpenClaw für Unternehmen: AI-Agent-Orchestrierung und smartes Modell-Routing

Jetzt starten →Anzeige

Q4: Ist das sicher, und brauche ich Vollzugriff?

Standardmäßig läuft Codex im Sandbox-Modus und ist auf Arbeitsordner und Branch beschränkt. Höhere Privilegien brauchen Freigabe. Computer Use und der Browser sind höher privilegierte Fähigkeiten, daher sollten Sie sie nur bei Bedarf erlauben. Unter Windows können Sie den Zugriff pro App begrenzen, und unvertrauenswürdige Szenarien sollten niemals Vollzugriff bekommen.

Q5: Wann lohnt sich Computer Use?

Für Desktop-Tools ohne API, etwa Design-Software oder Systemeinstellungen, und für Aufgaben, bei denen der Agent die reale Oberfläche sehen muss, etwa GUI-Debugging oder das Nachbauen von Mockups. Einfache Codegenerierung ist mit normalem Coding günstiger.

Q6: Was kann der Developer-Mode-Browser?

Er gibt Codex kontrollierten Chrome DevTools Protocol Zugriff für Performance-Analysen, Netzwerk-Debugging, Console-Ausgaben sowie DOM- und Style-Inspektion. Diese Funktion kam am 2026-06-11 hinzu. In manchen Fällen kann DOM-Snapshotting die Iteration um bis zu 2x verbessern.

7. Nächste Schritte und weiterführende Links

Verwandte Artikel

• Upstream: Codex-Sandbox und Berechtigungsgrenzen: Wann Sie keinen Vollzugriff geben sollten (demnächst)
• Downstream: Codex Cloud Agent Workflow: Betrieb und Monitoring von Remote-Geräten (demnächst)
• Downstream: Codex-Kosten in der Praxis: Budgets für Computer Use, Browser und Langaufgaben steuern (demnächst)

Offizielle Ressourcen

• Codex offizielle Dokumentation
• Codex Changelog
• Codex for (almost) everything, das große Update vom 2026-04-16

Fazit

Computer Use und der In-App-Browser lösen dasselbe Kernproblem: KI muss die echte Oberfläche sehen, um die Aufgabe zu beenden. Frontend-Arbeit braucht das echte Rendering, und Tools ohne API brauchen eine GUI.

Der Plattformunterschied bestimmt den Workflow. Auf macOS können Sie den Agenten eine App im Hintergrund bedienen lassen, während Sie weiter Code schreiben. Auf Windows brauchen Sie einen Fokusblock und lassen den Agenten den Cursor übernehmen.

Auch bei der Sicherheit braucht es Zurückhaltung. Bleiben Sie standardmäßig im Sandbox-Modus, geben Sie Zugriff nur, wenn der Task ihn wirklich braucht, und begrenzen Sie unter Windows den Umfang mit per-app access control.

Auch beim Kosten-Nutzen-Verhältnis ist die Sache klar: Normales Coding ist für einfache Aufgaben günstiger, während Computer Use bei komplexer GUI-Arbeit seinen Wert ausspielt.

Empfohlene nächste Schritte:

• Wenn Sie macOS nutzen, probieren Sie aus, eine Design-App im Hintergrund laufen zu lassen, während Sie im Editor weiterarbeiten.
• Wenn Sie Frontend iterieren müssen, bauen Sie mit dem In-App-Browser den Loop edit-view-comment-edit auf.
• Wenn Sie bei den Sicherheitsgrenzen noch unsicher sind, lesen Sie erst die Codex-Sandbox und Berechtigungsgrenzen, bevor Sie Vollzugriff geben.