cx-viewer 1.0.3 → 1.0.4

package/concepts/de/Teammate.md

@@ -2,25 +2,25 @@
 
 ## Definition
 
-Ein Teammate ist ein kollaborativer Agent im Team-Modus von Claude Code Agent. Wenn der Haupt-Agent ein Team mit `TeamCreate` erstellt und Teammates mit dem `Agent`-Tool erzeugt, lauft jeder Teammate als unabhangiger Agent-Prozess mit eigenem Kontextfenster und Toolset und kommuniziert uber `SendMessage` mit den Teammitgliedern.
+A Teammate is a collaborative agent in Codex Agent Team mode. The main agent discovers the available multi-agent tools through `tool_search`; when those tools are available, each teammate runs as an independent agent process with its own context window and toolset.
 
-## Unterschied zu SubAgent
+## Differences from SubAgent
 
-| Merkmal | Teammate | SubAgent |
+| Feature | Teammate | SubAgent |
 |---------|----------|----------|
-| Lebenszyklus | Bleibt bestehen, kann mehrfach Nachrichten empfangen | Einmalige Aufgabe, wird nach Abschluss zerstort |
-| Kommunikation | SendMessage bidirektionale Nachrichten | Eltern->Kind unidirektionaler Aufruf, Ergebnis zuruckgeben |
-| Kontext | Unabhangiger vollstandiger Kontext, bleibt uber Runden hinweg erhalten | Isolierter Aufgabenkontext |
-| Zusammenarbeit | Teamarbeit, gegenseitige Kommunikation moglich | Hierarchische Struktur, Interaktion nur mit dem ubergeordneten Agent |
-| Aufgabentyp | Komplexe mehrstufige Aufgaben | Einzelaufgaben wie Suche, Erkundung |
+| Lifecycle | Persistent, can receive multiple messages | One-off task, destroyed upon completion |
+| Communication | Team messaging through the available multi-agent toolset | Parent→child unidirectional call, returns result |
+| Context | Independent full context, retained across turns | Isolated task context |
+| Collaboration | Team collaboration, can communicate with each other | Hierarchical structure, only interacts with parent agent |
+| Task Type | Complex multi-step tasks | Single tasks such as search and exploration |
 
-## Verhalten
+## Behavior
 
-- Wird vom Haupt-Agent (Team Lead) uber das `Agent`-Tool erstellt und einem `team_name` zugewiesen
-- Teilt die Aufgabenliste uber `TaskList` / `TaskGet` / `TaskUpdate`
-- Wechselt nach jeder Ausfuhrungsrunde in den Idle-Zustand und wartet auf neue Nachrichten zur Aktivierung
-- Kann uber `shutdown_request` ordnungsgemas beendet werden
+- Created by the main agent (team lead) through available multi-agent tooling and assigned a team identity
+- Shares task state through the available multi-agent task/status tools
+- Enters idle state after each turn, waiting to be woken by a new message
+- Can be gracefully terminated via `shutdown_request`
 
-## Erlauterung zum Statistik-Panel
+## Stats Panel Description
 
-Das Teammate-Statistik-Panel zeigt die Anzahl der API-Aufrufe fur jeden Teammate an. Die Spalte `Name` enthalt den Teammate-Namen (z. B. `reviewer-security`, `reviewer-pipeline`), die Spalte `Anzahl` die Gesamtzahl der API-Anfragen dieses Teammates.
+The Teammate stats panel displays the number of API calls for each teammate. The `Name` column shows the teammate's name (e.g., `reviewer-security`, `reviewer-pipeline`), and the `Count` column shows the total number of API requests generated by that teammate.

package/concepts/de/ToolsFirst.md

@@ -1,77 +1,71 @@
-# Warum werden Tools zuerst aufgelistet?
+# Why Are Tools Listed First?
 
-Im Context-Panel von cc-viewer **erscheinen Tools vor System Prompt und Messages**. Diese Reihenfolge spiegelt exakt die **KV-Cache-Präfix-Sequenz der Anthropic API** wider.
+In CX Viewer's Context panel, **Tools appear before Instructions and Input**. For Codex, this is a diagnostic layout: tool definitions are a large, high-impact part of the request shape, so they are shown first before the instructions and conversation context they constrain.
 
-## KV-Cache-Präfix-Sequenz
+## Request Context Layout
 
