„Welches Fenster meinst du?" — bts holt das richtige Browserfenster per CLI nach vorn

„Drei Browser offen, ein Dutzend Fenster – und im Vordergrund natürlich das falsche.” Wer mit KI-Agenten arbeitet, kennt den Moment: Du bittest den Agenten um einen Screenshot oder eine Playwright-Aufnahme, und als Erstes muss er wissen, welches Browserfenster überhaupt gemeint ist. Also liest du den Fenstertitel vom Bildschirm ab und tippst ihn in den Chat. Bei mehreren Chrome-Profilen und einem Stapel offener Fenster ist das langsam, fehleranfällig – und jede Rate-Runde kostet Tokens und Kontext.

bts (Browser Target Selector) löst genau diesen einen Schritt: Es inventarisiert, was gerade läuft – über Chrome, Edge und Firefox hinweg – und bietet eine stabile, nummerierte Auswahl. Oder du beschreibst einfach, was du suchst.

Nebenbei: bts ist CLI und MCP-Server zugleich. Über den mitgelieferten bts-mcp.exe teilen Claude Code, GitHub Copilot, Cursor oder Windsurf denselben Browser-Kontext. Dazu am Ende kurz — der rote Faden hier ist das CLI, das du auch in den Videos live siehst.

Das Problem: „welches Fenster meinst du?”

Der teure Teil ist nicht das Fokussieren selbst, sondern die Übergabe. Ein Agent sieht deinen Bildschirm nicht wie du. Damit er das richtige Fenster erwischt, läuft heute meist dieses Spiel:

Du liest einen Fenstertitel ab und tippst ihn ab (mit Tippfehlern).
Der Agent rät bei mehreren gleichnamigen Fenstern daneben.
Du korrigierst, er versucht es erneut – und jede Runde wandert als Text durch den Kontext.

Bei zwei, drei Profilen und einem Dutzend Fenster wird aus „mach mal einen Screenshot” ein Dialog. Das ist genau die Sorte Reibung, die man bei Agenten-Workflows nicht will.

Was hier eigentlich zu groß ist

Es gibt starke Werkzeuge, die einem Agenten vollen Zugriff auf Browser-Tabs geben: Extensions, die Seiteninhalt lesen, klicken, tippen, ganze Web-Apps über deine eingeloggte Session bedienen — manche bringen über die Plugins tausende Tools mit. Für „bediene Slack/Jira/GitHub für mich” sind die großartig und einem schlanken Selektor haushoch überlegen.

Für die schlichte Frage „welches Fenster nach vorn?” sind sie aber überdimensioniert:

Sie setzen eine Extension voraus, die in deinen Seiten mitläuft.
Sie ziehen Seiteninhalt (und damit Kontext und Tokens) in den Agenten, den man fürs bloße Auswählen nicht braucht.
Sie geben Rechte – Lesen, Klicken, API-Zugriff auf die eingeloggte App –, die für „hol das Fenster nach vorn” viel zu weit reichen.

Die naheliegende, aber falsche Lösung

Das schwere Automation-Framework anwerfen, die Browser-Extension installieren, den DOM in den Kontext holen — nur um ein Fenster zu fokussieren. Das funktioniert, ist aber mehr Setup, mehr Rechte, mehr Tokens und mehr Angriffsfläche, als die Aufgabe verlangt. Und es ändert oft etwas an deinem Alltags-Browser (Debug-Port, Neustart, Flags), was du für einen Screenshot nicht wolltest.

Die belastbare Lösung: auswählen statt steuern

bts macht bewusst nur dreierlei — auflisten, per Nummer anspringen, per Beschreibung finden — und übergibt dann an Playwright, dein Screenshot-Tool oder den Agenten. Kein Seitenzugriff, keine Extension, und es fasst keinen Browser an, den es nicht selbst gestartet hat.

Installieren (einmalig)

Voraussetzung: Windows 11 und das .NET SDK 8. Der Setup baut bts.exe und bts-mcp.exe nach %LOCALAPPDATA%\BrowserTargetSelector\bin und ergänzt den PATH.

git clone https://github.com/brunsforge/browser-target-selector
cd browser-target-selector
.\setup.ps1 -Hosts both -AddToPath
# neues Terminal öffnen (damit der PATH greift), dann:
bts doctor

bts doctor zeigt pro Browser/Profil, was erkannt wurde und welche Capability möglich ist (nur Fenster, oder auch Tabs). Ehrlich statt geraten: kann bts Hintergrund-Tabs nicht sehen, sagt es das, statt welche zu erfinden.

Auflisten und per Nummer anspringen

bts inventory        # nummerierte Übersicht aller Fenster (Chrome/Edge/Firefox, Profile getrennt)
bts activate 2       # Fenster 2 in den Vordergrund

Du wählst immer über eine Nummer — nie über abgetippte Titel, Profile oder technische IDs. Genau das macht die Übergabe an einen Agenten robust.

