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_
6 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Can you share your use case, please? What information are you missing to enable it?
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.
Yes same here..There's another Issue open on this too so we are not alone. Make it optional worst case please!
Why reduce the output? Need to see all the tool calls, files read, and edits made.
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?