[Windows][codex_apps][MCP OAuth] Brokered connector tool calls reach remote MCP but fail with -32603 Internal error

What version of Codex CLI is running?

0.151.0

What subscription do you have?

ChatGPT Plus

Which model were you using?

gpt-5.5 xhigh

What platform is your computer?

Windows 11 x64

What terminal emulator and version are you using (if applicable)?

Windows Terminal / PowerShell

Codex doctor report

not available

What issue are you seeing?

A brokered codex_apps MCP connector can be created successfully and OAuth/PKCE completes successfully, but MCP tool calls fail with:

Mcp error: -32603: Internal error

The affected connector is a remote Streamable HTTP MCP server.

Both workspace_info and read_file reach the connector/bridge, but both return the same generic -32603 Internal error.

The bridge shows that the request is received, but no underlying server-side exception or stack trace is exposed.

The connector is not a locally configured Codex MCP server:
codex mcp list reports "No MCP servers configured yet."

Local server validation passes completely:

• 14 test files passed
• 146 tests passed
• Typecheck passed
• Streamable HTTP MCP integration tests passed
• workspace_info test passed
• read_file test passed
• OAuth/token enforcement tests passed

This suggests the failure is in the codex_apps brokered connector / MCP invocation layer rather than the local MCP server implementation.

Possibly related to openai/codex#35344.

Important difference from #35344:
In this case the bridge reports that the tool invocation/request is received, whereas #35344 reported requests not leaving the client.

What steps can reproduce the bug?

1. Start the remote Streamable HTTP MCP bridge for the Codex with ChatGPT workspace.

2. Create the ChatGPT/Codex brokered connector with OAuth 2.1 / PKCE.

3. Complete OAuth successfully.

   • Pairing succeeds.
   • Access token is issued.
   • Required scopes are granted:
     offline_access
     workspace.read
     workspace.search
     git.read
     execution.read

4. In Codex CLI 0.151.0, invoke the brokered connector tool:
   workspace_info

5. The request reaches the connector/bridge, but Codex returns:

   Mcp error: -32603: Internal error

6. Invoke:
   read_file

7. The request again reaches the connector/bridge and returns the same:

   Mcp error: -32603: Internal error

8. Verify local MCP server health:

   • 14 test files passed
   • 146 tests passed
   • Typecheck passed
   • Streamable HTTP MCP integration tests passed
   • workspace_info test passed
   • read_file test passed
   • OAuth/token enforcement tests passed

9. Run:
   codex mcp list

10. CLI reports:
    No MCP servers configured yet.

This confirms the failing connector is a codex_apps brokered connector, not a locally configured Codex MCP server.

What is the expected behavior?

The codex_apps brokered connector should successfully invoke the remote MCP tool and return the tool result.

If the invocation cannot be completed because of an OAuth, transport, session, or connector error, Codex should expose the actual underlying error instead of returning only:

Mcp error: -32603: Internal error

Additional information

Possible relation: openai/codex#35344

Important difference:
In this case, the remote bridge confirms that the MCP tool invocation/request is received.

In #35344, the reported failure occurred before the request left the client.

The local MCP server implementation has also been independently validated:

• 14 test files passed
• 146 tests passed
• Typecheck passed
• Streamable HTTP MCP integration tests passed
• workspace_info test passed
• read_file test passed
• OAuth/token enforcement tests passed

No access token, pairing code, secret, or private identifier is included in this report.

Start with the codex_apps brokered connector path for workspace_info and read_file, comparing its behavior with the reported difference from openai/codex#35344. Review the bridge request and OAuth/PKCE flow alongside the already-passing local MCP tests. Done means brokered remote tool calls return their results, or expose the underlying OAuth, transport, session, or connector error instead of -32603.