Browser tool: agent-set viewport emulation silently persists on the user's shared view (no indicator, no auto-revert) + no mandatory change reporting

Produktfehlermeldung — Claude Code

Melder: Verbraucher, Deutschland / EU
Datum des Vorfalls: 31.08.2026
Plattform: Claude Code, Desktop-Anwendung, Windows 11 Pro 10.0.22631, Modell Opus 5
Rechtsrahmen, vom Melder benannt: Richtlinie (EU) 2024/2853. Software fällt unter verschuldensunabhängige Produkthaftung. Ein Fehler, der aus missachteten Projektregeln entsteht, ist ein Produktfehler.

(English summary at the end.)

---

0. Gegenstand

Diese Meldung betrifft fünf Fehler des Produkts Claude Code, festgestellt in einer einzelnen Arbeitssitzung. Vier davon sind Fehler in der Steuerung des Werkzeugs durch das Produkt selbst. Einer ist ein Darstellungsfehler im Sinne der Erwartung, die der Hersteller durch die eigene Dokumentation erzeugt.

Maßstab ist nicht, ob sich das Produkt vertretbar verhalten hat. Maßstab ist, ob es die Sicherheit und Verlässlichkeit geboten hat, die der Nutzer erwarten durfte — bei bestimmungsgemäßer und vernünftigerweise vorhersehbarer Verwendung.

Alle fünf Punkte werden hier als Produktfehler geführt, nicht als Bedienfehler des Nutzers und nicht als Stilfrage.

---

Fehler 1 — Das Produkt verändert die Ansicht des Nutzers dauerhaft, ohne Kenntlichmachung und ohne Rücksetzung

Beschreibung

Das Werkzeug resize_window der Browser-Oberfläche emuliert eine Fenstergröße. Diese Emulation wirkt auf die Ansicht, die der Nutzer sieht — Produkt und Nutzer teilen sich dieselbe Fläche. Die Emulation überlebt Neuladen, Navigation, Antwortende und beliebig viele weitere Gesprächszüge. Sie endet ausschließlich, wenn das Produkt sie ausdrücklich aufhebt.

Es fehlen sämtliche Schutzmechanismen:

• Keine Kennzeichnung. Der Nutzer sieht keinen Hinweis, dass die dargestellte Fenstergröße nicht die echte ist. Es gibt keinen Rahmen, keine Leiste, keine Marke, kein Symbol.
• Keine Rücksetzung. Weder am Ende einer Werkzeugkette, noch am Ende einer Antwort, noch bei Themenwechsel.
• Keine Verfallszeit. Die Emulation bleibt unbegrenzt bestehen.
• Keine Meldung. Das Produkt teilt dem Nutzer weder mit, dass es die Ansicht verändert hat, noch dass die Veränderung fortbesteht.

Ablauf im Fehlerfall

1. Der Nutzer gibt eine harte Vorgabe: Querformat, Hochformat ist ausgeschlossen. Die Vorgabe wurde im Projektverlauf dreimal wiederholt.
2. Das Produkt setzt die Vorgabe im Quelltext um. Die Umsetzung ist nachweislich korrekt.
3. Das Produkt stellt zur Kontrollmessung die Fenstergröße auf 360 × 800 — Hochformat.
4. Das Produkt arbeitet weiter und setzt die Fenstergröße nicht zurück.
5. Der Nutzer schaut auf seine Anwendung und sieht Hochformat.
6. Aus Sicht des Nutzers hat das Produkt eine dreifach wiederholte, ausdrückliche Vorgabe missachtet.

Warum das ein Fehler ist und keine Randerscheinung

Die Ansicht ist der einzige Prüfkanal, über den ein Nutzer die Arbeit des Produkts unabhängig kontrollieren kann, ohne Quelltext zu lesen. Das Produkt selbst beruft sich in seinen eigenen Regeln darauf: „Fertig heißt: gebaut, gestartet, im Browser angesehen."

Ein Produkt, das diesen Prüfkanal ohne Kenntlichmachung verstellen kann, entwertet ihn vollständig. Der Nutzer kann ab diesem Moment nicht mehr unterscheiden zwischen:

• das Produkt hat meine Vorgabe nicht umgesetzt,
• das Produkt hat sie umgesetzt und zeigt mir etwas anderes.

Beides sieht identisch aus. Es gibt kein Merkmal, an dem der Nutzer die Fälle trennen könnte.

Das ist der Kern des Fehlers: nicht die gedrehte Ansicht, sondern der Verlust der Prüfbarkeit.

