codex - 💡(How to fix) Fix Auto-unwrap FastMCP results [1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openai/codex#17733Fetched 2026-04-14 05:40:59
View on GitHub
Comments
1
Participants
2
Timeline
7
Reactions
0
Author
Participants
Timeline (top)
labeled ×3commented ×1mentioned ×1subscribed ×1

Code Example

{"result": "example1\nexample2"}

---

example1
example2
RAW_BUFFERClick to expand / collapse

What variant of Codex are you using?

App, CLI

What feature would you like to see?

FastMCP servers will auto-wrap all tool responses in a {"result": ...} JSON structure in order to comply with the MCP spec when returning primitive values (see: https://fastmcp.wiki/en/clients/tools#primitive-type-unwrapping). FastMCP assumes that the MCP client will auto-unwrap these.

Codex does not currently unwrap FastMCP results. I tested both Gemini CLI and the VSCode GitHub Copilot extension, and they both seem to unwrap them.

I think this would be a nice feature to have. With the current behavior, any FastMCP primitive strings are kept JSON-encoded, meaning newlines are escaped. For example:

{"result": "example1\nexample2"}

instead of

example1
example2

I've noticed that with strings with lots of newlines, model performance seems to be slightly worse when in this escaped form rather than as a raw string.

In order to avoid tampering with non-FastMCP servers that happen to return JSON of the form {"result": ...}, FastMCP seems to set "x-fastmcp-wrap-result": true in the schema which can be used to detect FastMCP servers.

The only potential downside I can think of this feature is that it increases risk of prompt injection, so (maybe) this could be an opt-in feature in the config.toml.

Additional information

No response

extent analysis

TL;DR

Implement auto-unwrapping of FastMCP server responses in Codex to improve model performance and user experience.

Guidance

  • Check the response schema for the presence of "x-fastmcp-wrap-result": true to detect FastMCP servers and determine if auto-unwrapping is necessary.
  • Consider adding an opt-in configuration option in config.toml to enable auto-unwrapping, mitigating potential prompt injection risks.
  • Verify that auto-unwrapping does not interfere with non-FastMCP servers that may return similar JSON structures.
  • Test the performance impact of auto-unwrapping on model responses, especially for strings with multiple newlines.

Example

No code example is provided due to lack of specific implementation details.

Notes

The implementation should carefully consider the potential security implications of auto-unwrapping and ensure that it does not introduce vulnerabilities.

Recommendation

Apply workaround: Implement auto-unwrapping with an opt-in configuration option to balance improved model performance with security concerns.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

codex - 💡(How to fix) Fix Auto-unwrap FastMCP results [1 comments, 2 participants]