OpenRig v0.6.6

OpenRig 0.6.6

0.6.6 is about getting to your agents fast. After you install OpenRig, the kernel's operator greets you, asks what you want to build, offers three teams and launches the one you pick in your own project. Teams can now be shared and installed from a GitHub folder link, and the workshop, OpenRig's four-seat team for building in any repository, installs from openrig.dev/rigs with one command.

npm install -g @openrig/cli

It is built from main at 2620dea8 (after #900). Work merged to main after that point isn't in this release. If something breaks for you, please open an issue.

Before you upgrade

Restart the daemon after upgrading the CLI. The running daemon keeps its old build until it restarts: run rig daemon stop, then rig daemon start. On its first start the daemon adds a database column for the non-interruptive choice (existing rigs start with it off) (#737), and installs the bundled openrig-core plugin at version 0.1.4 (#685, #829). Running seats pick up the new plugin when they next launch.

The built-in teams have new names. The shelf is now starter (a Claude Code builder and a Codex reviewer), factory (a lead, an advisor, a builder, QA, design and two reviewers), the specialist teams code-review, research and pm, plus secrets-manager and the kernel (#864, #866, #868).

• rig up first-project still works and starts starter, with a note that the team's providers changed. first-project used two Codex seats; starter has a Claude Code builder and a Codex reviewer, so on a Codex-only machine ask the kernel's operator to adapt it.
• adversarial-review is now code-review, research-team is now research, and pm-team is now pm. There is no alias for these three.
• conveyor, demo, implementation-pair, product-team, first-project-claude, first-project-mixed and factory-rsi are no longer built in. Rigs you already created from them keep restoring.
• The implementer and QA agents no longer load the test-driven-development skill by default. The skill is still available.
• workshop isn't built in, so rig up workshop doesn't resolve. Install it from openrig.dev/rigs (see the highlights).

Team seats get permission defaults that need fewer prompts. A Claude Code or Codex seat in any rig other than the kernel, with no member or rig permission_policy, no permission choice saved for the seat, and (for Codex) no named Codex profile, gets a team default at its next launch, resume, fork or handover (#893).

• Claude Code: OpenRig passes an allow list and an ask list with the launch. rig commands, reads inside the project and common test commands (npm test, pytest, go test, cargo test and similar) run without a prompt. Lifecycle commands such as rig up, rig down, rig bundle install, rig seat stop and rig daemon stop still ask. Your own ask and deny rules still apply, and no settings file is written.
• Codex: the seat keeps the workspace-write sandbox and can also write OpenRig's workspace folder and its pod's state folder. Lifecycle commands don't ask yet (see Known issues).
• These are command allowances, not containment: a project's test command runs project code.
• To keep the previous behaviour, give the rig or member an explicit policy, for example permission_policy: none.

Kernel seats get operational authority. Seats of the rig named kernel with no explicit permission choice, member or rig policy, or (for Codex) named profile launch with a wider default, so the operator can install and run teams for you (#820, #858). Claude Code runs in acceptEdits with an allow list for file tools, reads under your home folder, and operational commands such as rig, tmux, npm, git, ssh and curl, plus claude auth status and codex login status. Codex runs unsandboxed with approvals off (-s danger-full-access -a never). Your ask and deny rules still apply to Claude. rig seat status reports the source as the kernel operational default. To keep the previous behaviour, set an explicit permission choice or policy on those seats.

New rigs with services get their own Docker Compose project. A new rig's default Compose project now comes from its rig ID instead of its name, so two rigs whose names sanitize to the same string no longer share containers (#481). Existing rigs keep their project. A rig created fresh, not as a same-name replacement, won't attach to containers or volumes under the old name-based project unless you set services.project_name. If service boot or every seat launch fails, the new project is brought down (never with volumes). When the generations being replaced use different projects and no project_name is set, rig up refuses with compose_project_conflict and starts no services. rig down exits 2 when it keeps a project that a live rig of the same name still uses.

Files a launch creates now show in git status. When a launch creates a new guidance file such as AGENTS.md or CLAUDE.md in a Git repository, OpenRig leaves it visible to Git and prints the exact line you can add to .git/info/exclude. New files under .codex/plugins/openrig-core/ are excluded automatically, in a marked OpenRig block in info/exclude; delete a line in that block to make a path visible again (#721, #727).

Slack catches up after a gap. On the first daemon start with Slack inbound configured, each channel gets a recovery checkpoint. From then on, top-level messages posted while the daemon was disconnected are delivered late as tasks marked "Recovered after a gap". History before the checkpoint stays unknown (#742).

Compaction restore maps move into the seat's workspace. Managed Claude compaction now writes the restore map at .openrig/compaction/preparation/<session>/<attempt>/RESTORE-MAP.md in the seat's launch folder, with a .gitignore that keeps it out of Git. Tools that don't read .gitignore (rsync, zip deploys, Docker build contexts without .dockerignore) still see the folder. The OpenRig home is used when the workspace is unknown or unwritable (#685).

Highlights

Meet the kernel's operator after install. On a fresh kernel the operator greets you first and asks, once, what you want to build or change (#858, #862). It offers three teams, starter, workshop and factory, with one recommendation and a drawing of each, and fits the chosen team to the providers you have by writing an adapted copy. It shows you the plan, launches only on your yes, shows you the team, and hands your goal to the team's lead as a queue task (#862, #880). The lead starts from that goal instead of asking again. For continuing work it records one mission and slice in OpenRig's workspace, not in your repository, and a question just gets an answer (#865). An agent that installs OpenRig for you now keeps the kernel running and passes your goal and project folder to the operator, instead of building the project itself (#873). rig setup prints how to reach the operator after ready, incomplete and dry-run results (#859, #886), and when the operator offers the workshop it reads the current pin from the registry's raw file, because a cached copy can be older (#900). The kernel advisor no longer assumes you're on macOS (#770). These are guidance changes for the agents: how closely an agent follows them is what OpenRig's journey runs check (see How it was tested).

See your agents. After installing, the agent opens a new terminal space with the kernel's TUI, advisor and operator (herdr, then cmux, then a plain terminal window) without taking over its own terminal (#821). rig terminal open saved:kernel now works without any saved-view file: it opens the TUI, the advisor and the operator side by side, for Claude-only, Codex-only and mixed kernels. A view you saved yourself under the name kernel still wins (#830, #854). Without herdr or cmux, setup, the TUI preview and a failed rig terminal open give an exact tmux or ssh -t attach command for each seat, and rig tui --shared is named as the dashboard, not the conversation (#831, #833, #878). Team views say the dashboard is the overview and the lead's pane is where you talk about the work (#884, #890). The TUI now goes straight to the work views once it has read the daemon, even when no rig is running; the Start page is still there on S (#818). Opening a rig spec in the TUI shows its topology as a graph with Launch, which asks for a working folder and hands the terminal to the real rig up (#867, #874). rig specs preview starter and rig specs preview factory end with the three-team choice (#884).

Install a team from a GitHub folder link. rig up, and rig bundle create, inspect and install, accept a public GitHub folder link (https://github.com/<owner>/<repo>/tree/<ref>/<folder>). The ref resolves to one commit, and the result reports the source, configuration ID and package digest (#708). Link import needs git on your PATH and a running local daemon.

• Configurations: a bundle can declare presets in configurations.yaml. rig bundle configurations <spec> lists them, and --preset <name> or --seat pod.member=runtime picks one (#704).
• See it before you install it: rig bundle inspect, and the view printed before rig bundle install and rig up <bundle>, show the team and models, the permission posture ("Permission prompts: off for all seats" when every seat declares full bypass), files the agents receive, startup actions, writes, outside domains, the author's setup preconditions (shown, never run) and what stays unknown until launch. Per-seat facts are labelled with the seat (#710, #717, #723, #738, #892).
• Contents arrive first: skills, plugins, workflow specs, context packs and agent images in a bundle are put in place before any seat launches, and routing failures are printed instead of dropped (#692, #705, #720, #722). rig bundle install --cwd <dir> sets every seat's working folder; --target sets the install folder (#692).
• Author tools: rig bundle check <folder> is a local, advisory check of a bundle against the authoring rules (#708). rig bundle create --context-pack <dir> carries a context pack from outside the rig folder, and --project-dir <dir> carries the project the rig works in (#694, #700, #716). An installed pack with the same name is never overwritten. Bundles built by an installed OpenRig record its real version (#718).
• Reinstalling: installing a team that already exists shows what's installed and offers to use it, stop and replace it, or cancel. A running team is refused before anything is written; a stopped one is replaced in the folder holding its installed manifest, with conflicting files backed up first (#877).
• rig bootstrap <file>.rigbundle now goes through the normal bundle install (#709).
• Sharing: the guide is docs/reference/publishing-a-rig-bundle.md (also at $OPENRIG_HOME/reference/). You submit a rig by opening a pull request to openrig-world that adds one file naming its repository, folder and ref. Rig names on the site are unique (#750, #751, #810, #777). The v1 bundle formats are documented in docs/reference/bundle-formats.md with JSON Schemas (#702).

The workshop, on openrig.dev/rigs. The workshop is OpenRig's team for building software in any repository, OpenRig's own included: a lead, a builder, a code reviewer and a QA seat. The lead starts from your goal, plans the work and routes it to the team, and nothing is published until you say so. It ships separately from this package, in the openrig-world repository, and is available from openrig.dev/rigs, which shows its install command. It needs OpenRig 0.6.6. Its seats run with permission prompts off and install non-interruptively by the team's own declaration; the view before install says so.

Launch without prompts, when you choose.

• --non-interruptive on rig up and rig bundle install lets seats whose policy is full bypass skip Claude Code's and Codex's first-launch warnings through launch flags. The choice is saved on the rig and kept for restores, forks and handovers. --no-non-interruptive clears it, with the rig down first. rig config set launch.non_interruptive true makes it the default for new rigs. No harness settings file is written (#737, #741).
• A rig spec can declare non_interruptive: true itself; an explicit flag still wins, and the declaration wins over the machine default (#892).
• If a fresh Claude Code seat stops at Claude's bypass-permissions warning, it now keeps its startup context and reports attention. Accept the warning in that seat's terminal, then run rig seat continue <seat> to deliver the context into the same conversation, without relaunching. rig up and rig bundle install print the command (#740, #748).
• A new built-in policy, builtin:auto, launches Claude Code seats with --permission-mode auto; Codex and Pi seats launch at their normal floor. rig seat status shows the effective mode and where it came from (#680, #733). The built-in policies are described in the RigSpec reference (#713).
• rig seat set-permissions takes --operator <address>, so it works from a plain shell (#689).

Plugin skills reach Claude Code and Codex seats. When a seat's profile selects a plugin, such as openrig-core, its skills are now copied into the seat's .claude/skills/ or .agents/skills/ folder, where the runtime actually loads them. Before, neither runtime saw them. An existing folder with the same name that OpenRig doesn't own is kept, with a plugin_skill_kept warning. Existing seats get the skills when they're next instantiated, not on restore. The change was checked with stand-in harnesses; whether a real Claude Code or Codex seat lists and loads each skill is checked separately (#815, #823).

Find specialists, read history. rig roster list, show and find read JSON rosters from <workspace.root>/rosters/ and show who to involve for a purpose and why, across rigs and hosts. They never dispatch work (#697). rig telemetry events, transitions and tenures read one bounded page of retained history with a cursor and explicit gaps, so collectors no longer read OpenRig's database (#696).

Your project's context, picked for you. With several projects declared and no --project, rig context work-install now picks the project whose rigs: list names the seat's rig, then the deepest project root containing the working folder, then the only unclaimed project. It reports how it chose, and stops with project_required only when more than one still matches, printing a ready-to-run command for each candidate (#690, #688, #772). A project can list world packs under install.worlds (#691). Operating posture reads the same catalog and picks a project the same way (#693, #712).

Answering a menu with a digit. rig send --dangerously-interact now types your answer as keystrokes instead of a paste, so a numbered menu gets the digit you sent. This addresses 0.6.5's known issue #519; it wasn't tried against a live Claude Code or Codex menu. Upgrade the CLI and the daemon together for this (#663).

Behaviour changes to know about

• Queue writes return when they're saved. rig queue create, handoff and handoff-and-complete return once the change is saved, and the wake follows. The returned task no longer reports the wake's outcome; use --verify to wait for delivery (#776).
• rig doctor says what it didn't check. It no longer ends with "System checks look good." It says there were no failures, to review WARN and SKIP rows, and that provider logins and agent readiness aren't checked (#855).
• rig setup output. The guided next steps now come before the permission-policy menu, and --json gains nextSteps (#886). When setup finishes with problems, it lists each failed step with its fix (#842). On Linux, rig setup --dry-run reports the Homebrew and cmux steps as skipped (#769).
• Startup attention. A seat whose bundled prompt reveals a provider gate, such as Claude's trust dialog, is reported as needing attention instead of ready (#684). A Claude Code seat at the bypass warning reports bypass_consent_gate until you run rig seat continue (#740).
• Claude startup. After delivering a Claude Code seat's startup text, OpenRig sends one short line asking it to run its startup-proof command, so Claude seats reach the oriented state on their own (#719, #743, #747). Startup files delivered later get the same submit check, and staged or unverified startup text now shows as warnings in rig bootstrap, rig import, rig seat launch, restore records and the TUI (#736).
• Claude idle detection. A Claude Code pane is read as idle when update, focus-events or weekly-limit warnings sit below an empty input, in every permission mode; a pane showing live work alongside the mode bar is read as working (#735, #814). A tall question picker is recognised as a waiting question (#745).
• Bundles. Installing a bundle never merges its context pack into an installed pack with the same name; it reports already_installed or kept_existing (#694). rig bundle inspect refuses the same unsafe archive entries install refuses (#695). Every rig bundle create records the configuration ID and the assembling OpenRig version in bundle.yaml (#708). A legacy bundle whose project block escapes its root is refused (#716). A launch where a profile selects a skill from its own agent folder that differs from the managed catalog now uses the selected skill, with a skill_bundle_precedence warning, instead of failing (#720, #722).
• Packages. Installing a package whose manifest gives a skill or agent a name that would write outside the install target is refused before anything is written (#725).
• Pi. A rig with a Pi seat no longer fails preflight when pi isn't on the daemon's PATH; it warns, and the pane's shell finds Pi at launch (#655).
• Oh My Pi. An OMP seat whose model is written anthropic/…, openai/… or litellm/… now also receives that provider's base-URL variable when you allowlist it in recovery.provider_auth_env_allowlist. If you already allowlist ANTHROPIC_BASE_URL or OPENAI_BASE_URL, those OMP seats now send requests there (#744).
• rig down keeps guidance a surviving seat uses. When a seat can't be stopped, its CLAUDE.md, CLAUDE.local.md or AGENTS.md isn't stripped or deleted (#662).
• Service teardown through the API deletes volumes only when the request says volumes: true as a JSON boolean; rig env down --volumes is unchanged (#668).
• rig host pair --timeout caps an infinite or overflowing value at about 25 days instead of waiting forever (#734).
• TUI. A rig spec opens on its graph tab (#867).
• rig seat set-permissions reports a missing identity, mode or reason as three separate errors (#689), and rig seat status prints the permission mode with its source (#680).

Dependency and install-script changes

• npm dependencies: none added, removed or changed. The package's 15 dependency ranges and every external entry in the lockfile are the same as in 0.6.5; only OpenRig's own package versions moved to 0.6.6. As with any npm package, a new install can still pick newer transitive versions within those ranges. The Node requirement is unchanged (node >=22).
• Install scripts: unchanged. The package's only lifecycle script is still postinstall: node scripts/check-abi.mjs, byte for byte the same as in 0.6.5. It checks Node.js and SQLite compatibility and suggests a rebuild if the check fails; it doesn't rebuild anything, start the daemon or set up providers. better-sqlite3 13 is still the native SQLite dependency.
• Building from source: the unchanged lockfile still includes esbuild's postinstall script and the optional macOS fsevents native build, which are used when building OpenRig from source.
• A new install script in the repository, not in the package: scripts/install.sh is an optional wrapper that checks for Node and npm, runs npm install -g @openrig/cli, runs the installed Node.js/SQLite check, then rig setup --dry-run and rig setup, and stops at the first failed step. It isn't part of the npm package and isn't documented yet (#832, #841, #853).
• macOS: to verify a Claude Code process whose name is a version number, the daemon may run the built-in /usr/bin/osascript (#724, #730). Whether macOS shows a permission prompt for it on a Mac that has never approved one hasn't been observed.
• Git: importing a bundle from a GitHub link runs your git with credential helpers, hooks and global config disabled (#708). At launch, OpenRig runs your git to check generated files and may append its marked block to info/exclude (#721, #727).
• Database: one migration, adding the saved non-interruptive choice to rigs (#737).
• Bundled plugin: openrig-core 0.1.4 (#685, #829).

Everything else since 0.6.5

Kernel, setup and first run. rig daemon start --no-kernel and rig start say the operator is skipped too, and how to start it later (#873). Setup's next steps offer the kernel view before you pick a team, and treat declining, SSH and headless use as valid (#859). Shipped help, skills and onboarding use the new team names (#866), and lifecycle help says what stopping or restarting a live team does to its work (#895). The getting-started guide and the agent help guide explain rig seat continue, startup attention, readiness timeouts, Claude's bypass warning and builtin:auto (#779). The README and getting-started say a Linux distribution's own Node.js can be too old and how to install 22 or 24, that npm 11 may skip the postinstall check, and that cmux is optional and macOS-only (#839).

Claude. OpenRig can identify a Claude process running under a shell wrapper with a version number as its name, by its executable path, so restore attention on such seats can be cleared (#724, #730). A seat brought back with rig up --existing keeps its activity hooks (#731), and a restore that can't reapply them now says so (#746). Forking a Claude seat quotes the parent session ID in the launch command (#773).

Codex. Codex seats no longer stall at launch, resume or fork when Codex 0.160 shows its update menu with the new header (#861).

Pi and Oh My Pi. Pi seats keep their daemon routing and seat identity when shell startup files set conflicting values (#666). A Pi seat failing with "No API key found" now says what to set (#667), and Pi flag errors name the Pi version (#655). When OMP exits during startup, the error says how it exited and shows its last stderr lines (#646).

Launch and seats. runtime.readiness_timeout_seconds (1 to 600, default 30) gives slow seats more time to become ready at launch, restore and handover (#643). When rig whoami or rig health --self can't find the seat, the error names the daemon it reached (#660). Requests that carry an X-OpenRig-Diagnostic-Attempt header are traced in the daemon's slow-operation log, to help diagnose inventory timeouts (#726).

Queue and Slack. rig queue block help says --on is always required, and parking on a task this daemon doesn't have suggests an external gate (#664). The query behind the TUI's recent queue activity does less sorting on large histories (#816). Slack gateway state survives a crash in the middle of a write (#669). rig slack status shows the live connection and recovery state (#742).

CLI. rig context add starts a stopped local daemon (#784). rig context sync finds a workspace context-pack folder created after the daemon started (#686). Context packs with .mjs or .py helper files install from the CLI (#706). rig project shadow-drain and shadow-stop take --actor, so they run from a plain shell (#665), and rig project experimental refuses a FIFO instead of hanging (#670). rig capture shows an empty pane as empty (#671). rig mcp serve shuts down when its input ends (#674) and keeps the daemon address it found, including IPv6 (#676). A mission title with : , # or quotes writes valid frontmatter (#768).

Services, terminal and transcripts. rig env logs --tail 0 prints no past lines (#673), and rig env status survives a corrupt cached service receipt (#675). rig terminal open starts tiles with the daemon's own tmux, and with herdr reports a pane that exits at once as degraded (#715). Transcript cleanup applies runs of backspaces correctly (#677).

Skills. rig compact-plan points to the shipped claude-compaction-restore skill, and shipped skills no longer point to skills that don't ship (#683). The bundled skills index sends agents changing OpenRig itself to the developing-openrig skill (#829). The rigs skill, which gives an ordinary Claude Code or Codex session a route into OpenRig, lives in the GitHub repository rather than the package: add it with npx skills add mvschwarz/openrig --skill rigs (#872, #881).

Docs. The developer documentation was refreshed for this release, each claim checked against the code at the time; a final pass against the release commit lands separately. The refresh covers the README, CONTRIBUTING, SUPPORT and SECURITY (#782); the reference pages for specs, projects, bundles, operations and process (#777, #783, #785, #788, #789, #791, #795, #797, #823, #825); and the architecture pages and CLI reference (#775, #778, #781, #787, #790, #792, #793, #794, #799, #804, #805, #826, #856). ARCHITECTURE, DESIGN and the TUI README were updated too (#796, #803, #806). Contributor setup uses npm ci (#714), and the contributor skill asks whether an agent with instructions could do a behaviour before adding code for it, and points to the capability map first (#827, #828).

How it was tested

• The final package: openrig-cli-0.6.6-2620dea8.tgz, 4,077 files, SHA-256 53e815f572bc9f5f331d34848d9cf5fea7828bd781d6e2a774a9778a20a283b2, built from 2620dea8. It was compared file by file with the earlier builds the runs below used (141513eb and a622adaa): the differences are help and guidance text, the operator's role text and the build stamps. The final package itself wasn't put through another journey.
• The final package, installed: into a fresh prefix on Linux x86_64 with Node 22.23.1 and npm 10.9.8. rig --version printed 0.6.6 (2620dea8); the daemon started and its health check reported version 0.6.6 at commit 2620dea8, clean, built 2026-10-07 00:25:05 UTC; rig ps and rig help down ran. No agents were launched in this check.
• A first-user journey on a Linux VPS (build 141513eb, Claude Code 2.1.292, Codex 0.145), with an installing agent that had never seen OpenRig. The person reached the operator, gave the goal once, accepted a recommended mixed Claude Code and Codex workshop with its broad permissions disclosed, saw the team, and the goal reached the ready lead. It passed with findings: the person was guided to attach a terminal five times, which counts as help. It used an earlier workshop revision than the one openrig.dev/rigs lists now. A change was then made and reviewed locally; no pull request was published.
• The current workshop on build 141513eb: its permissions were disclosed before install, and its four seats started non-interruptively from the team's own declaration. This was a startup check, not a full journey, and it doesn't cover the other configurations or Pi.
• The team permission defaults on build a622adaa: ordinary rig, read and test commands ran without prompts on Claude Code 2.1.292 and Codex 0.160.1. The lifecycle confirmation was checked on Claude Code only.
• macOS: an earlier first-user journey ran on macOS with build 5d7d741b, and its findings shaped #890. It wasn't rerun on the final package.
• Text changes: #895 and #900 are text, packaged without a new journey run. #900 tells the operator to read the workshop pin fresh; that a fresh first-user run then finds the current workshop hasn't been reproduced.
• Not tested: the final package on macOS; Codex lifecycle confirmation; Pi and Oh My Pi seats beyond automated tests; live Slack recovery; Windows.

Known issues

• rig setup's permission question describes the older behaviour. Its "No — keep prompts" choice and "If you skip: OpenRig sets nothing" predate the team defaults: a team seat with no permission policy or saved choice still gets the team default at its next launch (see Before you upgrade). To keep prompts for a team, give the rig or member an explicit policy such as permission_policy: none. The setup text is corrected in the next release.
• In a Claude Code team seat, rig down --help asks for confirmation, because the lifecycle ask rule matches it. rig help down prints the same help without a prompt.
• Codex team seats don't yet ask before lifecycle commands such as rig up and rig down. Claude Code team seats do.
• The starter's Codex reviewer needs a Codex newer than 0.145. Its model, gpt-6-astra (the same one 0.6.5's first-project used), is refused by Codex 0.145 with "requires a newer version of Codex". Codex 0.160.1 works.
• Part of the guidance for an agent finishing an install is on openrig.dev's install page, not in the package.
• A restore can report a problem with a seat that works. Several fixes in this release target it, and it isn't fully resolved (#273).
• A claude alias or function defined only in a nushell rc doesn't resolve for classic Claude launches, as in 0.6.5.
• After a reboot the daemon doesn't come back on its own. Start it with rig daemon start, then bring your rig back with rig up <name> --existing.
• The web UI's file preview runs scripts, as in 0.6.5. The web UI is off by default; preview only files you trust.
• Browser access protects against unknown web pages and names. It isn't complete browser isolation, so keep the daemon on loopback or your tailnet.
• Codex network inside the sandbox hasn't been checked with real logins, managed policy bundles or on Linux, as in 0.6.5.
• Setup's optional cmux step can report an error, as in 0.6.5.
• Reinstalling a team into another folder that holds a copy of its installed manifest treats that folder as the team's install folder, so its conflicting files are replaced. They are backed up first and the backup is named. Recording each team's install folder is a separate change.
• Windows wasn't tested.

Thanks

To the people whose pull requests are in this release: @1solomonwakhungu, @adampog, @Coder8124, @dajiaohuang, @DeryFerd, @Nikhi00718, @PowellTravis, @rudycelekli, @shravansumanthanan and @Vaishnavi220506.

And to the people whose reports shaped fixes here: @AdamWhitehurst (#808), @DianaKerim (#519), @gopinathrimc (#728) and @pr0xc3nt4ur1 (#729).