docs: refresh the README, CONTRIBUTING, SUPPORT and SECURITY facts against main (#782)

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.

.github/SUPPORT.md

@@ -4,9 +4,12 @@
   troubleshooting. An index linking to agent-friendly documentation is at
   https://openrig.dev/llms.txt.
 - **Agents helping a user:** read [docs/reference/help.md](../docs/reference/help.md), or run `rig context get help`.
+  The same guide is at https://www.openrig.dev/help/agents.
+- **Email:** hello@openrig.dev, which needs no GitHub account.
 - **Questions:** [Discussions › Q&A](https://github.com/mvschwarz/openrig/discussions/categories/q-a).
 - **Bugs:** [open an issue](https://github.com/mvschwarz/openrig/issues/new/choose) with the bug
-  template. Include `rig --version`, your OS and Node versions, and relevant redacted command output.
+  template. Include `rig --version`, your OS, Node and tmux versions, the harnesses involved, and
+  relevant redacted command output.
   Reports are public: remove credentials, private prompts and personal information.
 - **Ideas and setups:** [Ideas](https://github.com/mvschwarz/openrig/discussions/categories/ideas)
   and [Show and tell](https://github.com/mvschwarz/openrig/discussions/categories/show-and-tell).

CONTRIBUTING.md

@@ -8,7 +8,7 @@ change in with the least friction on both sides.
 ## Before you start
 
 - **Bugs:** open an issue with the bug template. Include your OpenRig version (`rig --version`),
-  OS, Node version, which harnesses are involved (or none), and the relevant command and output.
+  OS, Node and tmux versions, which harnesses are involved (or none), and the relevant command and output.
   Reports are public: remove credentials, private prompts, personal details and private paths
   before posting. Share a small reproduction rather than a full transcript or instance dump.
 - **Features and behaviour changes:** open an issue or a Discussion in *Ideas* first. A short
@@ -57,12 +57,16 @@ the lockfile change with it.
 
 `npm test` builds the daemon and runs repository checks before the package suites. Read the
 specific failure. A shipped skill may exist in more than one copy (see ARCHITECTURE.md): edit every copy, then run
-`node scripts/regen-edge-digests.mjs` (the full `npm run mirror-skills` apply needs maintainer-only
-inputs; see "A shipped skill" in [ARCHITECTURE.md](ARCHITECTURE.md#a-shipped-skill)).
-`npm run generate-context-packs` updates generated packs. Review the generated diff; neither
-fixes every documentation failure. The UI unit-test suite is advisory and separate:
-`npm run test:ui`. [docs/as-built/test-layers.md](docs/as-built/test-layers.md) lists every test
-layer, what CI runs, and what each layer can and cannot prove.
+`node scripts/regen-edge-digests.mjs` and commit the digest file it changes (the full
+`npm run mirror-skills` apply needs maintainer-only inputs; see "A shipped skill" in
+[ARCHITECTURE.md](ARCHITECTURE.md#a-shipped-skill)). The repository checks include a docs guard: a
+tracked file under `docs/` must be in `docs/as-built/`, `docs/reference/` or `docs/releases/`
+(`docs/DESIGN.md` is the one exception). They also validate the context-pack sources;
+`npm run generate-context-packs` rebuilds the generated packs locally, which aren't committed.
+The UI unit-test suite is separate from `npm test`: run `npm run test:ui`. CI runs it on every pull
+request as `package-tests (ui)`, so a change has to pass it.
+[docs/as-built/test-layers.md](docs/as-built/test-layers.md) lists every test layer, what CI runs,
+and what each layer can and cannot prove.
 
 For hands-on development, read the [check requirements](docs/reference/developing.md),
 [worktree setup](docs/reference/worktree-builds.md), and
@@ -84,7 +88,7 @@ your working copy.
 - Do not bump versions.
 - Match the surrounding style. `npm run lint` typechecks; it does not format code.
 - Write commit messages in the form the log already uses: `fix(cli): …`, `feat(daemon): …`,
-  `docs(reference): …`, `harness: …`.
+  `docs(reference): …`, `test: …`.
 
 ## The pull request
 
@@ -118,7 +122,8 @@ clarifying question or run the reproduction; a maintainer makes the merge decisi
   when they work in this checkout (`.claude/skills/` and `.agents/skills/`). It points at the maps
   above and at what to run before you push.
 - Repository reference: `docs/reference/`; user documentation: [openrig.dev/docs](https://openrig.dev/docs).
-- Skills: `packages/daemon/specs/agents/shared/skills/` and plugin skills under
-  `packages/daemon/assets/plugins/`; static context-pack sources: `packages/daemon/context-packs-src/`.
+- Skills: `packages/daemon/specs/agents/shared/skills/`, plugin skills under
+  `packages/daemon/assets/plugins/`, and `skills/_canonical/`; static context-pack sources:
+  `packages/daemon/context-packs-src/`.
   Generated packs live in `packages/daemon/context-packs/` and are not hand-edited or committed.
 - Releases: [GitHub Releases](https://github.com/mvschwarz/openrig/releases) and npm `@openrig/cli`.

README.md

@@ -29,7 +29,7 @@ rig setup --dry-run
 
 To install with Bun instead, run `bun add -g @openrig/cli`. OpenRig still runs on Node.js, so install Node.js 22 as well. Bun may block this package's postinstall script, in which case the Node.js and SQLite check described under [what OpenRig changes on your machine](#what-openrig-changes-on-your-machine) does not run at install time.
 
-Choose the working account you already have: **Claude Code, Codex, or both**. Reuse an explicit choice; no second subscription is required. `rig setup --dry-run` previews the broader setup, but applying `rig setup` checks both harnesses and cmux. It is optional for the [selected-provider path](docs/reference/getting-started.md#choose-your-providers).
+Choose the working account you already have: **Claude Code, Codex, or both**. Reuse an explicit choice; no second subscription is required. `rig setup --dry-run` previews the broader setup, but applying `rig setup` checks both harnesses and installs a missing one, and on macOS cmux too. It is optional for the [selected-provider path](docs/reference/getting-started.md#choose-your-providers).
 
 Before launching, your agent asks once: **“Allow your agents to run OpenRig commands without repeated permission prompts?” Yes — recommended / No — keep prompts.** This covers every `rig` command, including starting/stopping agents and configuration, at personal project scope unless you explicitly choose user-wide sessions. It is not global YOLO or permission to invent work. On Yes, the agent [adds and verifies native rules](docs/reference/getting-started.md#have-your-agent-configure-permissions); No or no answer leaves settings unchanged. An existing explicit choice is reused. Say “Undo the OpenRig command allowances added by this setup” to remove only its additions.
 
@@ -61,7 +61,7 @@ rig tui --shared
 
 The kernel provides separate operational support and the shared dashboard. To detach without stopping the dashboard, press Ctrl-b then d; `rig tui --shared` returns to that view. Plain `rig tui` opens an independent view. Closing a viewing terminal does not mean you should relaunch the team.
 
-Check project-seat readiness with `rig ps --nodes --rig "$starter"` and resolve any authentication, trust or permission prompt before assigning work. Then give the owner one bounded outcome from your repository:
+Check project-seat readiness with `rig ps --nodes --rig "$starter"` and resolve any authentication, trust or permission prompt before assigning work. If a seat stopped at such a prompt before its startup context arrived, `rig ps` shows the `rig seat continue <seat>` command that delivers it once the prompt is answered. Then give the owner one bounded outcome from your repository:
 
 ```bash
 rig send "dev-owner@$starter" 'Implement <one useful change>. Track the task in the queue and return its ID. Keep it local, verify the behavior, ask dev-check in this rig to check the exact candidate, and record the result and how I can try it.'
@@ -91,10 +91,11 @@ using a published package, since repository guidance can be ahead of npm.
 
 | When | What changes and why |
 | --- | --- |
-| **npm installation** | Installs the CLI, bundled components and dependencies under your npm prefix (with Bun, under Bun's global directory). OpenRig's postinstall checks the Node.js version and that the SQLite module loads; Bun may block this script. It does not run daemon or provider setup. |
+| **npm installation** | Installs the CLI (`rig` and `openrig-tui`), bundled components and dependencies under your npm prefix (with Bun, under Bun's global directory). OpenRig's postinstall checks the Node.js version and that the SQLite module loads; Bun may block this script. It does not run daemon or provider setup. |
 | **`rig setup`** | Attempts missing tools and writes an OpenRig block in `~/.tmux.conf` for mouse support and scrollback. On macOS it can install cmux and enable its automation socket control in `~/.config/cmux/settings.json`; cmux defaults `automation.socketControlMode` to `cmuxOnly`, which only accepts processes started inside cmux and so blocks OpenRig's control, so setup switches it to `automation`. `--full` adds workstation tools. `--dry-run` shows setup's plan without applying it. |
 | **Daemon startup** | Creates/updates instance state under `OPENRIG_HOME` (normally `~/.openrig`), including its database and managed plugin resources. Seeds the `openrig-skills` discovery skill in `~/.claude/skills` and `~/.agents/skills`, subject to existing version ownership. With `runtime.codex.hooks_enabled` enabled (the default), writes Codex hook configuration and trust records as described below—even before a rig launches. |
-| **Rig/seat launch and attachment** | Creates tmux sessions, supplies seat identity and daemon connection environment, and projects selected guidance, skills, plugins and runtime resources into the workspace. Managed startup pre-trusts the workspace. Claude context collection can also be provisioned for attached sessions and refreshed during monitoring. |
+| **Rig/seat launch and attachment** | Creates tmux sessions, supplies seat identity and daemon connection environment, and projects selected guidance, skills, plugins and runtime resources into the workspace. Managed startup pre-trusts the workspace. Claude context collection can also be provisioned for attached sessions and refreshed during monitoring. In a Git repository, newly created files under `.codex/plugins/openrig-core/` are added to the repository's Git `info/exclude` inside an `# BEGIN OpenRig generated files` block; new `AGENTS.md`, `CLAUDE.md` and `CLAUDE.local.md` files stay visible with a warning. |
+| **Bundle install** (`rig bundle install`, or `rig up` with a `.rigbundle` or GitHub link) | Writes the bundle's files into the install target (`--target`, or the current directory) and routes its declared skills, plugins and context packs into your libraries. A GitHub link's archive is kept under `OPENRIG_HOME/bundle-imports/`, and installs are recorded in `OPENRIG_HOME/bundle-audit.jsonl`. A bundle that carries a project creates it under `workspace.projects_root` and records it, with the rig's association, in the workspace catalog. |
 | **Explicit permission configuration** | The built-in bootstrap does **not** add `rig` command allow rules. Agent-guided setup recommends Yes and requires your actual answer before the agent [adds rules at your chosen scope](docs/reference/getting-started.md#have-your-agent-configure-permissions). No/no answer preserves settings; existing choices and stricter rules remain relevant. Broader access is separate. |
 
 The provider files are separate from instance state. Here `~` means the daemon
@@ -103,7 +104,8 @@ user's home; changing `OPENRIG_HOME` alone does not isolate provider configurati
 - **Claude Code:** startup writes workspace trust and onboarding completion.
   With an explicit permission mode, it uses the launch-selected `HOME/.claude.json`,
   or `<CLAUDE_CONFIG_DIR>/.claude.json` when that variable is set. Classic startup
-  retains the daemon's `~/.claude.json` path. In the workspace, `.claude/settings.local.json` receives
+  writes `HOME/.claude.json`, and also `<CLAUDE_CONFIG_DIR>/.claude.json` when the
+  daemon has that variable set. In the workspace, `.claude/settings.local.json` receives
   the context collector's `statusLine` command and selected activity hooks;
   helper scripts live under `.openrig/`. Selected settings/MCP resources can also
   change that settings file and `.mcp.json`. The shared settings resource sets
@@ -131,14 +133,25 @@ Managed launches supply `HOME`, `CODEX_HOME` and `OPENRIG_*` identity/connection
 variables. Claude uses `--permission-mode acceptEdits` and defaults to the classic
 renderer for terminal scrollback. Codex uses `-s workspace-write` unless a named
 profile governs its sandbox; the default does not force an approval-policy flag.
+On that plain launch OpenRig first asks Codex for its own configuration and adds
+`-c sandbox_workspace_write.network_access=true` unless a configuration layer sets
+network access or a managed requirement could restrict it, so the seat can reach
+the local daemon.
 Fresh Codex launches also add writable access to the workspace's `.git` and the
 pod's shared queue-state directory with `--add-dir`; the shared root comes from
 `OPENRIG_SHARED_DOCS_ROOT` or `~/.openrig/shared-docs`.
 YOLO is **off by default**. An explicitly selected full-bypass policy selects
 Claude's `--dangerously-skip-permissions` or Codex's
 `-s danger-full-access -a never`. The legacy environment-only `OPENRIG_YOLO=1`
-path still selects only Codex's sandbox; a resolved policy overrides that
-environment setting.
+path, with no policy attached, selects Claude's bypass flag, Pi's `--approve` and
+Codex's `-s danger-full-access` without `-a never`; a resolved policy overrides
+that environment setting. The `builtin:auto` policy launches Claude with
+`--permission-mode auto`; Codex and Pi seats stay at the floor.
+`--non-interruptive` on `rig up` or `rig bundle install` additionally passes
+per-launch flags to full-bypass seats so Claude's bypass warning and Codex's
+full-access and GPT-5.1 migration notices don't stop startup; it writes nothing to
+their settings files and is saved on the rig. See
+[non-interruptive mode](docs/reference/non-interruptive-mode.md).
 
 Permission mode controls native execution permissions; work posture is separate
 project guidance. Use `rig policy permissions list|show|current|apply` for rig
@@ -249,9 +262,9 @@ For cmux, use `--provider cmux`. In the TUI, a rig's detail view has a `term ▸
 - **Seat**: A stable role and address in a rig, such as `dev-owner@first-project`. The conversation occupying it can change while its identity and authored context remain.
 - **Pod**: A group of related seats with shared guidance and context. Each agent still has its own context window.
 - **Discovery**: `rig discover` fingerprints existing tmux sessions. `rig adopt` brings them under management.
-- **Snapshot/Restore**: `rig down --snapshot` captures full state. `rig up <name>` restores from latest snapshot. Restore reports per-node outcomes (resumed, fresh, or failed).
-- **RigBundle**: Portable archive with vendored AgentSpecs and SHA-256 integrity. Share topologies across machines.
-- **Culture**: CULTURE.md sets coordination norms for the group. Research rigs get exploratory culture. Implementation rigs get conservative, trust-but-verify culture.
+- **Snapshot/Restore**: `rig down --snapshot` captures full state. `rig up <name>` restores from latest snapshot. Restore reports per-node outcomes: resumed, fresh-primed, awaiting-decision (the original conversation can't resume; choose `--fresh`), attention_required, or failed.
+- **RigBundle**: Portable archive with vendored AgentSpecs and SHA-256 integrity. Share topologies across machines. `rig up`, `rig bundle create`, `inspect` and `install` also take a GitHub folder link, `rig bundle check` checks a folder before you share it, and `rig bundle inspect` shows what a bundle will do before you install it. See [publishing a rig bundle](docs/reference/publishing-a-rig-bundle.md).
+- **Culture**: A rig's `CULTURE.md` (its `culture_file`) sets coordination norms for the group, on top of OpenRig's default culture, which every seat receives.
 
 ## Agent-Managed Software
 
@@ -267,7 +280,7 @@ Requires Docker for service-backed rigs.
 
 ## Upgrading an existing instance
 
-For an existing installation, follow the [upgrade procedure](skills/_canonical/core/openrig-upgrade/SKILL.md) and the [0.5.14 release notes](docs/releases/v0.5.14.md). Preserve live seats during the upgrade; `rig down` is not an upgrade step. Upgrading to 0.6.0 also requires Node.js 22 or 24: see [Moving off Node 20](#moving-off-node-20) and the [0.6.0 release notes](docs/releases/v0.6.0.md).
+For an existing installation, follow the [upgrade procedure](skills/_canonical/core/openrig-upgrade/SKILL.md) and the [0.5.14 release notes](docs/releases/v0.5.14.md); notes for later releases are in [CHANGELOG.md](CHANGELOG.md). Preserve live seats during the upgrade; `rig down` is not an upgrade step. Upgrading to 0.6.0 also requires Node.js 22 or 24: see [Moving off Node 20](#moving-off-node-20) and the [0.6.0 release notes](docs/releases/v0.6.0.md).
 
 ### Moving off Node 20
 

SECURITY.md

@@ -9,7 +9,11 @@ Include the affected version even when reporting a problem in an older installat
 ## What OpenRig touches
 
 OpenRig runs a local daemon, drives coding agents in tmux sessions on your machine, and writes
-configuration for those harnesses (for example under `~/.claude` and `~/.codex`). The README
+configuration for those harnesses, including workspace trust records and executable hooks: for
+example `~/.claude.json`, skills under `~/.claude`, `$CODEX_HOME/config.toml` (default `~/.codex`),
+and, in the project, `.claude/settings.local.json`, `.mcp.json` and managed blocks in `CLAUDE.md`,
+`CLAUDE.local.md` or `AGENTS.md`. `rig setup` also edits `~/.tmux.conf` and, on macOS, cmux's
+settings. OpenRig's own state lives under `$OPENRIG_HOME` (default `~/.openrig`). The README
 section [What OpenRig changes on your machine](README.md#what-openrig-changes-on-your-machine)
 describes these effects and the trust/permission choices. Unexpected access, disclosure or
 permission changes are useful reports; include what you expected and what you observed.