Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Local MCP returns 200 text/plain for OAuth protected-resource discovery paths, breaking tunnel-client v0.0.14 interoperability

Open Beginner friendly
  • Is something wrong?
#1,516 1 comment 1 reaction 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
84/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
csharp
Domain
api

Research direction

Start in src/OpenClaw.Shared/Mcp/McpHttpServer.cs and trace the authenticated GET handling before the generic friendly probe response. Add regression coverage for both OAuth protected-resource well-known paths, preserving 401 responses, the existing friendly GET 200 response, and POST JSON-RPC behavior; done means those authenticated discovery paths return 404.

Written by the indexing model from the issue text.

Description

clawsweeper:needs-maintainer-review clawsweeper:needs-product-decision clawsweeper:no-new-fix-pr clawsweeper:source-repro impact:security issue-rating: 🦞 diamond lobster P2

Summary

OpenClaw Windows Local MCP v2026.9.4 returns the generic authenticated GET probe response for OAuth Protected Resource Metadata discovery paths such as:

/.well-known/oauth-protected-resource/mcp
/.well-known/oauth-protected-resource

That behavior conflicts with openai/tunnel-client v0.0.14 when the OpenClaw Local MCP server does not actually advertise OAuth Protected Resource Metadata.

For an HTTP MCP target with no OAuth metadata, tunnel-client treats HTTP 404 from all PRMD candidates as the normal/optional "OAuth metadata not advertised" case. An authenticated 200 text/plain response instead looks like a metadata endpoint that returned invalid metadata and can keep OAuth discovery/readiness degraded.

This is an interoperability issue at the HTTP endpoint semantics boundary, not a general MCP transport incompatibility.

Environment

  • OpenClaw Windows Companion: v2026.9.4
  • Local MCP: enabled on loopback (127.0.0.1:8765)
  • Local MCP bearer authentication: enabled
  • OpenAI tunnel-client: v0.0.14
  • Windows 11 x64
  • tunnel-client target: OpenClaw Local MCP over loopback HTTP

Both versions were the latest stable releases at the time of reproduction.

OpenClaw behavior

In v2026.9.4, McpHttpServer.HandleAsync performs the bearer-token check before method dispatch and then handles any authenticated GET with the same friendly probe response:

if (ctx.Request.HttpMethod == "GET")
{
    _writeText(ctx.Response, HttpStatusCode.OK,
        $"OpenClaw MCP server. POST JSON-RPC to {Endpoint}", "text/plain");
    return McpRequestResult.Success;
}

Source:

https://github.com/openclaw/openclaw-windows-node/blob/v2026.9.4/src/OpenClaw.Shared/Mcp/McpHttpServer.cs

Therefore a correctly authenticated request to:

GET /.well-known/oauth-protected-resource/mcp

does not return 404 when OpenClaw has no PRMD document for that path; it falls through to the generic 200 text/plain GET probe response.

For completeness, an unauthenticated live probe to those paths correctly returned 401. The incompatibility occurs after valid bearer authentication, as shown by the method ordering above.

tunnel-client behavior

tunnel-client v0.0.14 actively probes OAuth Protected Resource Metadata candidates for HTTP MCP targets.

Its discovery implementation explicitly falls back across HTTP 404 responses, and its doctor path treats "all candidates returned HTTP 404" as the successful optional case:

OAuth metadata not advertised; all candidates returned HTTP 404

Sources:

https://github.com/openai/tunnel-client/blob/v0.0.14/pkg/oauth/discovery.go

https://github.com/openai/tunnel-client/blob/v0.0.14/cmd/client/doctor_command.go

So these two behaviors meet badly:

tunnel-client
  GET /.well-known/oauth-protected-resource/mcp
  Authorization: Bearer <OpenClaw local MCP token>
        |
        v
OpenClaw Local MCP
  auth succeeds
  any GET => 200 text/plain friendly probe
        |
        v
tunnel-client
  received 200 from a metadata candidate
  body is not Protected Resource Metadata JSON
  => discovery cannot be treated as the normal "metadata not advertised" case

Verified workaround

A loopback compatibility adapter was inserted only between tunnel-client and OpenClaw:

tunnel-client -> 127.0.0.1:8767 -> OpenClaw 127.0.0.1:8765

The adapter does only this:

  • /.well-known/oauth-protected-resource* => HTTP 404
  • every other request => proxy unchanged to OpenClaw Local MCP

With that narrow change:

  • tunnel-client /healthz => 200
  • tunnel-client /readyz => 200
  • OpenClaw operator/node state remained Ready / Connected
  • actual ChatGPT -> tunnel-client -> OpenClaw MCP tool calls continued to work
  • no change to OpenClaw JSON-RPC request/response handling was required

This strongly isolates the interoperability problem to the PRMD GET semantics rather than bearer authentication or MCP JSON-RPC transport.

Expected behavior

If OpenClaw Local MCP does not implement OAuth Protected Resource Metadata, requests to the well-known PRMD paths should behave as "not provided", e.g. HTTP 404.

The existing friendly GET probe can remain available for its intended endpoint.

Suggested minimal fix

Prefer a narrow compatibility fix rather than changing Local MCP architecture:

  1. Detect the OAuth Protected Resource Metadata well-known paths before the generic GET probe branch.
  2. Return HTTP 404 for those paths when OpenClaw does not provide PRMD metadata.
  3. Preserve current bearer-token, Origin, Host, concurrency, and JSON-RPC behavior.

For example, conceptually:

if (ctx.Request.HttpMethod == "GET" &&
    IsOAuthProtectedResourceMetadataPath(ctx.Request.Url?.AbsolutePath))
{
    return Reject/NotFound(...);
}

if (ctx.Request.HttpMethod == "GET")
{
    // existing friendly probe
}

A broader "unknown GET paths return 404" change may also be valid, but the well-known-path special case appears lower-risk for existing clients that may rely on the current friendly GET probe.

Regression tests

Suggested cases for McpHttpServer:

  1. Valid bearer + GET /.well-known/oauth-protected-resource => 404
  2. Valid bearer + GET /.well-known/oauth-protected-resource/mcp => 404
  3. Missing/invalid bearer on those paths => preserve current 401 auth behavior
  4. Valid bearer + existing friendly probe GET => preserve 200 text/plain
  5. Existing MCP POST JSON-RPC behavior unchanged

An integration test with tunnel-client is not required to validate the OpenClaw-side fix, but the expected external outcome is that tunnel-client v0.0.14 classifies the two 404s as "OAuth metadata not advertised" and proceeds without the compatibility adapter.

Scope

I am not claiming that OpenClaw or tunnel-client is generally non-compliant with MCP. The observed problem is specifically the interaction between:

  • OpenClaw's path-agnostic authenticated GET probe behavior, and
  • tunnel-client v0.0.14's OAuth PRMD discovery semantics for HTTP MCP targets.
Dominant language
C#
Stars
2.1k
Forks
315
Avg merge
2d 7h
Merged PRs (30d)
135

Getting set up

  • No Dockerfile or Docker Compose file
  • Has a pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from openclaw/openclaw-windows-node

All issues in openclaw/openclaw-windows-node

Similar issues

More C# issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.