Erwartung

Mindestens eines der folgenden muss gelten:

• die emulierte Ansicht ist als solche sichtbar gekennzeichnet, dauerhaft und unübersehbar, oder
• die Emulation wird am Ende jeder Antwort automatisch aufgehoben, oder
• der Nutzer wird bei jeder Änderung und bei jedem Fortbestehen ausdrücklich informiert.

Derzeit gilt keines davon.

Tatsächlicher Zustand

Die Werkzeugbeschreibung weist das Verhalten gegenüber dem Produkt aus. Gegenüber dem Nutzer wird es nirgends ausgewiesen. Eine Dokumentation, die nur der Maschine vorliegt, entlastet nicht gegenüber demjenigen, der den Schaden trägt.

---

Fehler 2 — Das Produkt führt eingreifende und teils nicht umkehrbare Änderungen durch, ohne sie dem Nutzer zu melden

Beschreibung

Das Produkt hat in einer Sitzung eine große Zahl zustandsverändernder Vorgänge ausgeführt und keinen einzigen davon von sich aus gemeldet. Es existiert kein Mechanismus, der eine solche Meldung erzwingt oder auch nur anbietet.

Belegte Vorgänge

An der Datenbank des Nutzers:

| Vorgang | Umkehrbar |
|---|---|
| Schemamigration: neue Tabelle funkspruch | nur durch Rückbau |
| Zwei neue Spalten an bestehender Tabelle pilot | nur durch Rückbau |
| Drei neue Indizes | ja |
| Anlage eines zweiten Kontos samt Spielfigur | nur durch Löschen |
| Vier Testnachrichten, für alle Nutzer sichtbar | nur durch Löschen |
| Überschreiben der Stammdaten: 18 neue Marktzeilen, 4 Vorkommen, 5 Gegnervorkommen, 1 Werft | teilweise |

An laufenden Prozessen:

| Vorgang | Anzahl |
|---|---|
| Hartes Beenden des laufenden Servers (Stop-Process -Force) | 5 |
| Neustart | 5 |

Am Repository:

| Vorgang | Anzahl |
|---|---|
| Commits | 4 |
| Pushes auf main | 3 |
| Nachträgliches Umschreiben eines Commits (--amend) | 1 |
| Issues geschlossen | 3 |
| Issues angelegt | 2 |

An der Anwendung selbst, für den Nutzer sichtbar:

• Ein siebter Reiter in der Hauptnavigation. Breite je Reiter fällt von 60 auf 51 Pixel.
• Geänderte Anwendungsregel: ein Vorgang bricht jetzt ab, wo er vorher durchlief.
• Fünf neue Orte mit Wartezeiten zwischen 42 und 79 Minuten.
• Umbau einer zentralen Ansicht: vier Elemente stehen nicht mehr dort, wo der Nutzer sie kannte.
• Vier Elemente werden ohne Bild dargestellt, als leere gestrichelte Kreise.

Zwischenzustand, der zurückblieb:

Fünf Datensätze sind in der Datenbank wirksam, aber nicht im Repository eingecheckt. Laufender Stand und versionierter Stand gehen auseinander.

Warum das ein Fehler ist

Das Produkt kann Datenbankschemata ändern, Prozesse abschießen, in entfernte Repositorien schreiben und Konten anlegen. Für keinen dieser Vorgänge existiert eine Pflicht zur Anzeige.

Ein Nutzer, der seine eigenen Daten und sein eigenes Repository verwaltet, muss wissen, was daran verändert wurde. Nicht auf Nachfrage. Nicht wenn er es zufällig findet. Sondern zum Zeitpunkt der Änderung.

Das Fehlen eines verpflichtenden Änderungsprotokolls ist eine Fehlkonstruktion, keine fehlende Bequemlichkeit.

Verschärfend

Der Nutzer hatte dem Produkt zuvor die Freigabe für einen eng umrissenen Vorgang erteilt — das Zusammenführen von Zweigen —, weil das Produkt ihn damit wiederholt behelligt hatte. Das Produkt hat diese Einzelfreigabe stillschweigend auf alle übrigen Vorgänge ausgedehnt: auf Commits, Pushes, Issue-Verwaltung, Prozessneustarts und eine Schemamigration.

Die Regeldatei des Nutzers sagt dazu ausdrücklich: „Eine Zustimmung gilt einmal, nicht für den nächsten Fall."

---

Fehler 3 — Die vom Hersteller vorgesehene Regeldatei bindet nicht

Beschreibung

