Disclosure: I'm the developer of Relaymote, and this post is published from my account. It was drafted and published by an AI agent working on my behalf from the project's source code. Relaymote is unofficial; not affiliated with or endorsed by Anthropic.
Relaymote is an open-source (MIT) companion for Claude Code sessions on your PC. It runs a small daemon with a control API on 127.0.0.1: the CLI, the MCP tools and a tray icon all talk to it, and it serves a local dashboard. Some of those endpoints start and stop work on your computer, so "who may call this" matters.
The usual answer is "it only listens on loopback, so only this machine can reach it". That is true, and it is not the whole threat model. This post is the 38-line guard that closes the rest.
Binding to 127.0.0.1 keeps other machines out. It does not keep out a web page running in your own browser on this machine. Two ways that goes wrong:
POST http://127.0.0.1:<port>/api/task with a form or fetch(..., {mode: 'no-cors'}). The page cannot read the response, but it does not need to: the request already did its work.127.0.0.1 after the page loads. The browser now treats http://evil.example:<port> as same-origin with the page, and the page can send requests Host header, which says evil.example:<port>.
CORS does not help with either. CORS controls who may read a response; it does not stop a simple POST from arriving, and under rebinding the browser thinks there is no cross-origin request at all.
The fix starts with noticing that the real callers are easy to describe:
Origin headerlocalhost or [::1].
Everything else is someone else.
const LOOPBACK = ['127.0.0.1', 'localhost', '[::1]'];
function allowedHost(value, port) {
const v = String(value || '').trim().toLowerCase();
return LOOPBACK.some(h => v === `${h}:${port}`);
}
/** Returns null when the request may proceed, or { status, body } to refuse it. */
function check(req, port) {
const h = req.headers || {};
if (h.host !== undefined && !allowedHost(h.host, port)) {
return { status: 403, body: { ok: false, error: 'BAD_HOST' } };
}
const safe = req.method === 'GET' || req.method === 'HEAD' || req.method === 'OPTIONS';
if (safe) return null;
if (String(h['sec-fetch-site'] || '').toLowerCase() === 'cross-site') {
return { status: 403, body: { ok: false, error: 'CROSS_ORIGIN' } };
}
if (h.origin !== undefined) {
let ok = false;
try { const o = new URL(String(h.origin)); ok = o.protocol === 'http:' && allowedHost(o.host, port); } catch {}
if (!ok) return { status: 403, body: { ok: false, error: 'CROSS_ORIGIN' } };
}
return null;
}
It runs first in the request handler, before any routing:
const refused = require('./lib/control-guard').check(req, PORT);
if (refused) return json(res, refused.status, refused.body);
Three rules, in order:
GET too: a rebinding page reading /api/state is a leak even if it changes nothing. The comparison is exact (localhost:<port>, not "contains localhost"), so localhost.evil.example does not pass.HEAD and OPTIONS change nothing, and the dashboard loads with them.Sec-Fetch-Site: cross-site is refused outright. If an http: on a loopback host and this port. A missing The test suite checks the cases that are easy to get wrong:
G('POST', { host: `127.0.0.1:${PORT}` }) // CLI / MCP: passes
G('POST', { host: `127.0.0.1:${PORT}`, origin: `http://127.0.0.1:${PORT}` }) // dashboard: passes
G('POST', { host: `127.0.0.1:${PORT}`, origin: 'https://evil.example' }) // CROSS_ORIGIN
G('POST', { host: `127.0.0.1:${PORT}`, origin: 'null' }) // CROSS_ORIGIN
G('GET', { host: `evil.example:${PORT}` }) // BAD_HOST, even for GET
G('POST', { host: `localhost:${PORT}`, 'sec-fetch-site': 'cross-site' }) // CROSS_ORIGIN
Origin: null deserves a note. Sandboxed iframes, file:// pages and some redirects send the literal string null. It is not "no origin"; it is a browser telling you it will not say. new URL('null') throws, ok stays false, and the request is refused.
The dashboard response is sent with X-Frame-Options: DENY (so another page cannot frame it and trick clicks onto its buttons) and Cache-Control: no-store. Neither replaces the guard; both are one header each.
It is not authentication. Any program already running as you on the same machine can call the API, exactly as it could read your files. The guard's job is narrower: a web page should not get the powers of a local program just because the browser happens to run on that machine. For a localhost API, that narrow job is the one most often skipped.
If you ship a local daemon with an HTTP control port (dev servers, desktop helpers, editor plugins), the checklist is short: exact loopback Host on every request, refuse Sec-Fetch-Site: cross-site on writes, and allow only your own loopback Origin or none.
Relaymote is on GitHub under the MIT licence. Unofficial; not affiliated with or endorsed by Anthropic.