Wormkey 0.4 — built for agents, safer for everyone
Today Wormkey became more than a command that opens a public URL. It became a proper handoff layer for unfinished software.
Wormkey started with one promise: run one command, get one public link, share what is running on your machine. That part is still the center of the product. But the way software gets built is changing. More of it is being written, tested, and reviewed by agents that need stable output instead of decorated terminal text.
So this release does two things at once: it makes the tunnel safer for people, and much easier for agents to operate.
The security work came first
The control plane now has three clear boundaries. Public routes only return safe tunnel status. Owner routes require the owner bearer token. Gateway synchronization uses a separate internal service key.
Session IDs, slugs, and credentials now use cryptographically secure randomness. Owner and tunnel tokens are stored as hashes. The gateway validates a session before completing its WebSocket upgrade.
Request forwarding is stricter too. Wormkey now limits request bodies and pending streams, strips unsafe forwarding headers, adds timeouts, and cancels the localhost request when the viewer disconnects.
The CLI can finally speak machine
Agents should not need to scrape QR codes or guess whether a sentence means success. The new JSON mode writes one stable object to stdout while status messages stay on stderr.
wormkey http 3000 --json --no-interactive{
"session_id": "sess_123",
"url": "https://quiet-lime-k7m4.wormkey.run",
"expires_at": "2026-07-25T21:00:00Z",
"status": "connected"
}Wormkey can also wait for your application before exposing it:
wormkey http 3000 --wait-for /health --timeout 60sOr manage the application and tunnel as one process:
wormkey run --port 3000 -- npm run devA tunnel you can inspect
Run wormkey http 3000 --inspect and Wormkey records request metadata locally: method, path, status, duration, request bytes, response bytes, and request ID.
wormkey logs --json
wormkey inspect req_123
wormkey replay req_123That makes Wormkey useful for webhook work, API debugging, and agent loops where a failed request should become the next piece of context.
Remote controls and MCP
Sessions now live in a secure multi-tunnel state file. You can list them, inspect them, and close one remotely even if the original terminal is gone.
wormkey list
wormkey status quiet-lime-k7m4
wormkey close quiet-lime-k7m4The new wormkey-mcp package exposes tools for starting, reading, listing, closing, inspecting, replaying, and waiting on tunnels. Coding agents can now use Wormkey without pretending to be a person at a terminal.
What Wormkey is becoming
Deployment assumes software is ready to live somewhere. Wormkey assumes software is still being made, but needs to become briefly reachable, inspectable, and collaborative.
That is the category we are building toward: the handoff layer between local execution and external intelligence.