cx-viewer 1.0.3 → 1.0.4

package/concepts/en/Tool-tool_search.md

@@ -0,0 +1,12 @@
+# tool_search
+
+`tool_search` searches deferred tool metadata and exposes matching tools for the next turn.
+
+Current logs show it is used to discover multi-agent tools, computer-use, node_repl, browser control, and other plugin/deferred tools.
+
+Fields:
+
+- `query`: search text, required.
+- `limit`: optional maximum number of tools to return.
+
+Response-side `tool_search_call` entries map to this document.

package/concepts/en/Tool-update_goal.md

@@ -0,0 +1,9 @@
+# update_goal
+
+`update_goal` marks the active goal as `complete` or `blocked`.
+
+Boundaries:
+
+- Use `complete` only when the objective is actually achieved and no required work remains.
+- Use `blocked` only after the same blocking condition repeats under the goal rules and no meaningful progress is possible.
+- Do not use it merely because work is hard, uncertain, or near a budget limit.

package/concepts/en/Tool-update_plan.md

@@ -0,0 +1,9 @@
+# update_plan
+
+`update_plan` maintains the current task plan and step statuses. At most one step should be `in_progress` at a time.
+
+Step statuses:
+
+- `pending`: not started.
+- `in_progress`: currently being worked on.
+- `completed`: finished.

package/concepts/en/Tool-view_image.md

@@ -0,0 +1,10 @@
+# view_image
+
+`view_image` displays a local image file for visual inspection, screenshot review, or asset verification.
+
+Fields:
+
+- `path`: local image path, required.
+- `detail`: optional detail level, `high` or `original`.
+
+Legacy `ImageView` and `imageView` entries map to this capability.

package/concepts/en/Tool-wait.md

@@ -0,0 +1,12 @@
+# wait
+
+`wait` resumes a yielded `exec` cell and returns only its new output or final completion state.
+
+Fields:
+
+- `cell_id`: running exec cell identifier, required.
+- `yield_time_ms`: how long to wait before yielding again.
+- `max_tokens`: output budget for this wait call.
+- `terminate`: stop the cell instead of waiting when true.
+
+Use it only after `exec` reports that the script is still running and provides a cell id.

package/concepts/en/Tool-wait_agent.md

@@ -0,0 +1,9 @@
+# wait_agent
+
+`wait_agent` waits for a mailbox update from any live agent. It also ends early for final-status notifications or when new user input redirects the active turn.
+
+Field:
+
+- `timeout_ms`: optional wait duration within the runtime's allowed range.
+
+The result summarizes which agents have updates but does not include the message contents; inspect the delivered agent messages in the conversation.

package/concepts/en/Tool-web_search.md

@@ -0,0 +1,11 @@
+# web_search
+
+`web_search` performs web search for text or images. The Codex manual describes `web_search` transcript items whenever Codex searches the web; the capability can also be configured as cached, live, or disabled.
+
+Use it when:
+
+- The user explicitly asks to browse, search, or verify current information.
+- The answer needs official documentation, direct links, or precise source attribution.
+- The relevant facts may have changed.
+
+Response-side `web_search_call` entries map to this document.

package/concepts/en/Tools.md

@@ -1,67 +1,38 @@
-# Claude Code Tools Overview
+# Codex Tools
 
-Claude Code provides a set of built-in tools to the model through the Anthropic API's tool_use mechanism. Each MainAgent request includes the complete JSON Schema definitions of these tools in the `tools` array, and the model invokes them via `tool_use` content blocks in its responses.
+The tools shown in the context-usage popover come from the currently loaded Codex request-body tools, not the legacy tool catalog. The July 11, 2026 local request logs contain 14 nested/core tools plus two newly loaded tool groups with 8 callable entries, for 22 documented tools in total.
 
-Below is a categorized index of all tools.
+## Code Mode
 
