fix(claw-server): admit Electron-based MCP clients past the /mcp hygiene filter - #2536
Closed
Dani Akash (DaniAkash) wants to merge 1 commit into
Closed
fix(claw-server): admit Electron-based MCP clients past the /mcp hygiene filter#2536Dani Akash (DaniAkash) wants to merge 1 commit into
Dani Akash (DaniAkash) wants to merge 1 commit into
Conversation
…ene filter The loopback /mcp hygiene filter rejected any request carrying a `Sec-Fetch-*` header. Chromium/Electron-based desktop MCP clients (e.g. Cherry Studio) attach browser-default Fetch Metadata to every outgoing request and cannot strip it, so they were blocked with 403 "unsupported request". `Sec-Fetch-*` presence does not identify a webpage: only `Origin` does. An MCP call is a POST with `application/json`, which is never a CORS simple request, so any page capable of making one always carries `Origin`, which stays rejected. The content-type gate continues to cover the origin-less page vectors. Drop the `Sec-Fetch-*` presence check and keep the `Origin` rejection. Fixes #2458
Contributor
Greptile SummaryThis PR changes the Rust loopback MCP hygiene filter to admit Electron clients that attach Fetch Metadata while retaining Origin and JSON content-type checks.
Confidence Score: 4/5The policy change appears defensible, but the shared MCP transport contract must be updated with it before merging to avoid a failing affected test suite. The Rust middleware now admits a request that the repository’s claw-mcp contract explicitly requires to return 403, creating a deterministic conformance-test failure. Files Needing Attention: packages/browseros-agent/apps/claw-server-rust/src/api/http/mod.rs; packages/browseros-agent/contracts/claw-mcp/tests/cases-transport.ts Important Files Changed
Prompt To Fix All With AI### Issue 1
packages/browseros-agent/apps/claw-server-rust/src/api/http/mod.rs:139
**Transport contract rejects admitted requests**
When the claw-mcp contract suite sends its JSON request with `Sec-Fetch-Site: cross-site` and no `Origin`, this middleware now admits it even though the shared transport contract requires a 403, causing the affected conformance suite to fail.
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.Reviews (1): Last reviewed commit: "fix(claw-server): admit Electron-based M..." | Re-trigger Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
Contributor
Author
|
Closing: the Sec-Fetch-Site rejection here is a deliberate DNS-rebinding/CSRF defense mirrored across both MCP servers and enforced by the shared transport contract, and Electron-based clients are indistinguishable from browser attacks by that header, so this endpoint filter cannot be safely relaxed. |
Dani Akash (DaniAkash)
deleted the
fix/mcp-sec-fetch-electron-clients
branch
September 3, 2026 04:27
Contributor
❌ Tests failed: 13/756 failedRan 3 of 16 suites (13 not affected by this change).
Failed tests
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
The loopback
/mcphygiene filter rejected any request carrying aSec-Fetch-*header (403 {"error":"unsupported request"}). Chromium/Electron-based desktop MCP clients such as Cherry Studio attach browser-default Fetch Metadata to every outgoing request and cannot strip it, so they could not connect at all.This drops the
Sec-Fetch-*presence check and keeps theOriginrejection.Why this is safe
The filter exists to reject requests originating from a webpage, so a page the user visits cannot drive their browser through the loopback MCP endpoint.
Sec-Fetch-*presence does not identify a webpage; onlyOrigindoes:POSTwithContent-Type: application/json. That is never a CORS "simple request", so any webpage capable of making one always sendsOrigin, which stays rejected.application/jsoncontent-type gate continues to cover the origin-less page vectors (navigations, no-cors simple requests), none of which can carry a JSON-RPC body.This restores parity with the previous MCP server, which accepted
Sec-Fetch-*and rejectedOrigin, and which these clients connect to natively.Tests
mcp_hygiene_rejects_browser_originated_requests:Originstill returns403.mcp_hygiene_admits_electron_sec_fetch_clients(new): aninitializePOST carryingSec-Fetch-Site/Mode/Destand noOriginreaches the service and returns200with a session id.mcp_hygiene_rejects_non_json_writes: unchanged.Reported behavior and reproduction in #2458.
Fixes #2458