›_ Codex Issues
Codex Issues / #26279

Feature request: allow folding verbose MCP tool result bodies in the Codex CLI TUI

Open 💬 4 comments Opened Jun 4, 2026 by sandynz

What variant of Codex are you using?

CLI

What feature would you like to see?

I would like the Codex CLI TUI to support folding or hiding verbose MCP tool result bodies in the main conversation history, while preserving the full result for the model and for explicit transcript inspection.

Today, Codex CLI TUI renders MCP tool result text directly in the conversation history after each MCP call. For tools that return file contents, the visible transcript can be dominated by tool result bodies:

• Called jetbrains-mcp.read_file(...)
  └ L1: ...
    L2: ...
    ...

This makes it difficult to read the assistant's higher-level messages. The issue is especially visible when the agent must load several skill, instruction, or project context files: those reads are legitimate and should not be artificially shortened, but their result bodies still flood the visible TUI history.

Reasonable designs:

  • Default collapsed MCP result body:

``text
• Called jetbrains-mcp.read_file(...) 58 lines, 9.2 KB
Press <key> or open transcript to view result
``

  • Config option, for example:

``toml
[tui]
fold_mcp_tool_results = "auto" # auto | always | never
mcp_tool_result_preview_lines = 1
``

  • Per-cell expand/collapse interaction in the transcript/history view.

Important distinction: this should be a display feature. It should not truncate or hide tool results from the model context, and it should not encourage agents to under-read required skill/instruction files.

Additional information

Local environment where this was observed:

Codex CLI: 0.135.0
Platform: Windows 11 Professional x64
Terminal: Windows Terminal / PowerShell
MCP server example: JetBrains MCP through stdio router

Reproduction outline:

  1. Configure any MCP server that exposes a file-reading tool. A JetBrains MCP server is one example.
  2. Start Codex CLI in TUI mode.
  3. Ask the assistant to read a file through MCP, for example a skill or project instruction file.
  4. Observe the conversation history after the MCP call.

Source check against current main suggests this is not currently configurable:

  • McpToolCallCell::display_lines() renders CallToolResult.content directly into history detail lines.
  • TOOL_CALL_MAX_LINES limits visible result height but still shows the body by default.
  • /raw / tui.raw_output_mode is for copy-friendly transcript selection and does not solve this compact-history use case.

This issue is about TUI readability and operator ergonomics, not MCP correctness.

View original on GitHub ↗

4 Comments

sandynz · 2 months ago

Additional context from a source check and existing issue search:

Existing issue search:

  • #4550 is related to output folding configurability, but it is about broader command output visibility/control rather than default folding of MCP tool result bodies in the main TUI history.
  • #6426 is about model-visible tool-result truncation. This request is about user-visible TUI rendering while preserving full tool results for the model.

Source check against current main (80b65e9945):

  • McpToolCallCell::display_lines() renders MCP CallToolResult.content into history detail lines.
  • McpToolCallCell::raw_lines() also emits the rendered content.
  • TOOL_CALL_MAX_LINES limits visible result height to 5 lines, but the body is still shown by default.
  • /raw / tui.raw_output_mode is for copy-friendly transcript selection, not a compact/folded MCP result display.
  • open_transcript opens the transcript overlay but does not collapse individual MCP result cells in the main history.

So I think this remains a TUI display/ergonomics feature request rather than a model-context truncation request or an MCP correctness bug.

kaywhy331 · 28 days ago

Narrow proposal: opt-in TokenPak activity grouping

A concrete downstream use case for this request is tokenpak codex, where TokenPak Companion exposes TokenPak, TokenPak Integrity Protocol (TIP), and Portable AI Knowledge (PAK) processing through MCP. This proposal does not request global folding of Codex tool activity. It asks for one compact row only for calls carrying explicit TokenPak activity provenance.

Desired main-history rendering

While TokenPak activity is in progress:

◐ 📦 TokenPak activity · 6 running · 9 complete

After all grouped calls reach a terminal state:

• 📦 TokenPak activity · 15 calls · 14 succeeded · 1 failed  (Ctrl+T for details)

Ctrl+T should retain and display every underlying call, argument, result, duration, and failure in execution order. This must be a presentation-only grouping: no tool result may be truncated or removed from model context, persisted history, hooks, approvals, telemetry, cancellation, or replay.

