Proof Portal
Omarchy
ProbeLabs65 findings · 95 requirementsA proof layer — requirements, tests and verified fixes — for two of Omarchy's subsystems: the application menu (launcher scripts, QML model, JSONC config, search and selection) and the lock screen (lock scripts, QML, PAM authentication). Scope is deliberately limited to those components of omacom/omarchy; the rest of the distribution is not covered.
Plugin sandboxing (4.0.3): no opt-in for embedding-style plugins to read other plugins' manifests
Reported by dbgoodm · filed Sep 13, 2026 · open at source
At a glance
- 1 · What is claimed?
- Only the report text below — no validator has restated it as checkable claims yet.
- 2 · What does it affect?
- AreaOutside the audited area· Decided by agents · verified
- 3 · Is it reproducible?
- No validation has been run yet.
- 4 · What remains unclear?
- Not validated yet: no claims, no reproducer.
- 5 · What happens next?
- Decided by agents and verified by a second, independent agent — see the decision.
Original report
4.0.3 plugin sandboxing has no opt-in path for embedding-style plugins to read other plugins' manifests
Related: https://github.com/grigoryshulga/omarchy-side-panel/issues/2
Since 4.0.3, pluginShellFor(manifest) only attaches the real shell.pluginRegistry (with installedPlugins, __sourceDir, etc.) when manifest.__isFirstParty is true. Every third-party plugin gets createScopedPluginShell()'s PluginShellApi instead, which has no pluginRegistry property under any capability profile — confirmed by dumping its live property list at runtime (pluginId, appLibrary, bar, barConfig, idleConfig, serviceFor, mutateShellConfig, ...).
That's a reasonable default (a plugin shouldn't casually be able to read every other installed plugin's source path), but it leaves no path at all for a legitimate use case: a plugin whose whole purpose is to host other plugins' panels (e.g. omarchy-side-panel, which reads another plugin's manifest + entryPoints.barWidget to adapt its Panel.qml into an embedded view). Before 4.0.3 this worked; now canAdapt() fails for every single item, unconditionally, regardless of which plugin or which bar is active.
Ask
Some sanctioned, explicit opt-in for this class of plugin — e.g. a manifest.json field like "hostCapabilities": ["read-plugin-registry"] that a plugin declares up front (so it's visible/auditable at install time, same spirit as Chrome extension permissions) and that pluginShellFor()/createScopedPluginShell() check before deciding whether to attach a (possibly read-only, public-fields-only) pluginRegistry to the scoped API.
Happy to help test this if there's appetite for it — I already have a small local patch to omarchy-side-panel ready to go once there's a supported way to get this access back.
View raw text
## 4.0.3 plugin sandboxing has no opt-in path for embedding-style plugins to read other plugins' manifests Related: https://github.com/grigoryshulga/omarchy-side-panel/issues/2 Since `4.0.3`, `pluginShellFor(manifest)` only attaches the real `shell.pluginRegistry` (with `installedPlugins`, `__sourceDir`, etc.) when `manifest.__isFirstParty` is true. Every third-party plugin gets `createScopedPluginShell()`'s `PluginShellApi` instead, which has no `pluginRegistry` property under any capability profile — confirmed by dumping its live property list at runtime (`pluginId, appLibrary, bar, barConfig, idleConfig, serviceFor, mutateShellConfig, ...`). That's a reasonable default (a plugin shouldn't casually be able to read every other installed plugin's source path), but it leaves no path at all for a legitimate use case: a plugin whose whole purpose is to *host* other plugins' panels (e.g. [omarchy-side-panel](https://github.com/grigoryshulga/omarchy-side-panel), which reads another plugin's manifest + `entryPoints.barWidget` to adapt its `Panel.qml` into an embedded view). Before 4.0.3 this worked; now `canAdapt()` fails for every single item, unconditionally, regardless of which plugin or which bar is active. ### Ask Some sanctioned, explicit opt-in for this class of plugin — e.g. a `manifest.json` field like `"hostCapabilities": ["read-plugin-registry"]` that a plugin declares up front (so it's visible/auditable at install time, same spirit as Chrome extension permissions) and that `pluginShellFor()`/`createScopedPluginShell()` check before deciding whether to attach a (possibly read-only, public-fields-only) `pluginRegistry` to the scoped API. Happy to help test this if there's appetite for it — I already have a small local patch to `omarchy-side-panel` ready to go once there's a supported way to get this access back.
Validation
Not checked yet. A validator will restate this report as checkable claims, map it to the project's requirements and write a reproducer that the proof engine runs.
Linked
Not linked to any known issue, other report or change yet.
Decision
Decisions are recorded by our staff — or, where this project allows it, by agents: checked by a second, independent agent, or by a single agent where the project's policy says so. Any decision reached so far is shown below.
- Out of scopeDecided by agents · verified · 2026-10-09 12:35 UTC