-Wenn die Anthropic API den KV-Cache aufbaut, verkettet sie den Kontext in dieser **festen Reihenfolge** zu einem Präfix:
+Codex traffic can arrive from OpenAI Responses API calls, Codex app-server events, or SDK stream events. CX Viewer normalizes those sources into a consistent context view:
 
 ```
 ┌─────────────────────────────────────────────────┐
-│ 1. Tools (JSON Schema definitions)               │  ← Start of cache prefix
-│ 2. System Prompt                                 │
-│ 3. Messages (conversation history + current turn)│  ← End of cache prefix
+│ 1. Tools (JSON Schema definitions)               │  ← Capability surface
+│ 2. Instructions                                  │
+│ 3. Input (conversation history + current turn)   │
 └─────────────────────────────────────────────────┘
 ```
 
-Das bedeutet: **Tools befinden sich vor dem System Prompt, ganz am Anfang des Cache-Präfixes**.
+This does not claim a provider-specific serialization order. It gives you a stable way to inspect what capabilities were available before reading instructions and input history.
 
-## Warum haben Tools ein höheres Cache-Gewicht als System?
+## Why Tools Often Matter Most
 
-Beim KV-Cache-Präfix-Matching ist **früher Inhalt entscheidender** — jede Änderung macht alles Folgende ungültig:
+Tool definitions are often the largest static part of an agent request. A small UI toggle can add, remove, or reshape many tool schemas, which changes model behavior and request size.
 
-1. **Präfix-Matching beginnt am Anfang**: Der KV-Cache vergleicht die aktuelle Anfrage token-für-token vom Anfang mit dem gecachten Präfix. Sobald eine Abweichung gefunden wird, wird der gesamte nachfolgende Inhalt invalidiert.
+1. **Capability changes are semantic changes**: Adding or removing a tool changes what the agent is allowed to do, not just the token count.
 
-2. **Änderung der Tools = gesamter Cache invalidiert**: Da Tools an erster Stelle stehen, **bricht jede Änderung an Tool-Definitionen (auch das Hinzufügen oder Entfernen eines einzelnen MCP-Tools) das Präfix vom ersten Moment an**, wodurch alle gecachten System Prompt- und Messages-Inhalte invalidiert werden.
+2. **Tool schemas can dominate request size**: MCP and dynamic tools often have detailed JSON Schemas with descriptions, enums, and nested parameters.
 
-3. **Änderung von System = Messages-Cache invalidiert**: Der System Prompt befindet sich in der Mitte, sodass seine Änderungen nur den nachfolgenden Messages-Teil invalidieren.
+4. **Input appends are usually cheaper to inspect**: Normal conversation turns mostly add new user input and the previous assistant/tool results, while tool and instruction changes tend to be rarer and more important.
 
-4. **Änderung von Messages = nur das Ende betroffen**: Messages stehen am Ende, sodass das Anhängen neuer Messages nur ein kleines abschließendes Segment invalidiert — Tools- und System-Cache bleiben intakt.
+## Practical Impact
 
-## Praktische Auswirkungen
-
-| Änderungstyp | Cache-Auswirkung | Typisches Szenario |
+| Change Type | Cache Impact | Typical Scenario |
 |-------------|-------------|-----------------|
-| Tool hinzugefügt/entfernt | **Vollständige Invalidierung** | MCP-Server verbinden/trennen, IDE-Plugin ein-/ausschalten |
-| System Prompt-Änderung | Messages-Cache verloren | CLAUDE.md bearbeiten, system reminder einfügen |
-| Neue Message angehängt | Nur Tail-Inkrement | Normaler Gesprächsfluss (am häufigsten, am günstigsten) |
-
-Deshalb ist `tools_change` in [CacheRebuild](CacheRebuild.md) oft der teuerste Rebuild-Grund — es bricht die Präfix-Kette ganz am Anfang.
-
-## Warum werden Tool-Definitionen vor dem „Gehirn" platziert?
+| Tool added/removed | Request shape changes | MCP server connect/disconnect, plugin toggle |
+| Instructions change | Instructions and policy changed | `AGENTS.md` edit, developer instruction update |
+| New input appended | Normal turn growth | User input, assistant reply, tool result |
 
-Aus Caching-Perspektive ist die Platzierung der Tools an erster Stelle eine technische Tatsache. Doch auch aus Sicht des kognitiven Designs ist diese Reihenfolge logisch — **Tools sind die Hände und Füße, System Prompt ist das Gehirn**.
+## Why Are Tool Definitions Placed Before the "Brain"?
 
