PR 4525 --experimental-json dramatically reduces the amount of information compared to --json

Resolved 💬 6 comments Opened Oct 10, 2025 by phubaba Closed Nov 15, 2025
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What feature would you like to see?

I would like to see information from the deprecated --json returned such as tool call arguments and tool call results. This pr removed very useful information from 'msg' https://github.com/openai/codex/pull/4525

I leave you with the codex change to my code which parsed the original json and its own feelings about the change. Note the sad face emoji from codex itself!

● I've rewritten the decode_event function to handle the new Codex JSON format from PR #4525. Here are the key changes:

  What Changed

  1. New event structure: Events now use type field directly (not nested in msg)
    - thread.started, turn.started, turn.completed
    - item.started, item.completed
  2. Item-based architecture: Different content types are now items with item_type:
    - assistant_message → text response to user
    - error → error messages
    - reasoning → internal reasoning (displayed with 💭)
    - mcp_tool_call → MCP tool invocations (no args/results in new format 😢)
    - command_execution, file_change, web_search, todo_list → placeholders for future data
  3. Token usage: Now comes from turn.completed event's usage field
  4. Loss of information: The new format sadly doesn't include tool arguments or results, so we can only report that a tool was called with server/tool
  name.

  The function now properly handles all the item types you mentioned and maps them to the appropriate types.

Additional information

_No response_

View original on GitHub ↗

6 Comments

github-actions[bot] contributor · 10 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #4685

Powered by Codex Action

pakrym-oai contributor · 10 months ago

Can you share your use case, please? What information are you missing to enable it?

phubaba · 10 months ago

Hi the use case is that we are missing the calls arguments as well as the call response/exception. We have metrics that track the tool usage and failures so we can improve our tool context and user experience. Now all we get back is a tool call, it's name, and a status result. It's very minimal compared to what previously was provided.

techjoec · 10 months ago

Yes same here..There's another Issue open on this too so we are not alone. Make it optional worst case please!

iskng · 10 months ago

Why reduce the output? Need to see all the tool calls, files read, and edits made.

double-thinker · 9 months ago

I saw the documentation was aligned with the real behaviour (no diffs are exposed). Is there any plan in the future to add again the file diff?