---
title: "Tunnel Register Anon"
method: POST
path: "/tunnel/register-anon"
---

# Tunnel Register Anon

`POST /tunnel/register-anon`

## Request

- Base URL: `https://api.local-mcp.com` (the document declares no server; this is the origin it was published from)
- URL: `https://api.local-mcp.com/tunnel/register-anon`
- Auth: none declared

Issue an anonymous tunnel token keyed on machine_id.

F-18 (2026-08-07): this used to return the EXISTING token when the machine already had
one — no auth, and not even filtered by `email IS NULL`, so it handed out the tokens of
registered users too. A machine_id is not a secret (lmcp_state returns it to the model),
so that branch was a credential-harvesting endpoint: anyone who knew a machine_id could
read out its live token. Since #2109 this RE-EMITS a fresh token instead of 409ing (see
the comment below); F-18's invariant survives that change because it was never about
refusing the request, only about never ECHOING the existing one. A second token can't
hijack the first: `_forward_to_tunnel` routes strictly by TOKEN
(`active_tunnels[token]`), never by machine_id — if that ever grows a machine_id
fallback, this analysis is invalid and needs re-review (#2129).

Cost, accepted knowingly: reinstalling after losing config.json no longer recovers the
relay here. There is no recovery path for anon installs until the Keychain key (F-03/F-04)
lands — with an email there is one (see /tunnel/token).

## Request body

- TunnelAnonRegisterRequest
  - `machine_id` string

## Response `200`

Successful Response

- unknown

## Other responses

- `422`: Validation Error

---

[API](https://skmtc.dev/local-mcp/apis/lmcp-api.md) · [All operations](https://skmtc.dev/local-mcp/apis/lmcp-api/llms.txt) · [OpenAPI document](https://skmtc.dev/local-mcp/apis/lmcp-api/revisions/f1f1c502623a?raw)