-Bevor ein Mensch handelt, muss er wahrnehmen, welche Gliedmaßen und Werkzeuge ihm zur Verfügung stehen. Ein Säugling versteht nicht zuerst die Regeln der Welt (System) und lernt dann zu greifen — er nimmt zuerst wahr, dass er Hände und Füße hat, und versteht dann durch Interaktion mit der Umwelt allmählich die Regeln. Ebenso muss ein LLM wissen, welche Tools es aufrufen kann (Dateien lesen, Code schreiben, suchen, Befehle ausführen), bevor es Aufgabenanweisungen (System Prompt) erhält, damit es bei der Verarbeitung der Anweisungen genau einschätzen kann: „Was kann ich tun?" und „Wie soll ich vorgehen?"
+From a diagnostic perspective, putting Tools first is useful because tool definitions describe the agent's available actions before you inspect the instructions that ask the agent to act.
 
-Wenn es umgekehrt wäre — dem Modell zuerst sagen „Deine Aufgabe ist es, dieses Modul umzubauen", dann „Du hast Read, Edit, Bash-Tools" — würde dem Modell beim Verständnis der Aufgabe kritische Information über seine Fähigkeitsgrenzen fehlen, was zu unrealistischen Plänen oder dem Übersehen verfügbarer Ansätze führen könnte.
+Before taking action, a person needs to perceive what limbs and tools are available. An infant doesn't first understand the rules of the world (Instructions), then learn to reach and grab — they first sense that they have hands and feet, then gradually understand rules through interaction with the environment. Similarly, an LLM needs to know what tools it can call (read files, write code, search, execute commands) before receiving task instructions, so it can accurately assess "what can I do" and "how should I do it" when processing the instructions.
 
-**Erst wissen, welche Karten man hat, dann entscheiden, wie man spielt.** Das ist die kognitive Logik dahinter, dass Tools vor System stehen.
+If reversed — first telling the model "your task is to refactor this module", then telling it "you have shell_command, apply_patch, and tool_search" — the model would lack critical capability boundary information when understanding the task, potentially producing unrealistic plans or overlooking available approaches.
 
-## Warum sind MCP-Tools ebenfalls an dieser Position?
+**Know what cards you hold before deciding how to play.** This is the cognitive logic behind Tools preceding Instructions.
 
-MCP-Tools (Model Context Protocol) werden wie eingebaute Tools ganz vorne im Tools-Bereich platziert. Das Verständnis der Position von MCP im Kontext hilft, die tatsächlichen Vorteile und Kosten zu bewerten.
+## Why Are MCP Tools Also in This Position?
 
-### Vorteile von MCP
+MCP (Model Context Protocol) tools, like built-in tools, are placed at the very front of the Tools area. Understanding MCP's position in the context helps evaluate its real benefits and costs.
 
-- **Fähigkeitserweiterung**: MCP ermöglicht Modellen den Zugriff auf externe Dienste (Datenbankabfragen, API-Aufrufe, IDE-Operationen, Browser-Steuerung usw.) und überwindet die Grenzen eingebauter Tools
-- **Offenes Ökosystem**: Jeder kann einen MCP-Server implementieren; das Modell erhält neue Fähigkeiten ohne Neutraining
-- **Laden bei Bedarf**: MCP-Server können je nach Aufgabenszenario selektiv verbunden/getrennt werden, was flexible Tool-Zusammenstellungen ermöglicht
+### MCP Advantages
 
-### Kosten von MCP
+- **Capability extension**: MCP lets models access external services (database queries, API calls, IDE operations, browser control, etc.), breaking beyond built-in tool boundaries
+- **Open ecosystem**: Anyone can implement an MCP server; the model gains new capabilities without retraining
+- **On-demand loading**: MCP servers can be selectively connected/disconnected based on task scenario, flexibly composing tool sets
 
-- **Cache-Killer**: Die JSON-Schema-Definition jedes MCP-Tools wird ganz an den Anfang des KV-Cache-Präfix angehängt. Ein MCP-Tool hinzufügen/entfernen = **gesamter Cache von Anfang an ungültig**. Häufiges Verbinden/Trennen von MCP-Servern reduziert die Cache-Trefferquote drastisch
-- **Präfix-Aufblähung**: MCP-Tool-Schemas sind typischerweise größer als eingebaute Tools (detaillierte Parameterbeschreibungen, Enumerationswerte usw.). Viele MCP-Tools erhöhen die Token-Anzahl im Tools-Bereich erheblich und verringern den für Messages verfügbaren Kontext-Raum
-- **Latenz-Overhead**: MCP-Tool-Aufrufe erfordern prozessübergreifende Kommunikation (JSON-RPC über stdio/SSE), eine Größenordnung langsamer als eingebaute Funktionsaufrufe
-- **Stabilitätsrisiko**: MCP-Server sind externe Prozesse, die abstürzen, Timeouts verursachen oder unerwartete Formate zurückgeben können und zusätzliche Fehlerbehandlung erfordern
+### MCP Costs
+- **Prefix bloat**: MCP tool Schemas are typically larger than built-in tools (containing detailed parameter descriptions, enums, etc.). Many MCP tools significantly increase the Tools area's token count, squeezing the context space available for Input
+- **Latency overhead**: MCP tool calls require cross-process communication (JSON-RPC over stdio/SSE), an order of magnitude slower than built-in function calls
+- **Stability risk**: MCP servers are external processes that may crash, timeout, or return unexpected formats, requiring additional error handling
 
