Signals

2026-09-21 / omp

In OMP, the repository you open can write the policy that governs it

Edited by Michael Ruescher

At v18.2.8 OMP's extension types say project-local .omp/config.yml and .omp/extensions "are already discovered and loaded unconditionally" and that isProjectTrusted "always returns true"; the approval docs list yolo as the default mode and project config above global config in precedence. A Pi extension that consults Pi's per-directory trust gate is told the project is trusted. v18.2.1 (2026-09-15) closed a cluster of approval bypasses, including a tool run with no approval context being treated as approved, and a view-only collab link that could steer a session after the host reconnected. None got an advisory.

What this changes for operators

  • Do not open an untrusted repository in OMP. Inspect .omp/config.yml, .omp/extensions and package.json omp.extensions or pi.extensions in any clone first.
  • Upgrade to v18.2.1 or later for the approval and collab fixes. Do not reuse a Pi extension’s trust check as a guard under OMP. This is a fact about OMP; Pi has had a trust prompt since June.

Signal metadata

Source findings

Featured in

Run: 2026-09-21-weekly-digest-2026-08-20_2026-09-21-frontier-v0

Schema: bitter.frontier_signals.v0 / ID: 2026-09-21-omp-the-repository-writes-the-policy

Research evidence and publication history are open in the repository.