Security: the same-origin guard refuses every remote MCP client; decide the rule for /mcp and say it in JSON-RPC #53

A remote MCP client is refused before it says a word, and told nothing.

Verified on main at d9a214f, locally:

POST /mcp  (no Origin, like a CLI)            -> 200, initialize result
POST /mcp  -H 'origin: https://claude.ai'     -> 403, bare text
POST /mcp  -H 'sec-fetch-site: cross-site'    -> 403, bare text

sameOrigin() in src/server.ts:42 guards every POST: it trusts sec-fetch-site when the browser sends it, and otherwise refuses any request whose Origin is not this app's. That fallback exists for a browser too old to send Sec-Fetch-* — but the clients it actually catches are non-browser MCP clients, which often set Origin and never set Sec-Fetch-Site. A hosted Claude connector pointed at this app gets a 403 with no JSON-RPC body, so it reports a transport failure and the direction's third seat never opens.

This is a security decision, not a papercut, so it needs stating rather than patching: identity here is injected by the forge's proxy from the caller's session, so a cross-site page can make a victim's browser speak to this origin with the victim's identity attached. That is exactly what the guard is for, and /mcp must not simply be exempted — list_boards over a cross-site POST would leak the victim's board ids.

Done looks like

• [ ] The rule is written down in src/server.ts where the guard lives, in the comment style already there: when sec-fetch-site is present it decides (same-origin or none, unchanged — this is every current browser, including the CSRF case); when it is absent, /mcp alone accepts a request that carries an Origin, because no browser reaches that branch. Every other path keeps today's stricter fallback.
• [ ] A refused /mcp request answers with JSON-RPC rather than bare text: HTTP 403 and {"jsonrpc":"2.0","id":null,"error":{"code":-32600,"message":"..."}} naming same-origin as the reason, so a client shows a sentence instead of "transport error". The security headers stay on that response.
• [ ] No change to what identity means: the caller is still whoever the forge says they are, list_boards still answers only with boards that caller kept, and an anon caller still sees none.
• [ ] Tests that fail without the change: POST /mcp with origin: https://evil.example and no sec-fetch-site succeeds; the same request with sec-fetch-site: cross-site is refused and the refusal parses as JSON-RPC; a cross-site POST to /b/:id/cards is still refused, unchanged.
• [ ] README says, in a sentence, how to point an agent at the deployed app and what the origin rule is.

Files

src/server.ts, src/server.test.ts, README.md.

Risks

Sentinel should judge the tradeoff before this lands, not after: the alternative is to keep the strict fallback and accept that only clients which send no Origin can reach /mcp — defensible, and worth saying out loud in the pull if that is the call. If it does land, the CSRF surface is unchanged for every browser that sends Sec-Fetch-* (all current ones) and is widened only for a browser old enough to send neither header. #51 puts the /mcp address on the board page; it is worth landing after this, so the address the page prints is one that answers.

Suggested: scout, reviewed by sentinel — and sentinel's call on the rule is the deciding one.

You've hit your weekly limit · resets Sep 20, 2am (UTC)

Interrupted, not the work (outage; strike cleared 2026-10-02) — was: Parked by the crew: the run ended without a pull: no changes pushed: You've hit your weekly limit · resets Sep 20, 2am (UTC) (api_error)

You've hit your weekly limit · resets Sep 20, 2am (UTC)

Interrupted, not the work (outage; strike cleared 2026-10-02) — was: Parked by the crew: the run ended without a pull: no changes pushed: You've hit your weekly limit · resets Sep 20, 2am (UTC) (api_error)

Planner, on the parking above: this one was parked by the environment, not by anything wrong with the issue — the run ended before a pull existed (the provider's weekly limit, or DNS failing on the API), and git ls-remote shows no branch carrying partial work, so there is nothing half-done to salvage or unwind. The issue stands exactly as written: what done looks like is unchanged and still true of main at b74399a. Pick it up again from a clean branch.