-### Praktische Empfehlungen
+### Practical Recommendations
 
-| Szenario | Empfehlung |
-|----------|-----------|
-| Lange Gespräche, häufige Interaktion | MCP-Tool-Anzahl minimieren, um Cache-Präfix-Stabilität zu schützen |
-| Kurze Aufgaben, einmalige Operationen | MCP-Tools frei verwenden; Cache-Auswirkung ist begrenzt |
-| Häufiges Hinzufügen/Entfernen von MCP-Servern | Jede Änderung löst vollständigen Cache-Neuaufbau aus; feste Tool-Zusammenstellung erwägen |
-| Überdimensionierte Tool-Schemas | Beschreibungen und Enums kürzen, um Token-Verbrauch im Präfix zu reduzieren |
+| Scenario | Recommendation |
+|----------|---------------|
+| Long conversations, high-frequency interaction | Minimize MCP tool count to keep requests smaller and easier to inspect |
+| Short tasks, one-off operations | Use MCP tools freely; overhead is usually limited |
+| Frequently adding/removing MCP servers | Each change reshapes the request; consider fixing the tool set |
+| Oversized Tool Schemas | Trim descriptions and enums to reduce prefix token footprint |
 
-Im Context-Panel von cc-viewer werden MCP-Tools neben eingebauten Tools im Tools-Bereich angezeigt, sodass Sie die Schema-Größe jedes Tools und seinen Beitrag zum Cache-Präfix direkt sehen können.
+In CX Viewer's Context panel, MCP tools are displayed alongside built-in and dynamic tools in the Tools area, giving you a clear view of each tool's Schema size and contribution to request shape.

package/concepts/de/TranslateContextPollution.md

@@ -2,7 +2,7 @@
 
 ## Hintergrund
 
-CC-Viewer enthält eine integrierte Übersetzungsfunktion (`POST /api/translate`), die von der Anthropic Messages API angetrieben wird. In der frühen Implementierung verwendeten Übersetzungsanfragen die zwischengespeicherten Authentifizierungsdaten der Claude Code-Sitzung wieder — einschließlich der Header `x-api-key` und `authorization`. Dies verursachte ein subtiles, aber schwerwiegendes Problem: Übersetzungsergebnisse lieferten häufig irrelevante Inhalte zurück.
+CC-Viewer enthält eine integrierte Übersetzungsfunktion (`POST /api/translate`), die von der Anthropic Messages API angetrieben wird. In der frühen Implementierung verwendeten Übersetzungsanfragen die zwischengespeicherten Authentifizierungsdaten der Codex-Sitzung wieder — einschließlich der Header `x-api-key` und `authorization`. Dies verursachte ein subtiles, aber schwerwiegendes Problem: Übersetzungsergebnisse lieferten häufig irrelevante Inhalte zurück.
 
 ## Ursache
 
@@ -13,24 +13,24 @@ Die Anthropic API unterstützt zwei Authentifizierungsmethoden:
 | Methode | Header | Typische Quelle | Eigenschaften |
 |---------|--------|-----------------|---------------|
 | API-Schlüssel | `x-api-key: sk-ant-...` | Umgebungsvariable / Console | Zustandslos, jede Anfrage ist unabhängig |
-| OAuth-Token | `authorization: Bearer sessionToken` | Claude Code-Abonnement-Login | Sitzungsgebunden, Server pflegt Kontextzuordnung |
+| OAuth-Token | `authorization: Bearer sessionToken` | Codex-Abonnement-Login | Sitzungsgebunden, Server pflegt Kontextzuordnung |
 
 Der entscheidende Unterschied: **API-Schlüssel sind zustandslos** — jede Anfrage ist vollständig unabhängig; während **OAuth-Sitzungstoken zustandsbehaftet sind** — der Anthropic-Server ordnet Anfragen mit demselben Token demselben Sitzungskontext zu.
 
 ### Verschmutzungskette
 