-## Agent System
+- exec: Code Mode's orchestration suite for discovering, composing, parallelizing, and resuming nested tool workflows inside a fresh V8 isolate.
+- wait: resume or terminate a yielded exec cell and return its latest output.
 
-| Tool | Purpose |
-|------|---------|
-| [Task](Tool-Task.md) | Launch a SubAgent to handle complex multi-step tasks |
-| [TaskOutput](Tool-TaskOutput.md) | Get the output of a background task |
-| [TaskStop](Tool-TaskStop.md) | Stop a running background task |
-| [TaskCreate](Tool-TaskCreate.md) | Create a structured task list entry |
-| [TaskGet](Tool-TaskGet.md) | Get task details |
-| [TaskUpdate](Tool-TaskUpdate.md) | Update task status, dependencies, etc. |
-| [TaskList](Tool-TaskList.md) | List all tasks |
+## Core tools
 
-## File Operations
+- shell_command: run local shell commands with explicit working directory and sandbox/approval metadata.
+- apply_patch: edit workspace files with structured patches.
+- view_image: inspect local image files.
+- update_plan: maintain the task plan.
+- request_user_input: ask structured short questions in Plan mode.
+- get_goal: read the active goal status, budget, and usage.
+- create_goal: create a goal only when explicitly requested.
+- update_goal: mark a goal complete or blocked under the goal rules.
+- tool_search: search deferred tool metadata and expose matching tools for the next turn.
+- list_mcp_resources: list resources exposed by MCP servers.
+- list_mcp_resource_templates: list parameterized MCP resource templates.
+- read_mcp_resource: read a specific MCP resource.
+- web_search: search the web for text or images.
+- image_generation: generate PNG images.
 
-| Tool | Purpose |
-|------|---------|
-| [Read](Tool-Read.md) | Read file contents (supports text, images, PDF, Jupyter notebook) |
-| [Edit](Tool-Edit.md) | Edit files via exact string replacement |
-| [Write](Tool-Write.md) | Write to or overwrite files |
-| [NotebookEdit](Tool-NotebookEdit.md) | Edit Jupyter notebook cells |
+## Multi-Agent V2
 
-## Search
+- spawn_agent: create a bounded sub-agent task.
+- send_message: queue context or guidance for an existing agent without starting a turn.
+- followup_task: assign a follow-up and start the target when it is idle.
+- wait_agent: wait for mailbox, completion, or user-steering updates.
+- interrupt_agent: stop the target's current turn while keeping the agent available.
+- list_agents: inspect the live agent tree.
 
-| Tool | Purpose |
-|------|---------|
-| [Glob](Tool-Glob.md) | Search files by filename pattern matching |
-| [Grep](Tool-Grep.md) | Search file contents based on ripgrep |
+The Code Mode and Multi-Agent V2 names are confirmed both by the captured request bodies and by the corresponding tool registration code in `openai/codex`. MCP, plugin, app-connector, and other dynamic tools are intentionally not hard-coded here because Codex discovers and injects them per session.
 
-## Terminal
-
-| Tool | Purpose |
-|------|---------|
-| [Bash](Tool-Bash.md) | Execute shell commands |
-
-## Web
-
-| Tool | Purpose |
-|------|---------|
-| [WebFetch](Tool-WebFetch.md) | Fetch web page content and process it with AI |
-| [WebSearch](Tool-WebSearch.md) | Search engine queries |
-
-## Planning & Interaction
-
-| Tool | Purpose |
-|------|---------|
-| [EnterPlanMode](Tool-EnterPlanMode.md) | Enter plan mode to design an implementation plan |
-| [ExitPlanMode](Tool-ExitPlanMode.md) | Exit plan mode and submit the plan for user approval |
-| [AskUserQuestion](Tool-AskUserQuestion.md) | Ask the user a question for clarification or decisions |
-
-## Extensions
-
-| Tool | Purpose |
-|------|---------|
-| [Skill](Tool-Skill.md) | Execute a skill (slash command) |
-
-## IDE Integration
-
-| Tool | Purpose |
-|------|---------|
-| [getDiagnostics](Tool-getDiagnostics.md) | Get VS Code language diagnostics |
-| [executeCode](Tool-executeCode.md) | Execute code in a Jupyter kernel |
+Legacy tool names are not part of the Codex tool catalog and are not kept as concept aliases.

