OpenRig 0.7.4

OpenRig 0.7.4: a first, experimental step toward every assistant you use working on one team

OpenRig's goal is for all of your assistants to work together on one team: one topology, shared work, organized projects. Assistants that run on your machine can already reach OpenRig's MCP server locally. Many assistants live in a vendor's cloud, and those can only reach a server on the internet. 0.7.4 adds the plumbing for that case. An assistant can join a rig as a hosted member: it takes work from its own inbox, returns results, comes back to the same work later, and loses access when you revoke its grant.

This is experimental and unsupported. It's off by default. Nothing in OpenRig listens on the internet unless you set it up yourself. You serve rig mcp serve --http, put it behind your own TLS tunnel or proxy, and issue a token. Doing that is like opening a port in your firewall. Anyone with the URL and a valid token can act as that member within its grant. Treat the token like a password, give the member the narrowest grant, and revoke it when you're done (rig mcp token revoke <name>). We don't support, and take no responsibility for, an OpenRig reachable from the internet, just as with running OpenRig itself on the open internet. Use at your own risk.

The worked example is Grok. Its app can add a remote MCP server with a bearer token, which made a clear end-to-end test. A real Grok joined a test team, claimed a task, returned a useful note, came back to it in a new conversation, said honestly what it couldn't reach, and was refused after its grant was revoked, with its work kept. Other assistants that can add a remote MCP server should work the same way. We haven't tried them yet.

Also in 0.7.4: resume the exact Claude Code or Codex conversation you choose; support for newer MCP clients; and for advanced remote setups, rig mcp serve --http can check keys with an external grant service and offer OAuth sign-in discovery.

Before you upgrade

npm install -g @openrig/cli@0.7.4
rig daemon stop && rig daemon start

• One database update applies on the daemon's first start: a column recording which grant's caller acted. Startup
  refreshes OpenRig's own plugin (openrig-core 0.1.21: the queue-handoff skill and the Claude hooks changed), first
  copying any file it replaces under $OPENRIG_HOME/backups/managed-refresh/. If you edited one, reapply your change
  from the copy.
• Claude seats get the new rate-limit hook at their next launch, resume, restore or handover. If a Codex seat stops at
  "Hooks need review", review the hooks in Codex.
• A Codex seat that keeps running through the upgrade warns about its hooks. On its next tool turn it shows
  "Hook failed … plugin contents changed; hook approval required", and some of OpenRig's Codex hooks stop running in
  that seat. Codex 0.164's /permissions menu has no hook item. Restart the seat on its own conversation with
  rig seat restart <seat> --keep-conversation --reason "<why>" (preview it with --plan first): the warning goes away
  and OpenRig's hooks run again. A Codex seat started after the upgrade isn't affected. (Tested on Linux with Codex 0.164.)
• Going back to 0.7.3 leaves the new column in place, unread.

What's new

Assistants as team members (experimental)