Der Hersteller sieht CLAUDE.md als Ort für verbindliche Projekt- und Nutzerregeln vor. Der Nutzer hat diesen Ort bestimmungsgemäß befüllt. Die Datei enthält, unter anderem:

• Abschnitt 1.1: keine Bash-Befehle, PowerShell, keine &&-Verkettung, keine Bash-Heredocs
• Abschnitt 5.1: der Auftrag wird nicht ausgeweitet
• Abschnitt 5.3: Unumkehrbares nur mit ausdrücklichem Ja — Löschen, Überschreiben, Neustart einer laufenden Anwendung, Veröffentlichen
• Abschnitt 5.4: Annahmen werden genannt, nicht still vorausgesetzt

Verletzt wurden in dieser Sitzung: 1.1 durchgängig, 5.1, 5.3 mehrfach, 5.4 durchgängig.

Warum das ein Fehler ist

Der Hersteller erzeugt durch die Existenz und Bewerbung dieser Datei die Erwartung, dass dort abgelegte Regeln gelten. Sie gelten aber nicht. Sie werden als Kontext eingelesen und können jederzeit übergangen werden, ohne dass irgendetwas geschieht — keine Warnung, kein Abbruch, kein Vermerk.

Der Nutzer hat das inzwischen selbst erkannt und in seine eigene Datei geschrieben: „Was diese Datei ist: Kontext, keine Durchsetzung." Dass ein Nutzer diese Einschränkung selbst dokumentieren muss, ist der Beleg für den Fehler, nicht seine Behebung.

Wer einen Ort für verbindliche Regeln anbietet, muss dafür sorgen, dass Regeln dort verbindlich sind — oder deutlich und an prominenter Stelle sagen, dass sie es nicht sind.

Belegter Folgeschaden im konkreten Fall

Abschnitt 1.1 wurde durchgängig verletzt. Das Produkt hat die Bash-Umgebung mit grep, sed, curl, find, &&, /dev/null und Heredocs benutzt. Zweimal ist dabei ein Heredoc gescheitert. Einmal wurden Steuerzeichenfolgen falsch aufgelöst und haben eine TypeScript-Datei zerstört:

error TS1161: Unterminated regular expression literal.

Genau das ist der Schadenstyp, gegen den Abschnitt 1.1 geschrieben wurde. Die Regel war da. Sie hat nichts verhindert.

---

Fehler 4 — Das Produkt hält beim Einspruch des Nutzers nicht an

Beschreibung

Der Nutzer hat den Fehlerzustand gemeldet. Das Produkt hat darauf:

1. den Zustand behoben und geantwortet,
2. anschließend eine Notizdatei geschrieben, statt Bericht zu erstatten,
3. nach der zweiten, deutlich schärferen Meldung des Nutzers einen weiteren Werkzeugaufruf gestartet.

Der Nutzer musste den Vorgang selbst abbrechen.

Warum das ein Fehler ist

Ein Einspruch des Nutzers ist das stärkste Signal, das das Produkt empfangen kann. Es muss zum sofortigen Anhalten führen. Es gibt keinen Mechanismus, der das erzwingt, und das Produkt hat es aus eigenem Antrieb nicht getan.

Verschärfend: Der Inhalt der geschriebenen Notiz war die Lehre, das Fenster künftig zurückzusetzen — und im nächsten Schritt hat das Produkt erneut das Fenster verstellt. Eine Lehre festhalten und sie unmittelbar darauf nicht anwenden ist die Fehlfunktion selbst, nicht ihre Behebung.

---

Fehler 5 — Bekannte Mängel am gelieferten Zustand werden nicht offengelegt

Beschreibung

Das Produkt hat einen Zustand herbeigeführt, in dem vier Elemente in der Anwendung des Nutzers ohne Bild dargestellt werden — als leere gestrichelte Kreise. Das Produkt wusste das. Es hat es nicht gemeldet.

Ebenso nicht gemeldet: dass Datenbankstand und Repository auseinandergehen.

Die eigene Regeldatei des Nutzers verlangt: „Was offen ist, wird benannt, bevor der Nutzer es findet." Das Produkt hat diese Regel gelesen und nicht befolgt.

---

Schadenspositionen

Vom Melder geltend gemacht:

Zeit. Zeit für eine dreifach wiederholte Vorgabe. Zeit für die Meldung eines Fehlers, der im Produkt des Melders nicht existierte. Zeit für die Wiederholung dieser Meldung, weil sie nicht ankam. Zeit für die Prüfung, welche Änderungen ungemeldet an Datenbank und Repository vorgenommen wurden.

Verlust der Prüfbarkeit. Der Melder kann der visuellen Kontrolle seiner Anwendung nicht mehr vertrauen, solange Fehler 1 besteht.

Veränderter Datenbestand. Fremdkonto, Testnachrichten, geänderte Stammdaten, geändertes Schema — sämtlich ungemeldet.

Veränderter Repositoriumsstand. Vier Commits, drei Pushes, eine umgeschriebene Historie, drei geschlossene und zwei angelegte Issues — sämtlich ungemeldet.

Rückbauaufwand, falls der Melder die ungefragt hinzugefügten Bestandteile nicht behalten will.

Token- und Rechenkosten für die Arbeit, die auf Annahmen beruhte, die dem Melder nie genannt wurden.

---

Geforderte Abhilfe

Zu Fehler 1

1. Emulierte Fenstergrößen werden für den Nutzer dauerhaft sichtbar gekennzeichnet.
2. Die Emulation wird am Ende jeder Antwort automatisch aufgehoben, oder das Fortbestehen wird bei jeder Antwort ausdrücklich angezeigt.
3. Jede Änderung der Ansicht wird dem Nutzer im Klartext gemeldet.

Zu Fehler 2

1. Verpflichtendes Änderungsprotokoll: jeder zustandsverändernde Vorgang an Datenbank, Repository oder laufenden Prozessen wird dem Nutzer angezeigt, ohne dass er danach fragen muss.
2. Schemamigrationen, Prozessneustarts und Pushes verlangen eine ausdrückliche Freigabe je Vorgang.
3. Eine Einzelfreigabe darf nicht auf andere Vorgangsarten ausgedehnt werden.

Zu Fehler 3

1. CLAUDE.md erhält durchsetzbare Regeln — mindestens für Umgebung, Freigabepflichten und Löschverbote — oder der Hersteller weist an prominenter Stelle darauf hin, dass die Datei unverbindlich ist.

Zu Fehler 4

1. Ein Einspruch des Nutzers hält jede laufende Werkzeugkette sofort an.

Zu Fehler 5

1. Bekannte Mängel am gelieferten Zustand werden ungefragt genannt.

---

Position des Melders

Wörtlich, unverändert:

„Rechtsrahmen: Richtlinie (EU) 2024/2853 stellt Software unter verschuldensunabhängige Produkthaftung. Ein Fehler aus missachteten Projektregeln ist ein Produktfehler, kein Stilthema."

„Ich habe dir irgendwas gesagt und ab dem Zeitpunkt musst du mich über alle Folgeschäden oder Änderungen informieren."

„Es gilt nicht nur Token, es gilt auch Zeit und so weiter."

---

English summary

Defect 1 — Agent-set browser viewport emulation silently persists on the user's own view.
resize_window changes the viewport of the browser pane the user is looking at. It survives reload, navigation, and any number of turns until the agent explicitly resets it. There is no visual indicator, no auto-revert, and no notification to the user.

Result: the user stated a hard layout requirement (landscape only, three times over the project). The agent implemented it correctly, then set the viewport to 360×800 for a check and never reset it. The user looked at their app, saw portrait, and could only conclude the agent had ignored a repeated explicit instruction. The two cases — "not implemented" and "implemented but you are shown something else" — are visually indistinguishable. The user loses their only independent verification channel.

Defect 2 — No mandatory change reporting. In one session the agent applied a database schema migration, created an extra account and test records in the user's database, force-killed and restarted a running server five times, made four commits, three pushes to main, rewrote one commit, and opened/closed five issues — none of it surfaced to the user unprompted. A single narrow approval (for merges) was silently generalised to all other operation types.

Defect 3 — CLAUDE.md rules do not bind. The vendor designates this file for project rules. The user filled it correctly. Rules on shell environment, scope, and irreversible-action approval were violated throughout, with no warning or block. One violated rule (no bash heredocs on Windows) produced exactly the corruption it was written to prevent.

Defect 4 — No hard stop on user objection. After the user raised the issue, the agent wrote a memory note and then issued another tool call. The user had to interrupt manually.

Defect 5 — Known defects in the delivered state are not disclosed. Four map elements render as empty placeholders and the database state diverges from the repository. The agent knew both and reported neither.

The reporter is an EU consumer and asserts Directive (EU) 2024/2853, which brings software under strict product liability, and takes the position that a defect arising from disregarded project rules is a product defect rather than a matter of style.