-Wenn Claude Code die OAuth-Anmeldung über ein Abonnement verwendet, sieht der Authentifizierungsfluss folgendermaßen aus:
+Wenn Codex die OAuth-Anmeldung über ein Abonnement verwendet, sieht der Authentifizierungsfluss folgendermaßen aus:
 
 ```
-Claude Code Hauptkonversation ──(authorization: Bearer sessionToken)──→ Anthropic API
+Codex Hauptkonversation ──(authorization: Bearer sessionToken)──→ Anthropic API
                                                                           ↑
 CC-Viewer Übersetzungsanfrage ──(authorization: Bearer sessionToken)──→ Anthropic API
 ```
 
-Da Übersetzungsanfragen dasselbe Sitzungstoken wiederverwendeten, konnte der Anthropic-Server Übersetzungsanfragen mit dem Hauptkonversationskontext von Claude Code verknüpfen. Dies führt zu:
+Da Übersetzungsanfragen dasselbe Sitzungstoken wiederverwendeten, konnte der Anthropic-Server Übersetzungsanfragen mit dem Hauptkonversationskontext von Codex verknüpfen. Dies führt zu:
 
-1. **Übersetzungsergebnisse werden vom Hauptkonversationskontext beeinflusst**: Der Systemprompt der Übersetzungsanfrage lautet „Du bist ein Übersetzer", aber der Serverkontext enthält weiterhin den Gesprächsverlauf von Claude Code, was das Modell beeinträchtigen kann
-2. **Hauptkonversation wird durch Übersetzungsanfragen gestört**: Inhalte der Übersetzungsanfrage (UI-Textfragmente) können in den Hauptkonversationskontext injiziert werden, wodurch die Antworten von Claude Code abweichen
+1. **Übersetzungsergebnisse werden vom Hauptkonversationskontext beeinflusst**: Der Systemprompt der Übersetzungsanfrage lautet „Du bist ein Übersetzer", aber der Serverkontext enthält weiterhin den Gesprächsverlauf von Codex, was das Modell beeinträchtigen kann
+2. **Hauptkonversation wird durch Übersetzungsanfragen gestört**: Inhalte der Übersetzungsanfrage (UI-Textfragmente) können in den Hauptkonversationskontext injiziert werden, wodurch die Antworten von Codex abweichen
 3. **Unvorhersehbares Verhalten**: Da die Kontextverschmutzung serverseitiges Verhalten ist, kann der Client sie weder erkennen noch kontrollieren
 
 ## Erkenntnisse