• A roster entry can mark a member as hosted ("hosted": true): an assistant that lives outside a terminal and reaches
  the team over MCP under a grant for its seat. rig_team lists it with its declared capabilities and caveat, and
  activity unknown, never idle. (#2095)
• The connection teaches the assistant the loop: its inbox, claiming an item, closing it with the answer or handing it
  on, and, when an item needs a person's approval, keeping the item and asking that person, then finishing it after the
  answer. (#2095, #2127)
• When work waits for a member nothing can wake, its person is told, on Steering, the TUI's Feed and Slack. (#2110)
• A hosted member's roster entry can declare a webhook trigger (secret names only): OpenRig rings it with a pointer to
  the row when work lands. A 2xx is recorded as the ring being accepted, not as the member waking; if it doesn't claim
  the work in time, its person is told. (#2115)
• rig_team and rig roster show show when a hosted member last called the team's MCP server, and rig_team its
  latest ring. (#2121)

Remote MCP callers and grants (experimental)

• rig mcp serve --http --grant-service <url> checks each request's key with an external grant service instead of the
  local token file, with nothing cached. (#2096, #2141)
• --oauth-resource and --oauth-issuer add OAuth protected-resource discovery (RFC 9728) and standard challenges for
  MCP clients that sign in with OAuth. The key and its grant still decide what a caller may do. (#2135)
• The rows a granted caller's actions write record whose grant acted: attribution, not authentication. (#2098)
• A caller's seat that was created but never launched is served instead of refused (#2125). A caller granted through a
  grant service hands work to the team it was granted, never to a caller seat (#2132), and can't attach tags that hide
  part of its text from a person asked about it (#2126).

Newer MCP clients

• Clients on MCP protocol revision 2026-07-28, which has no initialize handshake, work with rig mcp serve over stdio
  or --http, beside 2025 clients on the same endpoint. (#2112)

Resuming the conversation you chose

• rig seat history --rig <id> --node-id <id> lists the Claude and Codex conversations that exact node could resume. (#2100; by @bradvin)
• A client can resume the history a person reviewed; it refuses rather than substitute another conversation or start
  fresh. (#2109; by @bradvin, completing the three stages agreed in #1837)

Task views

• rig terminal open and the daemon's terminal preview accept qitem:<id>, the current local owners of that task, as a read-only
  membership view that names stopped, missing and external owners. It doesn't follow the task as it moves. (#2131)

The kernel at daemon start

• Startup brings back a kernel only when this start found it down, which is what a reboot leaves. A kernel already down
  before the start stays down, and rig start and rig daemon start --wait-for-kernel say why and how to bring it back
  (rig up kernel --existing). This fixes 0.7.3's known issue of a long-gone kernel returning. (#2146, #2152, #2156)

Also: a Claude seat stopped by a rate limit is recognised from Claude's StopFailure hook, and a delayed older hook
no longer replaces a seat's current state (#1908, #2113); a fresh Claude handover reports delivery only once the packet
is submitted (#1863); periodic snapshots keep a down agent's resume source (#2123); a resumed Pi seat no longer prints
Entry not found on every restart (#2122); parks on a person's own address resolve only from a later reply, keep their
summary and evidence, and show in NEEDS YOU (#2106, #2107, #2108); the reviews count only open rows as held (#2136); the
TUI starts in a terminal that reports 0 rows or columns (#2099) and lists rigs by name (#2134); identity lookup no
longer prints tmux errors (#2103).

The packaged CHANGELOG.md lists every change.

Behaviour that changed

• A kernel already down before daemon start is no longer restored on that start.
• rig daemon start --wait-for-kernel for a kernel skipped on purpose prints the reason and way back, not a timeout and
  an authentication fix. It still exits 1.
• Work waiting for a member nothing can wake is reported to its person, not to the member.
• A park on a registered person's address resolves only from a Slack reply written after its question.

Known issues

• A webhook ring proves only that the endpoint accepted it. An ordinary chat app can't receive unsolicited events,
  so a hosted assistant without a webhook-capable runner sees work only when it checks.
• The task view is membership only. It doesn't follow a task, keep a reusable viewer or grant input, and an explicit
  open still has the provider's usual workspace effects.
• Resuming a reviewed history has no CLI yet; it's through the daemon's startup review, for clients.
• The kernel's restore evidence lasts one daemon process. If the first daemon after a reboot exits before the
  kernel's restore starts a seat, the next start leaves the kernel down and says so; run rig up kernel --existing.
• An exported team isn't registry-ready by itself. rig export doesn't write a README, and openrig.dev/rigs'
  check fails until one is added and declared in rig.yaml docs. Add it, then run rig bundle check on the folder
  before you submit.
• OpenClaw's interrupted local turns still aren't recovered. Capture the pane before sending; for an unattended
  seat, use the Gateway preset.
• Whether processes a community harness starts outside its pane survive isn't exercised. rig down stops the pane
  only.
• Hermes: the preset doesn't declare resume, and whether a seat's gateway exits once idle is unknown. Check with
  ps before relying on it.
• A Codex seat's permission settings were enforced natively in 0.7.3's test with Codex 0.164.0; other versions
  weren't tested.
• Upgrading doesn't restore Codex hook approvals an earlier OpenRig removed. Approve the hooks you mean to enable.
• A session attached with rig attach --self can send, but replies to it may fail with transport_unavailable.
• After a seat handover, check the successor if OpenRig reports its restore packet unconfirmed. The packet can be
  left typed but not sent in a Claude successor's prompt. In our test, the seat's next ordinary task got it consumed.
• After the last managed session ends, an empty tmux server may remain running.
• Slack threads and messages from before 0.7.3 keep 0.7.3's limits on reply routing and on what a person sees.
• Shared channels are Slack only, the cmux path wasn't tried in a real cmux, and the TUI reads a remote host's rigs
  over HTTP only.
• Not in this release: verified task viewers (#2133), switching a seat to an isolated account home (#2138, #2143),
  source evidence for resolving stuck findings (#2153), the stale-pane repair message (#2157), current launch evidence
  for fresh handovers (#2159), and a warning for out-of-range MCP daemon ports (#2160).

Verification limits

• A real person's own Grok joined a 0.7.4 team over MCP under a revocable grant. It claimed a task, closed it with a
  useful note, came back to the same task, reported what it couldn't reach and when it can't be woken, and was refused
  after its grant was revoked, with its earlier result kept. The person drove Grok in its own app; other assistants
  weren't tried.
• No webhook consumer was shown waking from a ring.
• The notice to a hosted member's person when nothing can wake it wasn't shown with a registered person.
• Resuming the exact conversation was shown on Claude Code and on Codex. With Codex 0.164 on a low-effort model, the
  resumed conversation didn't recall an earlier fact, and the same happened outside OpenRig.
• An MCP 2026-07-28 client (SDK 2.x) was shown at installed scope.

Credits

Thank you to @Aschenbath, @Nikhi00718, @bradvin, @dajiaohuang and @seanmcn, whose work is in this release, and to
@pr0xc3nt4ur1 (#1822), @duncanleung (#2130), @ziadeh (#2129), @alperta (#99), @AdamWhitehurst (#1544),
@smota (discussion #2117) and
@oSquashBlossomo, whose reports and reviews led to fixes here.