Independent AI intelligence Two editions daily · ET
Fervor AI
Menu

Analysis · October 2, 2026 · repo

OpenRigmvschwarz/openrigmulti-agentagent-securityclaude-codecodex

OpenRig v0.6.4 Turned Off Its Own Web UI. Audit Your Other Agent Daemons Next.

The multi-agent harness for Claude Code and Codex now treats the browser as a threat. Most local agent tools on your laptop do not, and checking takes ten minutes.

A tool that runs teams of coding agents just shipped a release whose biggest feature is that a feature is gone. OpenRig v0.6.4, released October 2, turns its web UI off by default. The daemon "no longer serves the web UI's pages or its terminal connection unless you turn it on."

Projects rarely remove the most visual part of themselves in a point release. When one does, the reason usually lives outside the changelog.

The second change explains the first. The daemon now "checks which address and which web page a request comes from." In browser-security terms, that is a Host check and an Origin check. And the release notes are candid about the limit: this "isn't complete browser isolation, so keep the daemon on loopback or your tailnet."

That one sentence is a better security model than most local agent tooling ships with. It also undercuts the assumption that anything bound to localhost is private.

What OpenRig is, and why its daemon matters

mvschwarz/openrig describes itself with a neat line: "A harness wraps a model. A rig wraps your harnesses." You define an agent team in YAML, a RigSpec, and boot it with one command. Under the hood, a local HTTP daemon built on Hono manages SQLite state, tmux sessions, and runtime adapters for Claude Code and Codex. You message agents across the team with rig send.

It is Apache 2.0, sits around 4.2k stars on a cache-busted shields.io read, needs Node 22 or 24 plus tmux, and runs on macOS or Linux. It was #24 on Trendshift's momentum board this afternoon.

Here is the detail that turns a UI change into a security story. During setup, OpenRig writes trust settings and hooks into provider config, with ~/.claude.json and .claude/settings.local.json for Claude Code and ~/.codex/config.toml for Codex, and the README advises backing up first. The setup flow asks: "Allow your agents to run OpenRig commands without repeated permission prompts?" YOLO mode is off by default, and the permission modes are named floor, full_bypass, and inherit.

So the daemon is not a dashboard. It is a control plane that can deliver messages into running agent sessions that, depending on your choices, have been told to trust it.

Why localhost is not a wall

The browser is the part people forget. Any web page you open can make requests to 127.0.0.1. The same-origin policy limits what that page can read back, but it does not stop many requests from arriving. With DNS rebinding, an attacker's domain can briefly resolve to your loopback address, and the browser then treats your local daemon as same-origin with the attacker's page.

This is not theoretical hand-waving. The Model Context Protocol spec writes it into its transport rules. Streamable HTTP servers "MUST validate the Origin header on all incoming connections to prevent DNS rebinding attacks," "SHOULD bind only to localhost (127.0.0.1) rather than all network interfaces," and "SHOULD implement proper authentication for all connections." The spec's own summary: "Without these protections, attackers could use DNS rebinding to interact with local MCP servers from remote websites." (MCP transports, 2025-11-25)

OpenRig v0.6.4 does the first of those things for its own daemon. Host checks catch the rebinding trick, because a rebound request still carries the attacker's host name. Origin checks catch a random page trying to talk to your daemon directly. Turning the web UI off removes the terminal connection from the default attack surface entirely.

My position: this release is the right call, and it should embarrass the rest of us a little. A daemon that can type into agent sessions deserves the same scrutiny as an SSH key. I would bet most of the local agent servers on a typical builder's laptop have never been checked for any of this.

What changed, specifically

From the v0.6.4 release notes:

  • Web UI off by default. To turn it back on, run rig config set ui.enabled true and restart the daemon. With it off, the page shows setup instructions, and rig ui open prints them. The UI is now in maintenance mode; the CLI and TUI are the officially supported interfaces.
  • Host allowlist. If you reach the daemon through a custom DNS name or a proxy, add that name to OPENRIG_ALLOWED_HOSTS.
  • Origin allowlist. If a browser page on another origin needs to call the daemon, add it to OPENRIG_ALLOWED_ORIGINS.
  • Clear rejections. The notes say each rejected request names the setting to change, and both settings take effect after you stop and start the daemon.
  • Unchanged paths. The CLI, the TUI, agents, the queue, Slack, and other OpenRig hosts that reach the machine by IP address, its own hostname, or its Tailscale name keep working.

