Skip to content

[Bug]: Codex Desktop does not expose MCP tools from MCP for Unity HTTP server on Windows 11 #1193

Closed
#1292
Closed
[Bug]: Codex Desktop does not expose MCP tools from MCP for Unity HTTP server on Windows 11#1193
#1292
Labels
bugSomething isn't working

Description

@AmberY1618
AmberY1618
opened on Jun 8, 2026

What happened?

I am using MCP for Unity with Codex Desktop on Windows. The Unity MCP server starts correctly and responds at http://127.0.0.1:8080/mcp, but Codex Desktop does not expose any Unity MCP tools when I configure it directly as an HTTP MCP server.

Environment:

  • OS: Windows
  • Machine: Lenovo Windows PC
  • Unity version: 2022.3.44f1 (c3ae09b9f03c)
  • MCP for Unity server package: mcpforunityserver==9.7.1
  • Unity MCP URL: http://127.0.0.1:8080/mcp
  • Codex Desktop version: 26.602.40724
  • Codex config has rmcp_client = true
  • Windows sandbox setting: elevated

Original Codex MCP config:

[mcp_servers.unityMCP]
url = "http://127.0.0.1:8080/mcp"

The Unity MCP server appears healthy. A direct request to the endpoint returns a protocol-level response, not a connection failure:

  "jsonrpc": "2.0",
  "id": "server-error",
  "error": {
    "code": -32600,
    "message": "Not Acceptable: Client must accept text/event-stream"}

However, after restarting Codex Desktop, no Unity MCP tools are exposed. Tools such as read_console, manage_gameobject, find_gameobjects, and manage_scene are not available.

As a workaround, I created a local stdio bridge using the Python MCP SDK. The bridge connects to the same Unity MCP HTTP endpoint using streamable_http_client. Through that stdio bridge, Codex can see the Unity MCP server correctly. The bridge reports:

43 tools
19 resources
6 resource templates
Calling read_console through the stdio bridge succeeds and returns Unity console logs.

So the Unity MCP server itself seems to work. The issue appears to be that Codex Desktop does not expose the tools when connecting directly to the Unity MCP HTTP/streamable endpoint.

Reproduction steps

1.Open the Unity project on Windows.

2.Start MCP for Unity from inside Unity.

3.Confirm that Unity reports the MCP server is running at:
http://127.0.0.1:8080/mcp

4.Open Codex Desktop.

5.Configure Codex to use the Unity MCP server directly:

[mcp_servers.unityMCP]
url = "http://127.0.0.1:8080/mcp"

6.Make sure remote MCP support is enabled:

[features]
rmcp_client = true

7.Restart Codex Desktop.

8.Ask Codex to detect or use the Unity MCP server.

9.Observe that Codex fails to detect/connect to the Unity MCP server and does not expose any Unity MCP tools.

10.Expected result: Codex should expose Unity MCP tools such as read_console, find_gameobjects, manage_gameobject, and manage_scene.

11.Actual result: Codex does not expose any Unity MCP tools when using the direct HTTP MCP config.

Unity version

2022.3.44f1

MCP for Unity package version

9.7.1

Python server version

No response

MCP client

Codex

Transport

HTTP (default)

OS

Windows

Relevant logs / console output

Checks

  • I searched existing issues and did not find a duplicate
  • I included logs / steps to reproduce

Activity

  1. AmberY1618
    added
    bugSomething isn't working
    on Jun 8, 2026

  2. BBigBei commented on Jun 17, 2026

    @BBigBei
    BBigBei
    on Jun 17, 2026

    Same here

  3. theyzs commented on Jun 17, 2026

    @theyzs
    theyzs
    on Jun 17, 2026

    same here, and thank you for your temporal solution, works for me

  4. BBigBei commented on Jun 22, 2026

    @BBigBei
    BBigBei
    on Jun 22, 2026

    This didn't work for me. However, I managed to get it working after Codex automatically fixed the configuration.

    Changing the transport mode from HTTPLocal to stdio, and adding the following to config.toml solved the issue:

    [mcp_servers.unityMCP]
