Erinnert ihr euch noch daran, als unsere geliebten Agenten überhaupt nichts mitgebracht haben?

Mit Codex ist die Lage immer noch unklarer als bei Claude Code: Codex bringt ein Web-Search-Tool mit, das vor einigen Wochen eingeführt wurde. Laut Dokumentation kann es komplette Seiten abrufen (wenn man ein Reasoning-Modell verwendet, was beim Codex-CLI der Fall ist) – allerdings wird in den öffentlichen Docs nicht klar, ob dabei clientseitiges JavaScript ausgeführt wird, um ein DOM nach der JS-Ausführung zu erzeugen. Vielleicht tut es das, vielleicht auch nicht. Ehrlich gesagt weiß ich es nicht. Aber: Dieser Unterschied ist entscheidend bei SPAs, bei denen Inhalte erst nach der Hydration erscheinen.

Rendering, JavaScript und SPAs

Claude Code geht hier deutlich sauberer vor und trennt klar zwischen WebSearch (Quellen finden) und WebFetch (eine konkrete Seite abrufen). Dabei wird kein beliebiges Site-JavaScript ausgeführt – weshalb stark JS-lastige SPAs weiterhin nur dünne Ergebnisse liefern, sofern ihr keinen echten Browser verwendet.

«The web fetch tool currently does not support web sites dynamically rendered via Javascript.» (Anthropic-Dokumentation zum „web fetch tool“, 24. Oktober 2025)

Browser-basiertes Fetching als pragmatische Lösung

Genau wegen dieser Lücke hilft ein kleiner lokaler Fallback: einmal mit einem Headless-Browser rendern und dem Modell anschließend normalisierten Text übergeben. Ein winziges Wrapper-Skript kann dabei den ganzen Pfad-Lärm (und den Token-Overhead) aus eurem Kontext heraushalten:

# ~/bin/chrome
#!/usr/bin/env bash
exec "/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" "$@"

Damit lassen sich die meisten Anforderungen abdecken:

# 1) Fully rendered DOM (post-JS) as HTML
chrome --headless --disable-gpu --dump-dom "https://example.com"
# 2) Rendered DOM → Markdown (model-friendly)
chrome --headless --dump-dom "https://example.com" | uvx markitdown
# 3) Rendered DOM with stripped tags (token-budgeted)
chrome --headless --dump-dom "https://example.com" | uvx strip-tags

Dieses Pattern delegiert Netzwerkzugriffe, JavaScript-Ausführung und DOM-Konstruktion einmalig an die Browser-Engine und gibt dem Agenten anschließend ein stabiles Artefakt für seinen Kontext. Behaltet das eingebaute Search-Tool für Discovery-Zwecke bei, nutzt aber einen echten Browser, um Seiteninhalte abzurufen.

Um das für Agenten konkret nutzbar zu machen, hier ein Auszug aus meiner aktuellen AGENTS.md (ich verwende sie mit Codex). Sollte genauso mit CLAUDE.md funktionieren, ich habe es allerdings noch nicht ausprobiert. Wahrscheinlich braucht es dort nur etwas mehr Nachdruck.

## Agent’s toolbox (complementary to MCP server tools)
- When the user wants you to read websites, fetch their content using 
  `chrome --headless --dump-dom | uvx markitdown` 
  (if `chrome` is available). 
  The call will return the website’s content converted to markdown. 
  If markdown is not practicable, leave out the piping. 
  As a generic fallback use curl or wget. 
  Don’t use the search tool for fetching!

Bestehende Werkzeuge sinnvoll nutzen

Die besten Tools, die ein Agent nutzen kann, sind oft bereits auf eurem System vorhanden. In vielen Fällen braucht ihr überhaupt keinen MCP-Server: Ihr spart Konfigurationsaufwand und Token-Budget – denn jedes zusätzliche MCP-Tool zieht seine Tool-Beschreibung mit in den Kontext. Modelle wissen in der Regel, wie gängige CLI-Tools zu benutzen sind; falls nicht, können sie sie einfach aufrufen und die Usage-Ausgabe auslesen.

TAGS