bts inventory: eine nummerierte Liste aller Fenster über Chrome, Edge und Firefox — je Zeile Browser · Profil · aktiver Titel, dazu der stabile Snapshot für die Auswahl.

Per Beschreibung finden (semantisch)

Wenn du die Nummer nicht kennst, beschreibst du einfach den Kontext:

bts find "die mozilla doku" --activate

Eindeutiger Treffer für "die mozilla doku":

  Mozilla Firefox — MDN Web Docs
  https://developer.mozilla.org/de/

Aktiviert: Mozilla Firefox
Fenster in den Vordergrund geholt.

Ist der Treffer eindeutig, springt bts direkt an. Sind mehrere plausibel, bekommst du wieder eine nummerierte Liste statt einer geratenen Antwort. Die gesamte Ausgabe gibt es auf Deutsch mit --lang de.

Strukturiert für Automation

Für Agenten und Skripte liefert --json ein neutrales Protokoll — dieselbe Logik, maschinenlesbar:

bts inventory --json      # Snapshot mit snapshotId + browsers[].windows[]

Der snapshotId macht die Auswahl stabil: Ein Agent inventarisiert einmal, wählt eine Nummer gegen genau diesen Snapshot auf und aktiviert das Ziel — ohne Race Conditions. URLs sind dabei standardmäßig redigiert, private/Inkognito-Fenster bleiben außen vor, solange du sie nicht ausdrücklich anforderst.

Für eine Übergabe schreibt bts export einen portablen, redigierten Snapshot in eine Datei — den ein zweiter Agent oder Rechner ohne Live-Zugriff weiterverarbeitet.

Voller Tab-Zugriff — nur wenn du ihn willst

Braucht ein Ablauf echten Tab-Zugriff (etwa für eine Aufnahme), startet bts launch eine separate Instanz mit eigenem Profil und Debug-Port. Dein Alltags-Browser wird nie neu gestartet, nie umkonfiguriert und bekommt keinen Debug-Port hinter deinem Rücken.

bts launch --url https://example.org   # eigene Instanz mit voller Tab-Sicht, getrennt von deinem Profil

Wann bts – und wann etwas Mächtigeres (Checkliste)

Nur das richtige Fenster/Tab nach vorn holen (für Screenshot, Playwright, visuelle Prüfung)? → bts, schlank und token-sparsam.
Im Web-App agieren – klicken, tippen, Inhalte lesen, APIs der eingeloggten App nutzen? → Ein Content-Tool wie OpenTabs; das kann bts bewusst nicht.
Terminal-Tab-Management auf macOS/Linux? → bts ist Windows-only; dafür passt eher tabb.
Kontext/Tokens sparen und keine Extension wollen? → bts, denn es liest keinen Seiteninhalt.

Die Werkzeuge schließen sich nicht aus: bts pickt und fokussiert das Ziel, ein Content-Tool übernimmt danach. Auswahl und Steuerung sind zwei Jobs.

Grenzen und die unbequemen Teile

Windows 11 only, .NET 8 vorausgesetzt. Kein macOS/Linux.
Kein Seiteninhalt – by design. bts liest nichts aus deinen Seiten, klickt nicht, scrapt nicht. Wer das braucht, ist hier falsch.
Hintergrund-Tabs sieht bts nur, wo die Capability es hergibt; sonst bleibt es beim aktiven Tab und sagt das offen (statt Tabs zu erfinden).
Voller Tab-Zugriff nur über eine per bts launch gestartete, getrennte Instanz — nicht in deinem persönlichen Profil.
Es ist ein junges Werkzeug (Windows 11, CDP- und BiDi-Pfad gegen echte Browser geprüft, breite Testabdeckung) — aber eben fokussiert auf einen Job, nicht auf alle.

Der MCP-Server (kurz)

Dieselbe Logik gibt es host-neutral über bts-mcp.exe (JSON-RPC über stdio) als Tools: browser_find, browser_inventory, browser_select, browser_activate, browser_launch, browser_groups, browser_dedupe, browser_export. In Claude Code registrierst du ihn einmal — danach kannst du schlicht sagen: „Bring das Fenster mit der MDN-Doku nach vorn.” Die ganze Erkennungslogik bleibt im CLI; Skill, Agent und MCP sind nur dünne Adapter darauf.

Kurz: bts ist das Skalpell für „welches Fenster meinst du?” — nicht das Schweizer Taschenmesser für alles im Browser. Genau diese Selbstbeschränkung macht es bei Agenten-Workflows schnell, sparsam und vorhersehbar: es wählt aus und holt nach vorn, den Rest übergibt es.

Stand: Juli 2026. Quelle und Installationsdetails: github.com/brunsforge/browser-target-selector. Windows-11-Fokus, laufend erweitert — im Zweifel die README prüfen.