The same day also carried a release candidate, v0.6.4-rc.1, a couple of hours earlier, so the change moved from candidate to normal release within one morning.

Put this into practice

If you run OpenRig, upgrade first:

npm install -g @openrig/cli

Then leave the UI off unless you use it daily. If you do turn it on, keep the daemon on loopback or your tailnet, exactly as the release notes say, and resist adding broad entries to OPENRIG_ALLOWED_ORIGINS just to silence an error.

The bigger win is applying the same audit to everything else. This takes about ten minutes.

1. List every local listener. On macOS or Linux:

lsof -iTCP -sTCP:LISTEN -n -P

Look for agent harnesses, MCP servers, model gateways, local inference servers, and browser-automation bridges. Note anything bound to 0.0.0.0 or * rather than 127.0.0.1. Those are reachable from your network, not only your browser.

2. Probe each agent-facing port with a hostile Origin and Host. Replace PORT and pick a path the service actually answers:

curl -i -H "Origin: https://not-you.example" http://127.0.0.1:PORT/
curl -i -H "Host: not-you.example" http://127.0.0.1:PORT/

A well-behaved service rejects one or both (MCP servers should return 403 on a bad Origin). A 200 with real data means any web page you visit may be able to reach it.

3. Check what the service can do, not only what it shows. A read-only status page is a low-stakes leak. A daemon that can send messages to agents, start sessions, or run commands is a high-stakes one. Rank your findings by capability.

4. Review what your harness trusts. Open ~/.claude.json, your project's .claude/settings.local.json, and ~/.codex/config.toml, and read the hooks and MCP entries. Every tool that wrote itself in there at setup is part of your agent's trust boundary now, whether you remember approving it or not.

5. Prefer tools that ship off-by-default UIs. When two harnesses do the same job, the one that makes you opt in to a browser surface is the one that thought about this.

Honest limitations

A fair read of this release has edges, and some of them are big.

  • No vulnerability was disclosed. The release notes do not name an advisory, a CVE, or an exploit against earlier OpenRig versions. I am describing a hardening change and the class of attack it addresses, not a confirmed hole.
  • The notes read for this piece do not describe daemon authentication. Host and Origin checks stop browsers. They do nothing against other software already running on your machine as your user. If local malware is in your threat model, a localhost daemon without a token is still exposed.
  • A tailnet is a network. Keeping the daemon "on your tailnet" means every device on that tailnet can reach it. That is fine for a personal tailnet and worth a second look on a shared one.
  • Allowlists drift. The friendlier the error message, the easier it is to paste in an origin to make it go away. Review those two environment variables the way you would review firewall rules.
  • Fast-moving project. OpenRig shipped v0.6.3 on September 30 and v0.6.4 two days later. Pin versions in anything you depend on, and reread release notes when you upgrade.

The broader lesson

The agent ecosystem spent a year adding local servers: MCP servers, gateways, harness daemons, browser bridges. Each one is a small web service on your laptop, and each one was usually built by people focused on what the agent can do, not on who else can ask it to do things.

OpenRig's maintainers looked at their own daemon and decided the browser should not get a vote by default. That is the right instinct, and it costs nothing to copy.

Run the lsof command tonight. Whatever answers a stranger's Origin header is your next fix.

Sources: OpenRig v0.6.4 release notes; OpenRig README; MCP specification, transports (2025-11-25).

Medium metadata

  • Title: OpenRig v0.6.4 Turned Off Its Own Web UI. Audit Your Other Agent Daemons Next.
  • Subtitle: The multi-agent harness for Claude Code and Codex now treats the browser as a threat. Most local agent tools on your laptop do not, and checking takes ten minutes.
  • Tags: AI Agents, Cybersecurity, Claude Code, Open Source, Developer Tools
  • Canonical: import from the fervorai.dev URL