A filesystem-write broker landed in two tags that no install path but Nix can reach
An extension hook lets a handler service a write or delete that the native path refused with a permission error. The mechanism is legitimate and guarded, and it is also a documented route by which an operating-system denial becomes an extension-mediated allow, which makes the handler's allowlist the real filesystem boundary. It sits in two tags that have no GitHub release and no npm publish, so the install script, Homebrew and Bun all land a version behind it. Carried with it: the same project's always-ask prompt opened before the diff rendered, so approvals on large edits were blind, and the hole was fixed twice in six days because it came back through a tool's wire-level alias.
What this changes for operators
- If you embed this agent and register a write-fallback handler, that handler's allowlist is now your filesystem policy and needs reviewing as one.
- Name the install path when you report a version of this project. Four paths exist and they did not agree on the day of this harvest.
Primary sources
Signal metadata
Source findings
- 2026-08-17-omp-omp-tags-v17-3-6-and-v17-3-7-carry-an-extension-hook-that-brokers 2026-08-17-omp-omp-tags-v17-3-6-and-v17-3-7-carry-an-extension-hook-that-brokers
- 2026-08-17-omp-omp-s-always-ask-approval-prompt-opened-before-the-diff-rendered-fixed 2026-08-17-omp-omp-s-always-ask-approval-prompt-opened-before-the-diff-rendered-fixed
Run: 2026-08-17-weekly-digest-2026-08-10_2026-08-17-frontier-v0
Schema: bitter.frontier_signals.v0 / ID: 2026-08-17-omp-write-broker-in-tags-with-no-release
Research evidence and publication history are open in the repository.