Scope

Group only activity explicitly attributed to the TokenPak integration:

  • calls from TokenPak Companion that carry a stable TokenPak activity-group identifier;
  • TIP and PAK tools/functions carrying that same explicit identifier;
  • nested Code Mode calls only when Codex retains that TokenPak provenance.

Do not group:

  • other MCP servers or untagged tools;
  • GitHub, web search, shell, filesystem, patch, or generic Code Mode activity, even when it occurs in a TokenPak repository;
  • approval prompts or actionable failure details.

Classification should use explicit server/tool metadata or Codex-side server configuration, not prompt text, repository paths, or command-name heuristics. The exact metadata/config shape can follow Codex conventions; conceptually, the integration needs a validated group id, display label, icon, and collapse preference. Codex should never accept raw ANSI escape sequences from an MCP server.

Rendering model

A turn-scoped activity cell keyed by the explicit group id could mirror the existing split between compact exec rendering and expanded transcript rendering:

  • compact history: one live or completed summary row;
  • transcript overlay: the individual child calls and their full outputs;
  • counters keyed by unique call id, with running, succeeded, failed, cancelled, and interrupted states handled deterministically;
  • failures summarized in the compact row, while their actionable text remains visible in the normal approval/error surface and in Ctrl+T;
  • resume/replay reconstructs the same group without changing call identity or order.
Optional TokenPak styling

When the terminal and Codex theme support color, the requested TokenPak palette is:

  • #00B4AA: 📦 mark, TokenPak activity label, spinner, and active accent;
  • normal terminal foreground: completed and succeeded counts;
  • #E5484D: failed count only;
  • #6B7280: (Ctrl+T for details) hint;
  • #F5A623: degraded/warning state only, not ordinary running activity.

Color must never be the only status signal. A no-color terminal should render the same words and counters. Width measurement must count 📦 as a wide glyph; on narrow terminals, Codex should preserve a one-row summary by dropping optional styling and then the parenthetical hint before it allows wrapping.

Acceptance criteria
  1. Only explicitly tagged TokenPak/TIP/PAK calls enter the group.
  2. Untagged and non-TokenPak activity renders exactly as it does today.
  3. Concurrent and sequential tagged calls update one stable summary row with correct counts.
  4. Ctrl+T exposes every individual call and full result.
  5. Tool results and call identities remain unchanged for the model and persisted transcript.
  6. Approvals, failures, cancellation, interruption, resume, and replay remain observable.
  7. True-color, no-color, Unicode-width, and narrow-terminal cases have retained TUI tests.

This is a server-scoped, opt-in refinement of #26279 (and the broader #18396), not a request to change the default presentation for every Codex tool.

pardeike · 15 days ago

I'm in the business of making tooling and mcp solutions like pardeike/GABS that connect to games and applications via a plugin architecture in order to control them. This naturally stresses this issue a lot since it produces very good control results but also causes an enormous amount of noise in the TUI.

<img width="1029" height="1020" alt="Image" src="https://github.com/user-attachments/assets/2bea7dca-55dc-4c0d-b9fa-fb158d743701" />

So please consider this issue - it is an important one.

pardeike · 15 days ago

Follow up:

Current main now has separate Display and Transcript rendering for McpToolCallCell through #38044, so this appears implementable as a small TUI-only change.

Proposed narrow behavior:

  • keep the MCP invocation and arguments exactly as today;
  • leave successful all-text results that fit in three wrapped rows unchanged;
  • for longer successful all-text results, show two preview rows plus … +N lines (ctrl + t to view transcript);
  • never compact failed or interrupted results, mixed or non-text content, or calls already using the code-mode compact renderer;
  • leave Ctrl+T, raw mode, model context, rollout storage, app-server events, approvals, and telemetry unchanged;
  • add no config, persistent cell state, server metadata, grouping, or tool-name heuristics.

One safety prerequisite: the TUI currently appears to discard McpToolCallStatus::Failed when a failed MCP response includes a result body, reconstructing it with is_error: false. I would preserve that status and add a regression snapshot so failed content cannot be compacted.

This follows the merged hook-context pattern in #31252 and the display/transcript split from #38044.

If that direction matches the intended UX, would a maintainer be willing to invite a small PR?