command = "C:\\Users\\13482\\.local\\bin\\uvx.exe"
args = [ "--offline", "--from", "mcpforunityserver==9.7.3", "mcp-for-unity", "--transport", "stdio" ]
startup_timeout_sec = 60
env = { SystemRoot = "C:\\WINDOWS", UNITY_MCP_SKIP_STARTUP_CONNECT = "1", FASTMCP_SHOW_SERVER_BANNER = "false", FASTMCP_CHECK_FOR_UPDATES = "off" }

  5. BuKuSiShen commented on Jun 23, 2026

    @BuKuSiShen
    BuKuSiShen
    on Jun 23, 2026

    Create a red, blue, ane yellow cube in the current scene, spaced one unit apart on the X axis
    目前所有工具调用都返回 unsupported call-无论是MCP Unity 工具还是标准 Codex 工具(shell_command,read_mcp_resource等)都无法执行。这不是 Unity没启动的问题，而是Codex的工具调度层整体不响应
    我遇到的问题是调用工具都返回unsupported call

  6. AmberY1618 commented on Jul 1, 2026

    @AmberY1618
    AmberY1618
    on Jul 1, 2026
    Author

    This didn't work for me. However, I managed to get it working after Codex automatically fixed the configuration.

    Changing the transport mode from HTTPLocal to stdio, and adding the following to config.toml solved the issue:

    [mcp_servers.unityMCP]
    command = "C:\Users\13482\.local\bin\uvx.exe"
    args = [ "--offline", "--from", "mcpforunityserver==9.7.3", "mcp-for-unity", "--transport", "stdio" ]
    startup_timeout_sec = 60
    env = { SystemRoot = "C:\WINDOWS", UNITY_MCP_SKIP_STARTUP_CONNECT = "1", FASTMCP_SHOW_SERVER_BANNER = "false", FASTMCP_CHECK_FOR_UPDATES = "off" }

    This worked for me as well. Thanks!

  7. Scriptwonder
    added a commit that references this issue on Jul 28, 2026

    fix: advertise Codex as stdio-only (#1193)

    4ff8ff8
  8. Scriptwonder
    closed this as completedin #1292on Jul 28, 2026
  9. Scriptwonder
    added a commit that references this issue on Jul 28, 2026

    Merge pull request #1292 from Scriptwonder/fix/1193-codex-stdio-only

    334f3c0

  10. Scriptwonder commented on Aug 2, 2026

    @Scriptwonder
    Scriptwonder
    on Aug 2, 2026
    Collaborator

    Following up here rather than reopening, since the original symptom may well be real — but the fix I merged in #1292 was too broad, and #1305 walks part of it back.

    #1292 declared Codex stdio-only. Tested against Codex CLI 0.47.0 with an isolated CODEX_HOME, that isn't right: a bare

    [mcp_servers.unityMCP]
url = "http://127.0.0.1:8123/mcp"

    reports transport: streamable_http from codex mcp get, and Codex completes a full MCP handshake against a live MCP-for-Unity HTTP server — initialize 200, notifications/initialized 202, SSE GET 200, tools/list 200 — with no feature flag set at all. Adding [features] rmcp_client, the deprecated root-level experimental_use_rmcp_client, both, or even a deliberately bogus feature key all give byte-identical results; unknown feature keys are silently ignored.

    So HTTP works on current Codex, and #1292 removed a capability every Codex user has.

    What I could not verify: this issue was filed against Codex Desktop on Windows 11, and I only tested the CLI. The two may resolve config differently.

    @AmberY1618 — if you're still around, two things would settle it:

    1. Which Codex version, and was it the CLI or the desktop app?
    2. Does codex mcp get unityMCP report transport: streamable_http for you?

    If Desktop genuinely can't do HTTP, the fix belongs in Desktop-specific handling rather than disabling HTTP for everyone, and I'll open a separate issue for it.

    Also relevant to anyone landing here from a search: #1215 is the same report from a different angle, and the feature flag was renamed — [features] rmcp_client is current, root-level experimental_use_rmcp_client is deprecated (openai/codex#6995).

  11. Scriptwonder
    added 2 commits that reference this issue on Aug 2, 2026

    fix: restore HTTP transport for Codex (#1193)

    267b465

    Merge pull request #1305 from Scriptwonder/fix/1193-restore-codex-http

    5f8c806
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions