cx-viewer 1.0.2 → 1.0.4

package/concepts/ja/ToolsFirst.md

@@ -1,77 +1,71 @@
-# なぜToolsが最初に表示されるのか？
+# Why Are Tools Listed First?
 
-cc-viewerのContextパネルでは、**ToolsはSystem PromptとMessagesより前に表示されます**。この順序は、**Anthropic APIのKV-Cacheプレフィックスシーケンス**を正確に反映しています。
+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プレフィックスシーケンス
+## Request Context Layout
 
-Anthropic のAPIがKV-Cacheを構築する際、コンテキストを以下の**固定された順序**でプレフィックスとして連結します：
+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)   │
 └─────────────────────────────────────────────────┘
 ```
 
-つまり、**ToolsはSystem Promptより前、キャッシュプレフィックスの最先頭に位置します**。
+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.
 
-## なぜToolsはSystemよりキャッシュの重みが大きいのか？
+## Why Tools Often Matter Most
 
-KV-Cacheのプレフィックスマッチングでは、**前方のコンテンツほど重要**です — 変更が発生すると、それ以降のすべてが無効化されます：
+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. **プレフィックスマッチングは先頭から開始される**：KV-Cacheは現在のリクエストをキャッシュされたプレフィックスと先頭からtoken単位で比較します。不一致が見つかった瞬間、それ以降のコンテンツはすべて無効化されます。
+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の変更 = キャッシュ全体が無効化**：Toolsは最前列にあるため、tool定義の変更（MCP toolの追加・削除1つでも）は**プレフィックスを最先頭から破壊し**、キャッシュされたSystem Promptと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の変更 = Messagesキャッシュが無効化**：System Promptは中間に位置するため、その変更は後続のMessages部分のみを無効化します。
+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. **Messagesの変更 = 末尾部分のみ影響**：Messagesは末尾にあるため、新しいmessageの追加は小さな末尾セグメントのみを無効化します — ToolsとSystemのキャッシュはそのまま保持されます。
+## Practical Impact
 
-## 実際の影響
-
-| 変更の種類 | キャッシュへの影響 | 典型的なシナリオ |
+| Change Type | Cache Impact | Typical Scenario |
 |-------------|-------------|-----------------|
-| Tool追加/削除 | **完全無効化** | MCPサーバーの接続/切断、IDEプラグインの切り替え |
-| System Promptの変更 | Messagesキャッシュが失われる | CLAUDE.mdの編集、system reminderの挿入 |
-| 新しいmessageの追加 | 末尾の増分のみ | 通常の会話フロー（最も一般的、最もコストが低い） |
-
-これが、[CacheRebuild](CacheRebuild.md)における`tools_change`が最もコストの高いリビルド理由になりやすい理由です — プレフィックスチェーンを最前部から破壊するからです。
-
-## なぜツール定義が「脳」より先に配置されるのか？
+| 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 |
 
-キャッシュの仕組みから言えば、Toolsが最前列に位置するのは技術的な事実です。しかし認知設計の観点からも、この順序は理にかなっています —— **Toolsは手足であり、System Promptは脳です**。
+## Why Are Tool Definitions Placed Before the "Brain"?
 
-人は行動する前に、自分がどんな手足や道具を使えるかを感知する必要があります。赤ちゃんは最初に世界のルール（System）を理解してから手を伸ばすのではなく、まず自分に手や足があることを感知し、環境との相互作用を通じて徐々にルールを理解していきます。同様に、LLMはタスク指示（System Prompt）を受け取る前に、どんなツールを呼び出せるか（ファイル読み取り、コード記述、検索、コマンド実行）を知っておく必要があります。そうすることで、指示を処理する際に「何ができるか」「どうすべきか」を正確に判断できるのです。
+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.
 
-もし逆だったら —— まずモデルに「このモジュールをリファクタリングせよ」と伝え、次に「Read、Edit、Bashなどのツールがある」と伝える —— モデルはタスクを理解する際に重要な能力境界の情報が欠けてしまい、非現実的な計画を立てたり、利用可能な手段を見落としたりする可能性があります。
+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.
 
-**手持ちのカードを知ってから、どう切るかを決める。** これがToolsがSystemより先に来る認知的論理です。
+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.
 
-## なぜMCPツールもこの位置にあるのか？
+**Know what cards you hold before deciding how to play.** This is the cognitive logic behind Tools preceding Instructions.
 
-MCP（Model Context Protocol）ツールは、組み込みツールと同様にTools領域の最前列に配置されます。MCPのコンテキスト内での位置を理解することは、その実際のメリットとコストを評価するのに役立ちます。
+## Why Are MCP Tools Also in This Position?
 
-### 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.
 
-- **能力拡張**：MCPにより、モデルは外部サービス（データベースクエリ、API呼び出し、IDE操作、ブラウザ制御など）にアクセスでき、組み込みツールの境界を超えることができます
-- **オープンエコシステム**：誰でもMCPサーバーを実装でき、モデルは再トレーニングなしで新しい能力を獲得できます
-- **オンデマンド読み込み**：タスクのシナリオに応じてMCPサーバーを選択的に接続/切断でき、ツールセットを柔軟に構成できます
+### MCP Advantages
 
-### 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
 
-- **キャッシュキラー**：各MCPツールのJSON Schema定義はKV-Cacheプレフィックスの最前列に連結されます。MCPツールを1つ追加/削除するだけで = **キャッシュ全体が最初から無効化**されます。MCPサーバーの接続/切断を頻繁に行うと、キャッシュヒット率が大幅に低下します
-- **プレフィックスの肥大化**：MCPツールのSchemaは通常、組み込みツールより大きくなります（詳細なパラメータ説明、列挙値などを含む）。多数のMCPツールはTools領域のトークン数を大幅に増加させ、Messagesに使えるコンテキスト空間を圧迫します
-- **レイテンシオーバーヘッド**：MCPツール呼び出しにはプロセス間通信（JSON-RPC over stdio/SSE）が必要で、組み込み関数呼び出しより1桁遅くなります
-- **安定性リスク**：MCPサーバーは外部プロセスであり、クラッシュ、タイムアウト、予期しないフォーマットの返却が起こりうるため、追加のエラーハンドリングが必要です
+### 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
 
-### 実践的な推奨事項
+### Practical Recommendations
 
-| シナリオ | 推奨 |
-|----------|------|
-| 長い会話、高頻度のやり取り | MCPツールの数を最小限にし、キャッシュプレフィックスの安定性を保護 |
-| 短いタスク、一回限りの操作 | MCPツールを自由に使用可能；キャッシュへの影響は限定的 |
-| MCPサーバーの頻繁な追加/削除 | 変更のたびにキャッシュが全面再構築される；ツールセットの固定を検討 |
-| 過大なTool Schema | descriptionとenumを削減し、プレフィックスのトークン消費を削減 |
+| 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 |
 
-cc-viewerのContextパネルでは、MCPツールは組み込みツールと並んでTools領域に表示され、各ツールのSchemaサイズとキャッシュプレフィックスへの寄与を直感的に確認できます。
+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/ja/TranslateContextPollution.md

@@ -2,7 +2,7 @@
 
 ## 背景
 
-CC-Viewerには、Anthropic Messages APIを利用した組み込み翻訳機能（`POST /api/translate`）が含まれています。初期の実装では、翻訳リクエストがClaude Codeセッションからキャッシュされた認証情報（`x-api-key`と`authorization`ヘッダーの両方）を再利用していました。これにより、微妙ながら深刻な問題が発生しました：翻訳結果に無関係なコンテンツが頻繁に返されるようになったのです。
+CC-Viewerには、Anthropic Messages APIを利用した組み込み翻訳機能（`POST /api/translate`）が含まれています。初期の実装では、翻訳リクエストがCodexセッションからキャッシュされた認証情報（`x-api-key`と`authorization`ヘッダーの両方）を再利用していました。これにより、微妙ながら深刻な問題が発生しました：翻訳結果に無関係なコンテンツが頻繁に返されるようになったのです。
 
 ## 根本原因
 
@@ -13,24 +13,24 @@ Anthropic APIは2つの認証方式をサポートしています：
 | 方式 | ヘッダー | 典型的なソース | 特徴 |
 |------|----------|----------------|------|
 | APIキー | `x-api-key: sk-ant-...` | 環境変数 / Console | ステートレス、各リクエストが独立 |
-| OAuthトークン | `authorization: Bearer sessionToken` | Claude Codeサブスクリプションログイン | セッションに紐づき、サーバーがコンテキストの関連付けを維持 |
+| OAuthトークン | `authorization: Bearer sessionToken` | Codexサブスクリプションログイン | セッションに紐づき、サーバーがコンテキストの関連付けを維持 |
 
 重要な違い：**APIキーはステートレス**であり、各リクエストは完全に独立しています。一方、**OAuthセッショントークンはステートフル**であり、Anthropicサーバーは同じトークンを使用するリクエストを同一のセッションコンテキストに関連付けます。
 
 ### 汚染の連鎖
 
-Claude Codeがサブスクリプション型OAuthログインを使用する場合、認証フローは以下のようになります：
+Codexがサブスクリプション型OAuthログインを使用する場合、認証フローは以下のようになります：
 
 ```
