The README and docs/reference/getting-started.md describe the installer's real step-4 outcome: when the CLI installs but setup doesn't finish, it prints "INSTALLED, SETUP NOT COMPLETE (exit N)" and points to setup's own details and Fix. The "FAILED [n/4]" form is described for steps 1 to 3 only. Reported in #2538. Contributed by @dajiaohuang.
The install pins on main move from `v0.7.4` to `v0.7.5`, now that 0.7.5 is published: the README's `skills add` lines, its install-script lines and the sentence naming the release, plus the same install-script lines in `docs/reference/getting-started.md` and the example tag in `docs/reference/quickstart.md`. `docs/reference/whats-new.md` stays at main's note, because it names `packages/cli`'s version. Text only.
The README, getting-started and quickstart now install and add skills from the current release, v0.7.4, instead of v0.7.3. docs/releases/README.md says it holds the per-release notes for v0.1.12 through v0.6.3 plus v0.6.12, points to CHANGELOG.md and GitHub Releases for later ones, and its release steps match how releases are published now. Shipped skills and the kernel culture no longer route to a skill that isn't shipped: rig-lifecycle points to rig context get help, the kernel culture's restart case points to getting-started's "Incomplete setup and restart", and the dead sibling entries are dropped. Both skill copies stay identical and their digests are updated.
12 files, +28 -56: docs, skill text and the digest file only; no code change.
Main's documentation catches up with the accepted 0.7.4 candidate's release text, and its install pins point at the latest published release. The CHANGELOG gains the 0.7.4 section and the capability map its 0.7.4 teaching, both identical to the candidate's; getting-started's reboot troubleshooting row now says a kernel that was already down before the reboot stays down and names rig up kernel --existing, while main's newer rig start --last text stays. README, getting-started and quickstart install pins move from v0.7.0 to v0.7.3, the latest published release; the move to v0.7.4 follows at publication. whats-new stays at main's 0.7.1 note, because the packaged note must name the CLI package's version, and package versions, the lockfile and the packaged-plugin fixture are unchanged.
5 files, +383 -14 (docs only). No behaviour, flag or check changes.
The 0.7.0 release boundary's docs on main:
- the packaged capability map (onboarding-width/public-what-you-can-do.md) now carries 0.7.0's capability delta, so an agent reading it after install learns what it can do now, under the header marker capability-delta-v0.7.0;
- the CHANGELOG marks 0.7.0 published;
- the README's skill install (npx skills add ... /tree/v0.7.0/skills/rigs) and install script links (raw .../v0.7.0/scripts/install.sh) point at v0.7.0 instead of v0.6.12.
Fact-only: each line matches the published v0.7.0. Cost: +74/-10 docs, no code.
Adding or freshly launching a managed Claude seat rewrote the worktree's own `.claude/settings.local.json` permission mode to `acceptEdits`, overwriting a person's `auto` or `denyAll` (#1774). The shared Claude settings fragment carried that value, and its scalar won the merge. A managed session never needed it, because every launch passes its own mode flag, which outranks local settings.
Now the fragment no longer carries `defaultMode`, so a person's mode and rules are left as they were. Because the daemon's Claude permission check used that file as the session's mode, configuration now follows launch-mode precedence and keeps the file's default in the detail. A seat with no mode in the file, or with `auto` or `denyAll`, reads aligned. Native enforcement stays explicitly unverified, and the CLI front door allows only that observation gap when the configuration is a valid launch mode; unreadable, invalid or conflicting settings still keep the TUI closed. The printed Claude resume command now carries the selected mode flag, as the Codex one does.
Files already rewritten by earlier versions aren't repaired; set the intended default back once by hand. Manual Claude starts in a worktree now use the person's own default.
Cost: source +24/-13 plus the fragment's -3, tests +73/-55, README +4/-3. No new setting, refusal or error code.
Two fixes from first-user runs.
- **Node.js on a standard-user Mac:** the quickstart's "What you need" now gives the nvm route with its commands (`touch ~/.zshrc`, nvm v0.40.8's install line, a new terminal, then `nvm install 22`), with no administrator password for nvm itself, and says to run `xcode-select --install` if nvm's installer asks for Apple's command line tools. The README and getting-started name the same command.
- **Shell blocks that paste cleanly:** a trailing `# …` note in a shell block becomes arguments to the command in a Mac's default zsh, so those notes in the quickstart and README now sit in the sentence before their block.
- **No sandbox-only paths for the person:** the rigs skill (both copies) says that a file or command given to the person for their own terminal uses a path that exists on their side; a file a sandboxed agent writes under `/tmp` may not.
Onboarding docs: let your coding agent set OpenRig up, and say plainly what installing changes.
- **New `docs/reference/quickstart.md`:** the human getting-started page, with a short glossary of the first words a person meets.
- **`docs/reference/getting-started.md`:** a new title and opening for the agent doing the setup; the rest of the page, and every inbound link and `rig context get` lookup into it, is unchanged.
- **README:** the skill-first install block opens "Install and first run", followed by "Install it yourself"; a short box says what installing and starting change on the machine; the Getting started links point to the new page, and Key Concepts links to the glossary.
- **Facts kept current:** the example tags and version sample now match the v0.6.12 install pin.
- **`scripts/check-first-run-references.mjs`:** the first-run references check now also covers the new page.
Docs only; no product behaviour changes.
Development main now carries the published 0.6.12's versions and release text.
- **Versions:** root, `packages/cli`, `packages/daemon` and `packages/ui` read 0.6.12, and the lockfile matches; `packages/tui` stays 0.1.0.
- **Release text:** the 0.6.12 CHANGELOG section and whats-new entry as published, and `docs/releases/v0.6.12.md`, the published release notes byte for byte.
- **Capability map:** 0.6.12's additions (for example `rig seat set-effort` and `rig usage cost`) alongside main's later entries (`rig seat set-cwd`, the adopted-seat restart note, Pi effort and `rig usage top`).
- **Installer pins:** the README and getting-started now name `v0.6.12`, keeping the standard-user Mac Node route.
The release's two text and version commits are cherry-picked with `-x`; this isn't a merge of `release/0.6.12`, whose source changes main already has whole.
Two fixes from a first-user run on a Mac with fresh accounts.
- **Node.js for a standard Mac user:** someone who isn't an administrator, or whose Homebrew belongs to another account, can install Node.js in their own home folder with nvm. They run `touch ~/.zshrc` first, because a new Mac account has none and nvm's installer only adds itself to a profile file that already exists. Then they run nvm's install command, open a new terminal, and run `nvm install 22`. No administrator password is needed, and `npm install -g` then installs into the nvm folder. This is in `docs/reference/getting-started.md` and the README. Nothing is claimed about Node.js's own installer for a standard user.
- **What the registry checks decide:** `docs/reference/publishing-a-rig-bundle.md` now says that a submission with a taken name is still received, that a team sharing a listed team's `rig.yaml` name (such as an unchanged copy) passes with a maintainer notice, and that listing is the maintainer's review decision, not the checks'. Registry policy is unchanged.
Text only. The registry wording was read against `tools/registry-check.mjs` and `tools/ci/bundle-check.mjs` at the registry's main.
Four onboarding facts that had drifted, corrected in place. Text only, with no change to the onboarding path.
- The install script pin moves from `v0.6.8` to `v0.6.11`, the newest published release, in `README.md` and `docs/reference/getting-started.md`. Nothing moves these pins automatically.
- The `rigs` skill's footer drops "Written for OpenRig 0.6.7." and keeps the rule that `rig <command> --help` wins when it disagrees with the skill. Both copies stay byte-identical.
- The README and getting-started prerequisites now say one working Claude Code or Codex account is enough: `rig setup --providers` takes either, and the kernel operator adapts the shipped `starter` team to whichever the person has.
- The skill's disclosure of what starting OpenRig and a team writes now names Claude Code workspace trust in `~/.claude.json`, the activity hooks in `.claude/settings.local.json` and a status line there unless the project already has its own. It also says that, unless a permission policy, a per-seat choice or (for Codex) a named profile applies, the kernel's own seats run with an operational default: Codex with `-s danger-full-access -a never`, and Claude Code with its file tools, web fetches and operational commands, including reads under the home folder, allowed without asking.
`npm run test:repo` (docs guard, first-run references, skill mirrors, context packs) and the packaged-skill identity test pass.
README's "What OpenRig changes on your machine" now matches the writers it describes: startup writes Codex's managed config only when a Codex seat is recorded (otherwise it removes stale managed hooks), the first Codex launch ensures the config, a user's own Claude status-line command wins, and the warning about settings files is narrowed to the writers that actually recover unreadable files, without a product-wide preservation guarantee.
Error and help text now point to steps that exist:
- the protected-compaction refusal for an unrecorded pane names `rig reconcile-session <session> --no-launch`, notes that it records a new claimed session row with unverified conversation continuity, keeps input protection on, and points to `rig context get help` when the pane can't be resolved;
- `rig provider` prints the daemon's error message instead of a bare code, and prints a seat's unavailable reason even when it has windows;
- `rig scope --workspace` help states that a missing tree falls back to the configured root except for `mission create`, which creates the named tree, and `approve`, which refuses;
- config help tells a complete `--full` payload apart from the usual projections, including `queue transitions --full` and whoami's `--all-peers`;
- Pi cost switches are described as taking effect at a seat's next launch or resume, provider usage windows as off by default with the command to enable them, and cost history as `--json` only.
Human output and help text only: JSON output, exit codes, behaviour and path selection are unchanged.
The README's overview line read as if the whole project were in maintenance mode. It now says that OpenRig itself is under active development, and that only the older React web UI is in maintenance mode, with best-effort support. One line, text only.
Refs #55
An agent working in a plain clone of OpenRig now finds its starting map from the README.
- One line in the Community list: the `developing-openrig` skill in `.agents/skills/` (Claude Code: `.claude/skills/`) and CONTRIBUTING.md. Both paths exist.
- A README line rather than a tracked root `AGENTS.md`: Codex and Pi seats write OpenRig's managed block into the working directory's `AGENTS.md`, so a tracked one would leave every contributor clone that runs one of those seats with a modified file.
Text only.
Adds `docs/reference/claude-status-line.md`, linked from the README's Claude notes: why a user-level Claude status line doesn't show in a seat's directory (the seat's `.claude/settings.local.json` takes precedence), that OpenRig keeps a custom nonempty status-line command since 0.6.5 and what is lost without the collector, a POSIX-shell wrapper that feeds the same input to the collector and a custom renderer, and how to check after an upgrade or instance change that collection is still current. Docs only. Refs #1272.
Four first-hour fixes from a first install on a fresh Mac. rig setup --providers claude|codex|both leaves an unchosen provider uninstalled and reports it Not selected; a chosen provider's failure still fails, and setup without the option is unchanged. A first rig daemon start no longer prints tmux's "error connecting" line. Setup's next steps say starting OpenRig and handing the person to the operator are part of the install. The operator's first copy no longer stops for an approval prompt.
Add a topology naming reference and point the RigSpec, bundle, onboarding and authoring guidance at it, so new teams name pods and seats by purpose, domain and role. Existing rigs and aliases stay supported. Text only.
After install the agent opens the OpenRig TUI and operator as the handoff, sized to the person's terminal (operator alone under 120 columns, 50/50 from 120, an openrig kernel space inside Herdr), reusing a space only under its own name with live attached panes. Supersedes #989, #990 and #992.
Help, setup output and docs make the welcome screen discoverable: on a desktop the agent opens it with rig terminal open saved:kernel --window; over headless SSH it gives the attach command.
Setup installs herdr by default and rig terminal open --window opens the welcome view in a new terminal, so the person copies no command; a failed herdr install is a warning and setup continues.
Generated-file hygiene recognises the namespaced .codex/plugins/shared:openrig-core folder, so OpenRig's generated Codex plugin folder no longer shows as untracked.
Brings the README and the reference docs to the 0.6.6 release commit 2620dea8: claims checked against source at that commit, schema-2 and legacy bundle installs described separately, the permission-default exceptions kept in the short summaries, and plain wording for in-flight Slack work.
Shipped docs, skills, help and onboarding text now name the new built-in teams: starter, workshop and factory, plus the code-review, research and pm shelf. first-project is mentioned only as starter's old name, Codex-only readers are pointed to the kernel operator to adapt a team, and secrets-manager stays listed as built in. Skill mirrors and edge digests are regenerated.
From a blank-machine install on Ubuntu 24.04: the README and getting-started now name a Linux route to a supported Node.js (nvm or NodeSource, since the distribution's own may be 18), say cmux is macOS-only and optional, and explain that npm 11 and later can skip the CLI's postinstall Node.js and SQLite check with an install-scripts warning, which is expected, and how to run that check directly.
`rig terminal open saved:kernel` now works without editing YAML. With no saved kernel view, OpenRig builds one in memory from the installed kernel's actual bindings (advisor, operator and TUI; advisor and TUI for a single-runtime kernel) and opens it through the existing view and provider path. Missing or unbound roles are named absent with a reason; if nothing can attach, the result names every missing role instead of opening an empty view. A user's own kernel view still wins, and opening never starts, restarts or restores a seat. Getting started, help, the README, setup's closing guidance and onboarding now point to the command.
Brings four reference pages up to the 0.6.6 candidate: kernel seats launch with an operational default (Claude acceptEdits plus a per-launch allow list including reads under home; Codex -s danger-full-access -a never) unless a policy, per-seat choice or named Codex profile applies. getting-started now says Codex network access is added only when Codex answers that no configuration layer or managed requirement governs it, and the launch is unchanged otherwise.
After installation, the installing agent tells the person it will open a terminal so they can see their OpenRig agents, then opens a new space with existing tools: herdr, else cmux, else a plain terminal window. The first space shows the kernel advisor, the operator agent and the OpenRig TUI for a dual kernel, or the advisor and the TUI for a single-runtime kernel; it never takes over the installing agent's terminal or an existing space. Getting started gives the same steps as exact commands for a person, with session names taken from the kernel inventory, and on a headless or SSH target it says so and gives the exact attach command. The README, help, onboarding guide and setup's final text point to it.
Corrections from after-merge source checks of the README and the spec, context and startup references. Text only.
- README: a local rig bundle install needs --target (rig up and GitHub links default to the current directory); the Codex network default applies only when Codex confirms nothing sets or restricts it; builtin:auto keeps a named Codex profile and Pi's resource trust.
- agent-spec: filesystem skill discovery is for Claude Code and Codex (Pi uses only the skills folder beside the RigSpec; OMP does none); the auto hint also installs content starting # SKILL as a skill.
- agent-state-taxonomy and agent-startup-guide: the STARTUP, ORIENTED and RESTORE columns need rig ps --nodes --full.
- lore-routing, refocus-channel, project-workspace: rig context profile needs --situation; the light refocus trace previews about 800 characters of each LEARNED.md; a matching --project without a catalog reports selectedBy explicit.
Front-door documents re-verified against main for 0.6.6. Facts only; structure, voice and the README anchor are unchanged.
- README: rig setup installs a missing harness (and cmux on macOS); rig seat continue for a seat stopped at a prompt; the npm install table names rig and openrig-tui and adds a bundle-install row; Codex network access on the plain sandbox; the OPENRIG_YOLO, builtin:auto and --non-interruptive launch effects; restore outcomes, bundle links and checks, and the default culture; later release notes in CHANGELOG.md.
- CONTRIBUTING: tmux version in bug reports, the docs guard, context packs not committed, the UI suite runs in CI, and the skills locations.
- SUPPORT: the agent help page URL, the support email already published in help.md, and tmux and harness details in bug reports.
- SECURITY: the provider and project files OpenRig writes, and the tmux and cmux edits made by rig setup.
The README's rig setup row now says why setup changes cmux's automation.socketControlMode: cmux defaults it to cmuxOnly, which only accepts processes started inside cmux and so blocks OpenRig's control, so setup switches it to automation.
When a Claude seat uses an explicitly selected CLAUDE_CONFIG_DIR, OpenRig now writes its onboarding and workspace-trust bootstrap to that selected home, so the seat is not stranded at first-run screens. The classic launch (permissionMode omitted) keeps its existing home; a binding without a working directory uses the same stored-node selection as the launch; malformed existing state is preserved with a warning. The rig setup and README disclosures now name the right file. Native sign-in and Keychain behaviour are not verified. Refs #154.
Add `runtime: omp` as a managed runtime that runs Oh My Pi through
OpenRig's RPC runner, separate from `runtime: pi`.
Runner and launch:
- Share the Pi RPC runner with OMP-specific launch arguments, approval
mode (`always-ask` floor, `yolo` under a full-bypass policy), and a
deny-by-default environment allowlist.
- Isolate each seat under `$OPENRIG_HOME/state/omp/<seat>` with a per-seat
HOME so OMP never reads the operator's `~/.omp` or `~/.env`. Resolve the
real `omp` binary first so version-manager shims keep working.
- Cancel headless approval/input requests and keep the seat in
needing-attention until the next agent run; surface rejected prompts and
in-turn model/provider errors once per turn.
Identity and resume:
- Persist the OMP session file as the resume token only once it exists on
disk and matches the seat's own session file; retry identity delivery
until the daemon confirms the token.
- Validate the persisted seat runtime and session name on identity hooks,
and report `tokenPersisted` from the stored state for RPC runtimes.
- Capture and resume OMP session files through claim, handover, and
restore paths.
Recognition and docs:
- Recognize OMP in RigSpec validation, preflight (`omp --version`),
runtime verification, session fingerprinting, and discovery.
- Document OMP state, credentials, approval posture, model errors, and
restore in the RigSpec reference; add OMP UI branding.
The README opening now says what OpenRig is in one sentence (open-source
software for building and running your own network of agents) and closes
with the line about the AI civilization experiments. The npm package
description and the Context7 description use the same short summary:
"Build your own network of agents from Claude Code, Codex and Pi:
long-running teams with roles, shared context and owned work."
Co-authored-by: v-openrig-build <[email protected]>
* docs(readme): link the guide, help, Q&A and updates on X near the top
OpenRig is on GitHub's daily trending list. A stranger reading the first
screen found no link to the getting-started guide, the help guide, the Q&A
start-here thread or where updates and demos are posted. One line after the
introduction adds all four.
* docs(readme): offer the next walkthrough to visitors not installing today
For trending visitors who can't stop to install now: a secondary call to action
near the top and again after the getting-started steps, pointing to the
existing openrig.dev/follow signup. Nothing about installing the software is
gated.
* docs(readme): show the demo and a Start here link before the install steps
Trending visitors read the install prerequisites before seeing what OpenRig
looks like. Move the existing 'See it running' recording above the install
section, add a Start here link to the guided first-use path, and keep the
follow line after it. The install section, its requirements and the
disclosure of what OpenRig changes are unchanged and in the same order.
---------
Co-authored-by: v-openrig-build <[email protected]>
* docs: point agents to the OpenRig help route when OpenRig misbehaves
Add a short pointer to https://www.openrig.dev/help/agents in the
managed start guidance every seat reads, the openrig-skills index (all
three identical copies, digests regenerated) and the README 'For agents'
line. The route sends a symptom to version-matched docs and known
issues and explains how to reach the team. rig --version and rig doctor
help when available, but a broken install is not a reason to skip the
page. No new command.
* docs: one help guide for agents, served by rig context get help
Agent help now lives in one file, docs/reference/help.md. It ships with every
install, so it matches the installed version, and Context7 indexes it. A new
static context pack, help, serves the same file through `rig context get help`
by symlinking to it. The pack build copies the link's target, so installs get a
real file.
The pack generator accepts a static-pack symlink only when it points to a file
under docs/reference/. Any other link fails the build before anything is
written. Tests cover the help pack's bytes and both symlink cases.
The startup guidance, the openrig-skills index (all three copies), the
onboarding capability map, README and SUPPORT now point to `rig context get
help`, falling back to the installed file or openrig.dev/help/agents (the same
text) when `rig` won't run.
* docs(help): say contact options, not a contact form
The website's help page lists email and public Q&A; it has no contact form.
* docs(help): load linked guides on demand; correct the installed fallback path
F1: `rig context get help` served help.md alone, so its links to
getting-started, instance-layout and rig-spec had nothing to resolve against.
A new static pack, reference, symlinks exactly those three files from
docs/reference/. help.md keeps its source-relative links and adds the
`rig context get reference/<file>[#section]` address beside each, so a guide
loads only when it's needed and a help read stays small.
F2: the broken-rig fallback named docs/reference/help.md "in the installed
package". The package build copies these files to daemon/docs/reference/ in
@openrig/cli. Corrected in help.md, the startup guidance and the openrig-skills
index (all three copies, digests regenerated).
Tests: the reference pack ships real files equal to their sources; every
address help.md teaches resolves through the daemon's address route, section
and whole-file; the help preview contains none of the three manuals; a fixture
proves the address check fails on a missing target; source links and the
installed-path text match build-package.sh.
---------
Co-authored-by: v-openrig-build <[email protected]>
Bring the shipped macOS arm64/Node 24 SQLite caveat (0.5.15 known
compatibility limitation, repeated in the 0.5.17 notes) to the install
line, the Requirements list and Getting Started. State the platform
posture: macOS or Linux; native Windows is not supported yet; WSL2 has
not been tested. The declared Node range is unchanged.
Co-authored-by: v-openrig-build <[email protected]>
* fix(package): install without the unpublished @openrig/daemon (#66)
The CLI package declared the private @openrig/daemon in dependencies and
shipped it as a bundled dependency. npm used the bundle, but package managers
that resolve every dependency from the registry, such as Bun, failed with a
404.
The package already ships the daemon under daemon/. The package build now
rewrites the compiled CLI and TUI imports of @openrig/daemon/<subpath> to that
copy, using the daemon's exports map, and fails on any unmapped or unstaged
subpath or any daemon import left afterwards. The dependency, the bundled
copy and their lockfile entries are removed. Source imports and development
resolution are unchanged.
Reported by @drewpayment.
* fix(package): rewrite daemon imports from the syntax tree, not text
Parse each staged file with the TypeScript compiler and rewrite only real
import/export specifiers and literal import()/require() arguments. Text in
comments, strings and templates is no longer changed, and imports that carry
comments or use template literals are no longer missed. Unparseable files and
non-literal module arguments naming the package now fail the build.
* docs: note Bun installation and its postinstall limit
Bun can install the CLI, but OpenRig still runs on Node.js and Bun may
block the package's postinstall check.
* fix(package): run the daemon import rewrite from any checkout path
The direct-run check compared import.meta.url with a hand-built file:// URL,
which never matched when the path needed percent-encoding (spaces, #) or went
through a symlink. The script then exited 0 without rewriting anything. Compare
the decoded module path with the real path of argv[1] instead.
---------
Co-authored-by: OpenRig contributors <[email protected]>
Wu Shuwen