Skip to content

OpenRig v0.5.0 — Mission control TUI + context library + permission guarantee + provider usage

Choose a tag to compare

View all tags
@mvschwarz mvschwarz released this 07 Aug 16:14
· 1656 commits to main since this release
v0.5.0
20991e3

OpenRig v0.5.0

UI posture (unchanged from v0.4.7): the web UI is in maintenance mode — still ships, still runs, no new feature work. CLI/TUI is the primary surface. v0.5.0 lands the TUI (rig / rig tui) as the new mission-control home.

Summary — Mission control in the terminal + context library + permission policies + provider usage + honest CLI

Mission control in the terminal. Typing rig (or rig tui) opens the new TUI: file-tree navigator, dense agent detail (working directory, runtime, context %), a topology graph with the whole fleet on one screen, honest status/activity language, motion design, working scrolling, and honest width-clip indicators throughout.

v0.5.0 includes everything from v0.4.8. There is no divergence between the two releases — the v0.4.8 permission-posture work and shipped skills are all present in v0.5.0.

Migrations are additive only. Existing v0.4.8 databases upgrade by running rig daemon start on the new daemon.

What Shipped

Permission-policy built-ins + agent-driven translation

Building on the v0.4.8 permission-policy foundation, v0.5.0 ships the built-in policy templates plus the agent-driven skill that translates them into the target harness's live config.

  • Four built-in policy templates — locked, standard, open, yolo. Read-only from the package; copy to customize. Plus none as a deliberate no-policy choice.
  • rig setup --policy <name> — records the chosen policy into a rig spec. Takes a built-in name (locked | standard | open | yolo | none) or a path to a custom policy file (custom policies live as .policy.md files you author).
  • applying-a-permission-policy — bundled skill for the translation. At rig setup / preflight, the skill reads the policy spec, checks the seat's current harness version, shows the concrete diff before writing, and lands the config into Claude ~/.claude/settings.json and/or Codex config.toml. Never blind writes. The translation is agent-driven on purpose — harness permission formats change frequently across versions, so a deterministic writer would break the moment the harness surface shifts.
  • Two surfaces — the launch-flag surface (Claude --permission-mode, Codex sandbox/bypass, Pi --approve / --no-approve) is stable and OpenRig-set for you: the floor (Claude acceptEdits, Codex workspace-write) and the full-bypass YOLO mode. The config-file surface (Claude ~/.claude/settings.json, Codex config.toml) is where the allow/ask/deny rules live and where the skill applies your chosen policy.
  • What's deterministic vs best-effort — the launch-flag floor and YOLO are deterministic. Fine-grained config-file rules are best-effort because harness rule grammars vary; the skill surfaces the caveats to you (prefix collisions, target-first leaks, Claude's lack of a native network gate) via the diff-before-write flow. If a translation is uncertain, you can always fall back to hand-editing the harness's own settings file, or to YOLO / floor as blunt instruments.

Permission-writer guarantee, now test-pinned

v0.5.0 upholds the v0.4.8 promise — OpenRig never writes permission entries into your Claude settings.json — and pins it with a permanent guard test plus an empty-writer sweep. The one sanctioned exception is the project-local acceptEdits floor that v0.4.8 itself defines. Warning-ordering during permission-policy discovery is cleaner (pre-existing main-floor warnings first, then policy-attachment warnings); presentation-only, semantic fence unchanged.

Context library

rig context stores and composes context; rig walk delivers it paced; --context / --body-context attach a stored context (by reference) to rig send / rig broadcast / rig queue create. Grammar is strict: nouns store and compose (rig context never delivers on its own); verbs deliver (rig send, rig broadcast, rig walk, or rig queue create via --context / --body-context). The old context-window usage viewer from v0.4.x is removed; the rig context name now belongs to the library.

Behavior change (v0.4.8 → v0.5.0)

rig.yaml startup context_pack entries are no longer delivered at rig instantiation. They are rejected with a teaching error pointing you at rig context compose + a delivery command. Users who adopted context_pack in a rig.yaml on v0.4.8 (shipped days ago; small window) should compose the pack via rig context compose and then deliver it with a delivery command — rig send --context, rig broadcast --context, rig walk, or --context / --body-context on rig queue create. The bundle router still stores the pack; it just doesn't auto-deliver it at startup.

Provider usage observability

The daemon tracks account-level usage per host — the "am I about to hit a usage limit" question — exposed via GET /api/provider/usage and rig provider status. Explicit-unknown when the provider doesn't report it; conflict-shows-both-facts when signals disagree. Codex account-switch flows are preserved.

Plan amendment done right

rig scope slice approve --re-approve --reason "..." re-stamps a locked plan with an append-only audit trail — replacing an earlier workaround where an already-approved status forced a Status-note edit.

Honest CLI output

  • rig ps says when it is showing one rig of many, rather than silently limiting.
  • rig send --json returns structured errors as {fact, consequence, action}.
  • Activity-hook fix ends the fleet-wide "producer link stale" advisories that were firing on every send. Operator-facing quality improvement.

Build discipline

Contributor gates and lanes have a single source of truth at docs/reference/developing.md.

UI status (unchanged from v0.4.7)

The web UI stays in maintenance mode as introduced in v0.4.7 — still ships, still runs, no new feature work. CLI/TUI is the primary surface, and v0.5.0's TUI (rig / rig tui) is where mission-control investment lands going forward. The UI is not deprecated and not removed; existing deployments continue to work.

Bundled skills

Two new bundled skills join the shipped set alongside the v0.4.8 skills:

  • applying-a-permission-policy — agent-driven translation for permission policies (see the Permission-policy section above).
  • delegating-work — distribution guidance for every seat.

The openrig-user skill is updated with the v0.5.0 context-library grammar (rig context compose, rig walk, --context / --body-context).

Known Issues

  • Codex HOME fix not landed in v0.5.0 — a permission-posture fix that ensures the daemon and Codex seats agree on the HOME environment (so the posture writes reach the seat) was accepted for v0.5.0 but was inadvertently omitted from the shipped build. It ships as an early bug-fix in v0.5.1. In the meantime, the v0.4.8 deployment note applies: the daemon's HOME must equal the seat's tmux HOME for the permission-posture writes to reach Codex seats — verify this on any remote-host upgrade.

Upgrade Notes

  • Migrations are additive-only; run rig daemon start on the new daemon.
  • Any rig.yaml still declaring a startup context_pack will see the teaching-error rejection above; migrate to rig context compose + a delivery command.
Assets 2
Loading