package/concepts/en/ToolsFirst.md

@@ -1,52 +1,48 @@
 # Why Are Tools Listed First?
 
-In cc-viewer's Context panel, **Tools appear before System Prompt and Messages**. This ordering precisely mirrors the **Anthropic API's KV-Cache prefix sequence**.
+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 Prefix Sequence
+## Request Context Layout
 
-When Anthropic's API constructs the KV-Cache, it concatenates context into a prefix in this **fixed order**:
+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)   │
 └─────────────────────────────────────────────────┘
 ```
 
-This means **Tools sit before System Prompt at the very beginning of the cache prefix**.
+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.
 
-## Why Do Tools Have Higher Cache Weight Than System?
+## Why Tools Often Matter Most
 
-In KV-Cache prefix matching, **earlier content is more critical** — any change invalidates everything after it:
+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. **Prefix matching starts from the beginning**: The KV-Cache compares the current request against the cached prefix token-by-token from the start. The moment a mismatch is found, all subsequent content is invalidated.
+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. **Tools change = entire cache invalidated**: Since Tools come first, any change to tool definitions (even adding or removing a single MCP tool) **breaks the prefix from the very start**, invalidating all cached System Prompt and Messages.
+2. **Tool schemas can dominate request size**: MCP and dynamic tools often have detailed JSON Schemas with descriptions, enums, and nested parameters.
 
-3. **System change = Messages cache invalidated**: System Prompt sits in the middle, so its changes only invalidate the Messages portion that follows.
-
-4. **Messages change = only the tail affected**: Messages are at the end, so appending new messages only invalidates a small trailing segment — Tools and System cache remain intact.
+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.
 
 ## Practical Impact
 
 | Change Type | Cache Impact | Typical Scenario |
 |-------------|-------------|-----------------|
-| Tool added/removed | **Full invalidation** | MCP server connect/disconnect, IDE plugin toggle |
-| System Prompt change | Messages cache lost | CLAUDE.md edit, system reminder injection |
-| New message appended | Tail increment only | Normal conversation flow (most common, cheapest) |
-
-This is why `tools_change` in [CacheRebuild](CacheRebuild.md) tends to be the most expensive rebuild reason — it breaks the prefix chain at the very front.
+| 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 |
 
 ## Why Are Tool Definitions Placed Before the "Brain"?
 
-From a caching perspective, Tools being first is a technical fact. But from a cognitive design perspective, this ordering is equally logical — **Tools are the hands and feet, System Prompt is the brain**.
+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.
 
-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 (System), 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 (System Prompt), so it can accurately assess "what can I do" and "how should I do it" when processing the instructions.
+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.
 
-If reversed — first telling the model "your task is to refactor this module", then telling it "you have Read, Edit, Bash tools" — the model would lack critical capability boundary information when understanding the task, potentially producing unrealistic plans or overlooking available approaches.
+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.
 
-**Know what cards you hold before deciding how to play.** This is the cognitive logic behind Tools preceding System.
+**Know what cards you hold before deciding how to play.** This is the cognitive logic behind Tools preceding Instructions.
 
 ## Why Are MCP Tools Also in This Position?
 
@@ -59,9 +55,7 @@ MCP (Model Context Protocol) tools, like built-in tools, are placed at the very
 - **On-demand loading**: MCP servers can be selectively connected/disconnected based on task scenario, flexibly composing tool sets
 
 ### MCP Costs
-
-- **Cache killer**: Each MCP tool's JSON Schema definition is concatenated into the very front of the KV-Cache prefix. Adding or removing one MCP tool = **entire cache invalidated from the start**. Frequently connecting/disconnecting MCP servers will dramatically reduce cache hit rates
-- **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 Messages
+- **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
 
@@ -69,9 +63,9 @@ MCP (Model Context Protocol) tools, like built-in tools, are placed at the very
 
 | Scenario | Recommendation |
 |----------|---------------|
-| Long conversations, high-frequency interaction | Minimize MCP tool count to protect cache prefix stability |
-| Short tasks, one-off operations | Use MCP tools freely; cache impact is limited |
-| Frequently adding/removing MCP servers | Each change triggers full cache rebuild; consider fixing the tool set |
+| 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 |
 
-In cc-viewer's Context panel, MCP tools are displayed alongside built-in tools in the Tools area, giving you a clear view of each tool's Schema size and contribution to the cache prefix.
+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/en/TranslateContextPollution.md

@@ -1,46 +1,18 @@
-# Translate API Context Pollution
+# Auxiliary Request Isolation
 
 ## Background
 
-CC-Viewer includes a built-in translation feature (`POST /api/translate`) powered by the Anthropic Messages API. In the early implementation, translation requests reused cached authentication credentials from the Claude Code session — including both `x-api-key` and `authorization` headers. This caused a subtle but serious issue: translation results frequently returned irrelevant content.
+Some request details include sensitive authentication headers such as `authorization` or `x-api-key`. CX Viewer shows this concept next to those headers because auxiliary features must never reuse a live Codex session credential casually.
 
-## Root Cause
+## Rule
 
-### Fundamental Difference Between Two Authentication Methods
+Internal helper requests should be isolated from the main Codex conversation:
 
-The Anthropic API supports two authentication methods:
+1. Use their own endpoint and credential when a helper must call a model service.
+2. Do not forward the main session's `authorization` header to unrelated services.
+3. Treat prompt text, file snippets, and tool context as user data that may be routed through the active proxy profile.
+4. Prefer local processing for UI-only features when possible.
 
-| Method | Header | Typical Source | Characteristics |
-|--------|--------|----------------|-----------------|
-| API Key | `x-api-key: sk-ant-...` | Environment variable / Console | Stateless, each request is independent |
-| OAuth Token | `authorization: Bearer sessionToken` | Claude Code subscription login | Session-bound, server maintains context association |
+## Why It Matters
 
-The key difference: **API Keys are stateless** — each request is completely independent; while **OAuth session tokens are stateful** — the Anthropic server associates requests using the same token to the same session context.
-
-### Pollution Chain
-
-When Claude Code uses subscription OAuth login, the authentication flow looks like:
-
-```
-Claude Code main conversation ──(authorization: Bearer sessionToken)──→ Anthropic API
-                                                                          ↑
-CC-Viewer translate request ──(authorization: Bearer sessionToken)──→ Anthropic API
-```
-
-Since translation requests reused the same session token, the Anthropic server may associate translation requests with Claude Code's main conversation context. This causes:
-
-1. **Translation results influenced by main conversation context**: The translation request's system prompt is "you are a translator", but the server context still contains Claude Code's conversation history, potentially interfering with the model
-2. **Main conversation disturbed by translation requests**: Translation request content (UI text fragments) may be injected into the main conversation context, causing Claude Code's responses to deviate
-3. **Unpredictable behavior**: Since context pollution is server-side behavior, the client cannot detect or control it
-
-## Lessons Learned
-
-- **OAuth session tokens are not "just another API Key"** — they carry server-side state, reusing them means sharing context
-- **Internal service calls should use independent, stateless authentication** to avoid association with user sessions
-
-## References
-
-- [Anthropic API Authentication Docs](https://docs.anthropic.com/en/api/getting-started) — Official documentation on `x-api-key` and `authorization` headers
-- [Claude Code Authentication](https://support.claude.com/en/articles/12304248-managing-api-key-environment-variables-in-claude-code) — API Key environment variable management
-- [Anthropic Bans Subscription OAuth in Third-Party Apps](https://winbuzzer.com/2026/02/19/anthropic-bans-claude-subscription-oauth-in-third-party-apps-xcxwbn/) — Anthropic's restrictions on OAuth token usage scope
-- [Claude Code Authentication: API Keys, Subscriptions, and SSO](https://developertoolkit.ai/en/claude-code/quick-start/authentication/) — Authentication method comparison
+Reusing a session credential can bind unrelated helper traffic to the user's main agent session or leak request context to an unexpected service. Keeping helper calls separate makes proxy behavior easier to audit and prevents accidental cross-contamination between UI features and Codex turns.

package/concepts/en/UltraPlan.md

@@ -2,12 +2,12 @@
 
 ## What is UltraPlan
 
-UltraPlan is cc-viewer's **localized implementation** of Claude Code's native `/ultraplan` command. It allows you to use the full capabilities of `/ultraplan` in your local environment **without needing to launch Claude's official remote service**, guiding Claude Code to accomplish complex planning and implementation tasks using **multi-agent collaboration**.
+UltraPlan is CX Viewer's **localized planning workflow** for Codex. It guides Codex through complex planning and implementation tasks using **multi-agent collaboration**.
 
 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 (webSearch) for industry best practices
+- 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
 
@@ -23,12 +23,12 @@ UltraPlan's templates and workflows are deeply optimized for programming project
 
 ### 3. Execution Time and Context Window Requirements
 - A successful UltraPlan run typically takes **30 minutes or more**
-- Requires MainAgent to have a large context window (1M context Opus model recommended)
-- If you only have a 200K model, **make sure to `/clear` context before running**
-- Claude Code's `/compact` performs poorly when the context window is insufficient — avoid running out of space
+- 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
 
-If you have any questions or suggestions about the localized UltraPlan, feel free to open [Issues on GitHub](https://github.com/anthropics/claude-code/issues) to discuss and collaborate.
+If you have any questions or suggestions about the localized UltraPlan workflow, open an issue in the CX Viewer project to discuss and collaborate.
 
 ---
 
@@ -48,7 +48,7 @@ Automatically analyzes task complexity (score 4-12) and routes to different stra
 ### 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 webSearch
+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

package/concepts/es/BodyDiffJSON.md

@@ -2,7 +2,7 @@
 
 ## Contexto
 
-El MainAgent de Claude Code utiliza un mecanismo de envío de contexto completo: cada solicitud incluye el historial completo de la conversación, el system prompt, las definiciones de herramientas, etc. Esto significa que a medida que avanza la conversación, el cuerpo de la solicitud se vuelve cada vez más grande, y es difícil identificar rápidamente "qué se agregó en esta ronda" al ver el Body sin procesar.
+El MainAgent de Codex utiliza un mecanismo de envío de contexto completo: cada solicitud incluye el historial completo de la conversación, el system prompt, las definiciones de herramientas, etc. Esto significa que a medida que avanza la conversación, el cuerpo de la solicitud se vuelve cada vez más grande, y es difícil identificar rápidamente "qué se agregó en esta ronda" al ver el Body sin procesar.
 
 Body Diff JSON resuelve exactamente este problema: compara automáticamente los cuerpos de dos solicitudes MainAgent consecutivas, extrae la parte incremental y te permite ver de un vistazo el contenido realmente nuevo en esta solicitud.
 

package/concepts/es/BodyFields.md

@@ -1,42 +1,39 @@
-# Campos del cuerpo de la solicitud (Request Body)
+# Request Body Fields
 
-Descripción de los campos de nivel superior del cuerpo de la solicitud `/v1/messages` de la API de Claude.
+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.
 
-## Lista de campos
+## Field List
 
-| Campo | Tipo | Descripción |
+| Field | Type | Description |
 |-------|------|-------------|
-| **model** | string | Nombre del modelo a utilizar, por ejemplo `claude-opus-4-6`, `claude-sonnet-4-6` |
-| **messages** | array | Historial de mensajes de la conversación. Cada mensaje contiene `role` (user/assistant) y `content` (un array de bloques como texto, imagen, tool_use, tool_result, etc.) |
-| **system** | array | System prompt. Contiene las instrucciones principales de Codex, directrices de uso de herramientas, información del entorno, contenido de CLAUDE.md, etc. Los bloques con `cache_control` están sujetos a prompt caching |
-| **tools** | array | Lista de definiciones de herramientas disponibles. Cada herramienta contiene `name`, `description` e `input_schema` (JSON Schema). MainAgent normalmente tiene más de 20 herramientas, mientras que SubAgent solo tiene unas pocas |
-| **metadata** | object | Metadatos de la solicitud, generalmente contiene `user_id` para identificar al usuario |
-| **max_tokens** | number | Número máximo de tokens para una respuesta individual del modelo, por ejemplo `16000`, `64000` |
-| **thinking** | object | Configuración de pensamiento extendido. `type: "enabled"` activa el modo de pensamiento, `budget_tokens` controla el límite de tokens de pensamiento |
-| **context_management** | object | Configuración de gestión de contexto. `truncation: "auto"` permite que Codex trunque automáticamente historiales de mensajes demasiado largos |
-| **output_config** | object | Configuración de salida, como ajustes de `format` |
-| **stream** | boolean | Si se habilitan las respuestas en streaming. Codex siempre usa `true` |
-
-## Estructura de messages
-
-El `content` de cada mensaje es un array de bloques. Los tipos comunes incluyen:
-
-- **text**: Contenido de texto plano
-- **tool_use**: Invocación de herramienta por el modelo (contiene `name`, `input`)
-- **tool_result**: Resultado de la ejecución de la herramienta (contiene `tool_use_id`, `content`)
-- **image**: Contenido de imagen (base64 o URL)
-- **thinking**: Proceso de pensamiento del modelo (modo de pensamiento extendido)
-
-## Estructura de system
-
-El array del system prompt normalmente contiene:
-
-1. **Instrucciones principales del agente** ("You are Codex...")
-2. **Directrices de uso de herramientas**
-3. **Contenido de CLAUDE.md** (instrucciones a nivel de proyecto)
-4. **Recordatorios de habilidades** (skills reminder)
-5. **Información del entorno** (SO, shell, estado de git, etc.) — De hecho, Codex depende en gran medida de git. Si un proyecto tiene un repositorio git, Codex demuestra una mejor comprensión del proyecto, incluyendo la capacidad de obtener cambios remotos e historial de commits para asistir en el análisis
-
-Los bloques marcados con `cache_control: { type: "ephemeral" }` son almacenados en caché por la API de Anthropic durante 5 minutos. Cuando se producen aciertos de caché, se facturan como `cache_read_input_tokens` (significativamente más barato que `input_tokens`).
-
-> **Nota**: Para clientes especiales como Codex, el servidor de Anthropic no depende completamente del atributo `cache_control` en la solicitud para determinar el comportamiento de caché. El servidor aplica automáticamente estrategias de caché a campos específicos (como el system prompt y las definiciones de tools), incluso cuando la solicitud no incluye explícitamente marcadores `cache_control`. Por lo tanto, no se sorprenda si no ve este atributo en el cuerpo de la solicitud — el servidor ya ha realizado el almacenamiento en caché entre bastidores, simplemente no expone esta información al cliente. Este es un entendimiento tácito entre Codex y la API de Anthropic.
+| **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` |
+| **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 |
+
+## input Structure
+
+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/input_image/local_image**: Image content or an attached local image reference
+- **thinking**: Model's thinking process (extended thinking mode)
+
+## instructions Structure
+
+`instructions` typically contains:
+
+1. **Core agent instructions** ("You are Codex...")
+2. **Tool usage guidelines**
+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