-Claude Code メイン会話 ──(authorization: Bearer sessionToken)──→ Anthropic API
+Codex メイン会話 ──(authorization: Bearer sessionToken)──→ Anthropic API
                                                                     ↑
 CC-Viewer 翻訳リクエスト ──(authorization: Bearer sessionToken)──→ Anthropic API
 ```
 
-翻訳リクエストが同じセッショントークンを再利用していたため、Anthropicサーバーは翻訳リクエストをClaude Codeのメイン会話コンテキストに関連付ける可能性がありました。これにより以下の問題が発生します：
+翻訳リクエストが同じセッショントークンを再利用していたため、Anthropicサーバーは翻訳リクエストをCodexのメイン会話コンテキストに関連付ける可能性がありました。これにより以下の問題が発生します：
 
-1. **翻訳結果がメイン会話のコンテキストに影響される**：翻訳リクエストのシステムプロンプトは「あなたは翻訳者です」ですが、サーバーコンテキストにはClaude Codeの会話履歴が残っており、モデルに干渉する可能性があります
-2. **メイン会話が翻訳リクエストによって乱される**：翻訳リクエストの内容（UIテキストの断片）がメイン会話のコンテキストに注入され、Claude Codeの応答がずれる可能性があります
+1. **翻訳結果がメイン会話のコンテキストに影響される**：翻訳リクエストのシステムプロンプトは「あなたは翻訳者です」ですが、サーバーコンテキストにはCodexの会話履歴が残っており、モデルに干渉する可能性があります
+2. **メイン会話が翻訳リクエストによって乱される**：翻訳リクエストの内容（UIテキストの断片）がメイン会話のコンテキストに注入され、Codexの応答がずれる可能性があります
 3. **予測不能な動作**：コンテキスト汚染はサーバー側の動作であるため、クライアント側では検出も制御もできません
 
 ## 教訓
@@ -41,6 +41,6 @@ CC-Viewer 翻訳リクエスト ──(authorization: Bearer sessionToken)──
 ## 参考資料
 
 - [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/ja/UltraPlan.md

@@ -1,55 +1,55 @@
-# UltraPlan — 究極の願望マシン
+# UltraPlan — The Ultimate Wishing Machine
 
-## UltraPlan とは
+## What is UltraPlan
 
-UltraPlan は、Claude Code のネイティブ `/ultraplan` コマンドに対する cc-viewer の**ローカライズ実装**です。Claude の公式リモートサービスを起動することなく、ローカル環境で `/ultraplan` のフル機能を利用でき、Claude Code が**マルチエージェント協調**により複雑な計画・実装タスクを遂行するよう導きます。
+UltraPlan is CX Viewer's **localized planning workflow** for Codex. It guides Codex through complex planning and implementation tasks using **multi-agent collaboration**.
 
-通常の Plan モードや Agent Team と比較して、UltraPlan は以下が可能です：
-- タスクの複雑さを自動評価し、最適な計画戦略を選択
-- 複数の並列エージェントを配置し、異なる観点からコードベースを探索
-- 外部リサーチ（webSearch）を取り入れ、業界のベストプラクティスを参照
-- 計画の実行後、自動的に Code Review Team を編成しコードレビューを実施
-- 完全な **Plan → Execute → Review → Fix** のクローズドループを形成
+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
 
 ---
 
-## 重要な注意事項
+## Important Notes
 
-### 1. UltraPlan は万能ではない
-UltraPlan はより強力な願望マシンですが、すべての願いが叶うわけではありません。Plan や Agent Team より強力ですが、直接「お金を稼ぐ」ことはできません。適切なタスク粒度を考慮してください——大きな目標を実行可能な中規模タスクに分割し、一度にすべてを達成しようとしないでください。
+### 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. 現時点ではプログラミングプロジェクトに最も効果的
-UltraPlan のテンプレートとワークフローは、プログラミングプロジェクト向けに深く最適化されています。他のシナリオ（ドキュメント作成、データ分析など）も試すことはできますが、将来のバージョンでの対応を待つことをお勧めします。
+### 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. 実行時間とコンテキストウィンドウの要件
-- UltraPlan の正常な実行には通常 **30 分以上**かかります
-- MainAgent に大きなコンテキストウィンドウが必要です（1M context の Opus モデルを推奨）
-- 200K モデルのみの場合、**実行前に必ず `/clear` でコンテキストをクリアしてください**
-- Claude Code の `/compact` はコンテキストウィンドウが不足すると性能が低下します——空間の枯渇を避けてください
-- 十分なコンテキスト空間を維持することが、UltraPlan を成功させるための重要な前提条件です
+### 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
 
-ローカライズ版 UltraPlan についてご質問やご提案がありましたら、お気軽に [GitHub Issues](https://github.com/anthropics/claude-code/issues) でディスカッションにご参加ください。
+If you have any questions or suggestions about the localized UltraPlan workflow, open an issue in the CX Viewer project to discuss and collaborate.
 
 ---
 
-## 仕組み
+## How It Works
 
-UltraPlan には 2 つの動作モードがあります：
+UltraPlan offers two operating modes:
 
-### 自動モード
-タスクの複雑さ（スコア 4-12）を自動分析し、異なる戦略にルーティングします：
+### Auto Mode
+Automatically analyzes task complexity (score 4-12) and routes to different strategies:
 
-| ルート | スコア | 戦略 |
-|--------|--------|------|
-| ルート A | 4-6 | 軽量な計画と直接的なコード探索 |
-| ルート B | 7-9 | 構造図（Mermaid / ASCII）を伴う計画 |
-| ルート C | 10-12 | マルチエージェント探索 + レビューのクローズドループ |
+| 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 |
 
-### 強制モード
-完全なルート C のマルチエージェントワークフローを直接起動します：
-1. 最大 5 つの並列エージェントを配置し、コードベースを同時に探索（アーキテクチャ、ファイル特定、リスク評価など）
-2. オプションでリサーチエージェントを配置し、webSearch で業界ソリューションを調査
-3. すべてのエージェントの調査結果を統合し、詳細な実装計画にまとめる
-4. レビューエージェントを配置し、複数の観点から計画を精査
-5. 承認後に計画を実行
-6. 実装完了後、自動的に Code Review Team を編成しコード品質を検証
+### 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/ko/BodyDiffJSON.md

@@ -2,7 +2,7 @@
 
 ## 배경
 
-Claude Code의 MainAgent는 전체 컨텍스트 전송 방식을 채택하고 있어, 매 요청마다 완전한 대화 이력, system prompt, 도구 정의 등의 내용을 포함합니다. 이는 대화가 진행될수록 요청 본문이 점점 커진다는 것을 의미하며, 원시 Body를 직접 확인해서는 "이번에 실제로 무엇이 추가되었는지"를 빠르게 파악하기 어렵습니다.
+Codex의 MainAgent는 전체 컨텍스트 전송 방식을 채택하고 있어, 매 요청마다 완전한 대화 이력, system prompt, 도구 정의 등의 내용을 포함합니다. 이는 대화가 진행될수록 요청 본문이 점점 커진다는 것을 의미하며, 원시 Body를 직접 확인해서는 "이번에 실제로 무엇이 추가되었는지"를 빠르게 파악하기 어렵습니다.
 
 Body Diff JSON은 바로 이 문제를 해결하기 위한 것입니다. 전후 두 MainAgent 요청의 body를 자동으로 비교하여 증분 부분을 추출함으로써, 이번 요청에서 실제로 추가된 내용을 한눈에 파악할 수 있습니다.
 

package/concepts/ko/BodyFields.md

@@ -1,42 +1,39 @@
-# Request Body 필드 설명
+# Request Body Fields
 
-Claude API `/v1/messages` 요청 본문의 최상위 필드 설명.
+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
 
-| 필드 | 타입 | 설명 |
-|------|------|------|
-| **model** | string | 사용할 모델 이름. 예: `claude-opus-4-6`, `claude-sonnet-4-6` |
-| **messages** | array | 대화 메시지 기록. 각 메시지에는 `role`(user/assistant)과 `content`(텍스트, 이미지, tool_use, tool_result 등의 block 배열)가 포함됨 |
-| **system** | array | System prompt. Codex의 핵심 지시, 도구 사용 설명, 환경 정보, CLAUDE.md 내용 등을 포함. `cache_control`이 있는 블록은 prompt caching 됨 |
-| **tools** | array | 사용 가능한 도구 정의 목록. 각 도구에는 `name`, `description`, `input_schema`(JSON Schema)가 포함됨. MainAgent는 보통 20개 이상의 도구를 가지며, SubAgent는 소수만 가짐 |
-| **metadata** | object | 요청 메타데이터. 일반적으로 사용자를 식별하기 위한 `user_id`를 포함 |
-| **max_tokens** | number | 모델이 단일 응답에서 생성할 수 있는 최대 토큰 수. 예: `16000`, `64000` |
-| **thinking** | object | 확장 사고 설정. `type: "enabled"`로 사고 모드를 활성화하고, `budget_tokens`로 사고 토큰 상한을 제어 |
-| **context_management** | object | 컨텍스트 관리 설정. `truncation: "auto"`를 사용하면 Codex가 너무 긴 메시지 기록을 자동으로 잘라냄 |
-| **output_config** | object | 출력 설정. `format` 설정 등 |
-| **stream** | boolean | 스트리밍 응답 활성화 여부. Codex는 항상 `true`를 사용 |
+| Field | Type | Description |
+|-------|------|-------------|
+| **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 |
 
-## messages 구조
+## input Structure
 
-각 메시지의 `content`는 block 배열이며, 일반적인 유형은 다음과 같음:
+When `input` is an array, each input item usually contains `role` and `content`. `content` can be an array of blocks. Common types include:
 
-- **text**: 일반 텍스트 콘텐츠
-- **tool_use**: 모델의 도구 호출 (`name`, `input` 포함)
-- **tool_result**: 도구 실행 결과 (`tool_use_id`, `content` 포함)
-- **image**: 이미지 콘텐츠 (base64 또는 URL)
-- **thinking**: 모델의 사고 과정 (확장 사고 모드)
+- **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)
 
-## system 구조
+## instructions Structure
 
-system prompt 배열에는 일반적으로 다음이 포함됨:
+`instructions` typically contains:
 
-1. **핵심 agent 지시** ("You are Codex...")
-2. **도구 사용 규범**
-3. **CLAUDE.md 내용** (프로젝트 수준 지시)
-4. **스킬 프롬프트** (skills reminder)
-5. **환경 정보** (OS, shell, git 상태 등) — 사실 Codex는 git에 크게 의존함. 프로젝트에 git 저장소가 있으면 Codex는 원격 변경 사항과 커밋 기록을 가져와 분석을 보조하는 등 프로젝트에 대한 더 나은 이해 능력을 보여줌
-
-`cache_control: { type: "ephemeral" }` 표시가 있는 블록은 Anthropic API에 의해 5분간 캐시되며, 캐시 적중 시 `cache_read_input_tokens`로 과금됨 (`input_tokens`보다 훨씬 저렴).
-
-> **참고**: Codex와 같은 특수 클라이언트의 경우, Anthropic 서버 측은 실제로 요청의 `cache_control` 속성에 완전히 의존하여 캐싱 동작을 결정하지 않음. 서버 측은 특정 필드(system prompt, 도구 정의 등)에 대해 자동으로 캐싱 정책을 실행하며, 요청에 `cache_control` 표시가 명시적으로 포함되어 있지 않더라도 마찬가지임. 따라서 요청 본문에서 이 속성을 찾을 수 없더라도 의아하게 생각할 필요 없음 — 서버 측이 이미 백그라운드에서 캐싱 작업을 완료했으며, 단지 이 정보를 클라이언트에 노출하지 않았을 뿐임. 이는 Codex와 Anthropic API 사이의 일종의 암묵적 합의임.
+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