Ruflo 3.63.4 requires a token for local HTTP MCP and pins federation peer keys

What Ruflo is

Ruflo is an agent harness for Claude Code, Codex and other hosts. It coordinates agents, keeps project memory and exposes its tools through an MCP server. Each release publishes @claude-flow/cli, claude-flow and ruflo together.

What changed

Ruflo shipped many releases between 3.57.0 and these two. This story covers only the October 26 security pair. Version 3.63.3 (16:21Z) carries fixes from a private report; 3.63.4 (19:49Z) follows up on them. The release notes describe these changes.

• Breaking: mcp start -t http or -t websocket with no token now uses a per-user token stored in ~/.claude-flow/mcp-http-token (mode 0600, created on first use), so a loopback server is no longer open to every local process. The WebSocket transport checks the token on upgrade, as Authorization: Bearer or ?token=. Clients must send it. RUFLO_MCP_ALLOW_UNAUTHENTICATED_HTTP=1 restores token-less mode (PR #4516).
• Token-less transports refuse requests from a web page whose Origin is not listed by exact name (a * does not count), refuse a non-loopback Host, and will not listen beyond loopback without a token (@claude-flow/mcp 3.1.3, PR #4510).
• Breaking: federation VERIFIED and ATTESTED trust now require the peer's key to be pinned in the trustedPeerKeys config. A self-signed manifest only proves possession of the key it carries. The listener defaults to 127.0.0.1 and nonces use crypto randomness (PR #4514).
• A cloned project's config can no longer enable AI workers. daemon.aiWorkers.enabled is honoured only from --headless, RUFLO_DAEMON_AI_WORKERS=1 or ~/.claude-flow/config.json; a project file can only say false. The audit worker no longer globs .env files (PR #4509).
• A file dropped in .claude-flow/daemon-queue/ no longer counts as a manual trigger, and a .. in an AgentBBS room label can no longer move the room log outside its base path.

npm lists ruflo 3.63.4 as latest, published at 19:48Z on October 26, alongside standalone @claude-flow/mcp 3.1.4.

Get started

Prerequisites: Node 20 or later. The first command only asks the registry for the version and should print 3.63.4. If you run Ruflo's MCP server over stdio, as most hosts do, these transport changes do not apply. If you run it over HTTP or WebSocket, the next start creates the token file, and every client must send that token. If you used a project file to enable AI workers, move the setting to ~/.claude-flow/config.json.

Documentation verified only. We read the release notes, merged PRs and registry records, but did not install the package or run these commands.

npm view ruflo@3.63.4 version

npx ruflo@3.63.4 doctor --json

MCP: for HTTP clients, send Authorization: Bearer followed by the contents of ~/.claude-flow/mcp-http-token; WebSocket clients may also use ?token=. For federation, add each peer as node id to hex public key under trustedPeerKeys before expecting VERIFIED trust. Skills: no new npx skills command is documented in these releases.

Use it today

Input: a developer machine that runs a local HTTP MCP bridge for a browser-based or custom client. Workflow: upgrade, let the server create the per-user token, and configure only your own client with it. Output: other local processes and web pages can no longer call your tools without the token.

Acceptance: after upgrading, a request to the HTTP transport without the token is refused, and the same request with Authorization: Bearer and the token file contents succeeds.

Experimental commentary — acceptance test

One idea is a small team federation where each machine pins its colleagues' keys from a reviewed file in a shared repository. Limitation: the notes say self-asserted trust no longer counts, so key distribution and rotation become an operator task, and 3.63.3 listed further open federation items that 3.63.4 then addressed only in part. Falsifiable test: two nodes that pin each other reach VERIFIED trust, and a third node presenting a valid self-signed manifest but no pinned key does not. We have not run this.

Limits and verification

• Behavior is taken from the release notes and merged PRs. Nothing was run.
• 3.63.2 also notes open SSRF items in http_fetch (::, multicast, NAT64 and redirect re-validation). Those are not claimed as fixed here.
• Releases 3.58.0 to 3.63.2 are not covered by this story and remain unreviewed as news.
• No performance or benchmark claim is made.