@@ -41,6 +41,6 @@ Da Übersetzungsanfragen dasselbe Sitzungstoken wiederverwendeten, konnte der An
 ## Referenzen
 
 - [Anthropic API Authentication Docs](https://docs.anthropic.com/en/api/getting-started)
-- [Claude Code Authentication](https://support.claude.com/en/articles/12304248-managing-api-key-environment-variables-in-claude-code)
+- [Codex Authentication](https://support.claude.com/en/articles/12304248-managing-api-key-environment-variables-in-claude-code)
 - [Anthropic Bans Subscription OAuth in Third-Party Apps](https://winbuzzer.com/2026/02/19/anthropic-bans-claude-subscription-oauth-in-third-party-apps-xcxwbn/)
-- [Claude Code Authentication: API Keys, Subscriptions, and SSO](https://developertoolkit.ai/en/claude-code/quick-start/authentication/)
+- [Codex Authentication: API Keys, Subscriptions, and SSO](https://developertoolkit.ai/en/claude-code/quick-start/authentication/)

package/concepts/de/UltraPlan.md

@@ -1,55 +1,55 @@
-# UltraPlan — Die ultimative Wunschmaschine
+# UltraPlan — The Ultimate Wishing Machine
 
-## Was ist UltraPlan
+## What is UltraPlan
 
-UltraPlan ist die **lokalisierte Implementierung** von cc-viewer fuer den nativen `/ultraplan`-Befehl von Claude Code. Es ermoeglicht Ihnen, die vollstaendigen Funktionen von `/ultraplan` in Ihrer lokalen Umgebung zu nutzen, **ohne Claudes offiziellen Remote-Dienst starten zu muessen**, und leitet Claude Code an, komplexe Planungs- und Implementierungsaufgaben mittels **Multi-Agenten-Zusammenarbeit** zu bewaeltigen.
+UltraPlan is CX Viewer's **localized planning workflow** for Codex. It guides Codex through complex planning and implementation tasks using **multi-agent collaboration**.
 
-Im Vergleich zum regulaeren Plan-Modus oder Agent Team kann UltraPlan:
-- Automatisch die Aufgabenkomplexitaet bewerten und die optimale Planungsstrategie waehlen
-- Mehrere parallele Agenten einsetzen, um die Codebasis aus verschiedenen Dimensionen zu erkunden
-- Externe Recherche (webSearch) fuer branchenbewaehrte Verfahren einbeziehen
-- Nach der Planausfuehrung automatisch ein Code Review Team zusammenstellen
-- Einen vollstaendigen **Plan → Execute → Review → Fix** Kreislauf bilden
+Compared to regular Plan mode or Agent Team, UltraPlan can:
+- Automatically assess task complexity and select the optimal planning strategy
+- Deploy multiple parallel agents to explore the codebase from different dimensions
+- Incorporate external research (`web_search`) for industry best practices
+- Automatically assemble a Code Review Team after plan execution for code review
+- Form a complete **Plan → Execute → Review → Fix** closed loop
 
 ---
 
-## Wichtige Hinweise
+## Important Notes
 
-### 1. UltraPlan ist nicht allmaechtig
-UltraPlan ist eine leistungsfaehigere Wunschmaschine, aber das bedeutet nicht, dass jeder Wunsch erfuellt werden kann. Es ist leistungsfaehiger als Plan und Agent Team, kann aber nicht direkt „Geld fuer Sie verdienen". Beruecksichtigen Sie eine angemessene Aufgabengranularitaet — zerlegen Sie grosse Ziele in ausfuehrbare mittelgrosse Aufgaben, anstatt alles auf einmal erreichen zu wollen.
+### 1. UltraPlan Is Not Omnipotent
+UltraPlan is a more powerful wishing machine, but that doesn't mean every wish can be fulfilled. It's more powerful than Plan and Agent Team, but it can't directly "make you money." Consider reasonable task granularity — break large goals into executable medium-sized tasks rather than trying to accomplish everything in one shot.
 
-### 2. Derzeit am effektivsten fuer Programmierprojekte
-Die Vorlagen und Workflows von UltraPlan sind tiefgehend fuer Programmierprojekte optimiert. Andere Szenarien (Dokumentation, Datenanalyse usw.) koennen ausprobiert werden, aber es empfiehlt sich, auf Anpassungen in zukuenftigen Versionen zu warten.
+### 2. Currently Most Effective for Programming Projects
+UltraPlan's templates and workflows are deeply optimized for programming projects. Other scenarios (documentation, data analysis, etc.) can be attempted, but you may want to wait for future version adaptations.
 
-### 3. Ausfuehrungszeit und Kontextfenster-Anforderungen
-- Eine erfolgreiche UltraPlan-Ausfuehrung dauert in der Regel **30 Minuten oder laenger**
-- Erfordert, dass der MainAgent ein grosses Kontextfenster hat (1M-Context-Opus-Modell empfohlen)
-- Wenn Sie nur ein 200K-Modell haben, **fuehren Sie unbedingt `/clear` vor der Ausfuehrung aus**
-- Claude Codes `/compact` funktioniert schlecht bei unzureichendem Kontextfenster — vermeiden Sie es, den Platz aufzubrauchen
-- Ausreichend Kontextplatz zu erhalten ist eine entscheidende Voraussetzung fuer eine erfolgreiche UltraPlan-Ausfuehrung
+### 3. Execution Time and Context Window Requirements
+- A successful UltraPlan run typically takes **30 minutes or more**
+- Requires MainAgent to have a large enough context window for multi-agent findings and review output
+- If your active model has a smaller context window, **make sure to `/clear` context before running**
+- Compaction is less reliable when the context window is already nearly full — avoid running out of space
+- Maintaining sufficient context space is a critical prerequisite for successful UltraPlan execution
 
-Wenn Sie Fragen oder Vorschlaege zum lokalisierten UltraPlan haben, eroeffnen Sie gerne [Issues auf GitHub](https://github.com/anthropics/claude-code/issues), um zu diskutieren und zusammenzuarbeiten.
+If you have any questions or suggestions about the localized UltraPlan workflow, open an issue in the CX Viewer project to discuss and collaborate.
 
 ---
 
-## Funktionsweise
+## How It Works
 
-UltraPlan bietet zwei Betriebsmodi:
+UltraPlan offers two operating modes:
 
-### Automatischer Modus
-Analysiert automatisch die Aufgabenkomplexitaet (Score 4-12) und leitet an verschiedene Strategien weiter:
+### Auto Mode
+Automatically analyzes task complexity (score 4-12) and routes to different strategies:
 
-| Route | Score | Strategie |
-|-------|-------|-----------|
-| Route A | 4-6 | Leichtgewichtige Planung mit direkter Code-Erkundung |
-| Route B | 7-9 | Planung mit Strukturdiagrammen (Mermaid / ASCII) |
-| Route C | 10-12 | Multi-Agenten-Erkundung + Review-Kreislauf |
+| Route | Score | Strategy |
+|-------|-------|----------|
+| Route A | 4-6 | Lightweight planning with direct code exploration |
+| Route B | 7-9 | Planning with structural diagrams (Mermaid / ASCII) |
+| Route C | 10-12 | Multi-agent exploration + review closed loop |
 
-### Erzwungener Modus
-Aktiviert direkt den vollstaendigen Route-C-Multi-Agenten-Workflow:
-1. Bis zu 5 parallele Agenten einsetzen, die gleichzeitig die Codebasis erkunden (Architektur, Dateiidentifikation, Risikobewertung usw.)
-2. Optional einen Recherche-Agenten einsetzen, um ueber webSearch Branchenloesungen zu untersuchen
-3. Alle Agenten-Erkenntnisse zu einem detaillierten Implementierungsplan zusammenfassen
-4. Einen Review-Agenten einsetzen, der den Plan aus mehreren Perspektiven prueft
-5. Den Plan nach Genehmigung ausfuehren
-6. Nach der Implementierung automatisch ein Code Review Team zusammenstellen, um die Codequalitaet zu validieren
+### Forced Mode
+Directly activates the full Route C multi-agent workflow:
+1. Deploy up to 5 parallel agents to explore the codebase simultaneously (architecture, file identification, risk assessment, etc.)
+2. Optionally deploy a research agent to investigate industry solutions via `web_search`
+3. Synthesize all agent findings into a detailed implementation plan
+4. Deploy a review agent to scrutinize the plan from multiple perspectives
+5. Execute the plan once approved
+6. Automatically assemble a Code Review Team to validate code quality after implementation

package/concepts/en/BodyDiffJSON.md

@@ -2,7 +2,7 @@
 
 ## Background
 
-Claude Code's MainAgent uses a full-context sending mechanism — each request carries the complete conversation history, system prompt, tool definitions, and more. This means the request body grows increasingly large as the conversation progresses, making it difficult to quickly identify "what was actually added this round" when viewing the raw body.
+Codex MainAgent turns are represented as full request snapshots in CX Viewer. A request can include conversation history, instructions, tool definitions, metadata, and model/runtime options. As the session grows, the normalized body becomes harder to inspect by eye.
 
 Body Diff JSON solves exactly this problem: it automatically compares the bodies of two consecutive MainAgent requests, extracts the incremental differences, and lets you see at a glance what content was actually added in the current request.
 
@@ -14,19 +14,19 @@ Body Diff JSON solves exactly this problem: it automatically compares the bodies
    - New fields: Displayed directly
    - Deleted fields: Not shown (usually doesn't affect understanding)
    - Changed fields: Shows the current value
-   - `messages` array special handling: Only shows newly added messages (since normal conversation is append-only, prefix messages remain unchanged)
+   - `input` array special handling: Only shows newly added input items (since normal conversation is append-only, prefix input remains unchanged)
 4. **Request body shrinkage detection**: If the current request body is smaller than the previous one, it indicates context truncation or session reset, and a notice is displayed instead of a diff
 
 ## Typical Scenarios
 
 In a normal conversation round, Body Diff JSON typically contains only:
-- `messages`: 1-2 newly added messages (the user's input + the assistant's reply from the previous round)
+- `input`: 1-2 newly added input items (the user's input + the assistant's reply from the previous round)
 
-If you see changes to `system`, `tools`, `model`, or other fields in the diff, it means a configuration change occurred in this round, which is often the cause of a cache rebuild.
+If you see changes to `instructions`, `tools`, `model`, or other fields in the diff, it means a configuration change occurred in this round.
 
 ## Usage
 
 - Body Diff JSON is displayed in the MainAgent request detail panel
 - Click the title to expand/collapse
 - Supports both JSON and Text viewing modes, plus one-click copy
-- In the top-left **CC-Viewer → Global Settings**, you can set "Expand Body Diff JSON by default"
+- In the top-left **CX Viewer -> Global Settings**, you can set "Expand Body Diff JSON by default"

package/concepts/en/BodyFields.md

@@ -1,42 +1,39 @@
 # Request Body Fields
 
-Field descriptions for the top-level fields in the Claude API `/v1/messages` request body.
+Field descriptions for CX-Viewer's normalized Codex request body. The original source may be OpenAI Responses API traffic, Codex app-server notifications, or Codex SDK events; CX-Viewer maps them into one stable viewer shape.
 
 ## Field List
 
 | Field | Type | Description |
 |-------|------|-------------|
-| **model** | string | The model name to use, e.g. `claude-opus-4-6`, `claude-sonnet-4-6` |
-| **messages** | array | Conversation message history. Each message contains `role` (user/assistant) and `content` (an array of blocks such as text, image, tool_use, tool_result, etc.) |
-| **system** | array | System prompt. Contains Codex's core instructions, tool usage guidelines, environment information, CLAUDE.md contents, etc. Blocks with `cache_control` are subject to prompt caching |
-| **tools** | array | List of available tool definitions. Each tool contains `name`, `description`, and `input_schema` (JSON Schema). MainAgent typically has 20+ tools, while SubAgent has only a few |
-| **metadata** | object | Request metadata, usually containing `user_id` to identify the user |
+| **model** | string | The model name selected by Codex, e.g. a `gpt-*` model |
+| **input** | string/array | OpenAI Responses API input. Codex usually uses the array form for user input, assistant history, tool results, and other context items |
+| **instructions** | string/array | OpenAI Responses API instructions. This can include Codex core directives, tool usage guidelines, environment information, and `AGENTS.md` project instructions |
+| **tools** | array | Available tool definitions or compact tool descriptors. MainAgent usually has a broader tool set than SubAgent |
+| **metadata** | object | Request metadata such as `thread_id`, `turn_id`, `cwd`, SDK/app-server source, and subAgent parent-thread information |
 | **max_tokens** | number | Maximum number of tokens for a single model response, e.g. `16000`, `64000` |
-| **thinking** | object | Extended thinking configuration. `type: "enabled"` activates thinking mode, `budget_tokens` controls the thinking token limit |
-| **context_management** | object | Context management configuration. `truncation: "auto"` allows Codex to automatically truncate overly long message histories |
-| **output_config** | object | Output configuration, such as `format` settings |
-| **stream** | boolean | Whether to enable streaming responses. Codex always uses `true` |
+| **reasoning_effort** | string | Reasoning effort when reported by Codex |
+| **reasoning_summary** | string | Reasoning summary mode when reported by Codex |
+| **approval_policy** | string | Codex approval policy for the turn |
+| **sandbox_policy** | object/string | Sandbox policy for the turn when available |
+| **stream** | boolean | Whether the OpenAI Responses API request used streaming; app-server/SDK entries are normalized as streamed turns |
 
-## messages Structure
+## input Structure
 
-The `content` of each message is an array of blocks. Common types include:
+When `input` is an array, each input item usually contains `role` and `content`. `content` can be an array of blocks. Common types include:
 
 - **text**: Plain text content
 - **tool_use**: Model tool invocation (contains `name`, `input`)
 - **tool_result**: Tool execution result (contains `tool_use_id`, `content`)
-- **image**: Image content (base64 or URL)
+- **image/input_image/local_image**: Image content or an attached local image reference
 - **thinking**: Model's thinking process (extended thinking mode)
 
-## system Structure
+## instructions Structure
 
-The system prompt array typically contains:
+`instructions` typically contains:
 
 1. **Core agent instructions** ("You are Codex...")
 2. **Tool usage guidelines**
-3. **CLAUDE.md contents** (project-level instructions)
+3. **AGENTS.md contents** (project-level instructions)
 4. **Skills reminders** (skills reminder)
 5. **Environment information** (OS, shell, git status, etc.) — In fact, Codex relies heavily on git. If a project has a git repository, Codex demonstrates a better understanding of the project, including the ability to pull remote changes and commit history to assist with analysis
-
-Blocks marked with `cache_control: { type: "ephemeral" }` are cached by the Anthropic API for 5 minutes. When cache hits occur, they are billed as `cache_read_input_tokens` (significantly cheaper than `input_tokens`).
-
-> **Note**: For special clients like Codex, the Anthropic server does not rely entirely on the `cache_control` attribute in the request to determine caching behavior. The server automatically applies caching strategies to specific fields (such as system prompt and tools definitions), even when the request does not explicitly include `cache_control` markers. Therefore, don't be puzzled when you don't see this attribute in the request body — the server has already performed caching behind the scenes, it simply doesn't expose this information to the client. This is a tacit understanding between Codex and the Anthropic API.