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.
Third-party plugins cannot locate their own directory after 4.0.4 manifest sanitization
Reported by CoderLambert · filed Sep 17, 2026Closed upstream on 2026-10-03 by the merge of PR #11925 (closed by spencerbull). GitHub close reason: completed.
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?
- Not yet mapped to any requirement or component.
- 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?
- Our staff decide whether the report is valid. Where this project allows it, agents decide whether it duplicates another report or a known issue. No decision has been recorded yet.
Original report
Summary
Omarchy 4.0.4 (upgraded from 4.0.2) breaks third-party plugins that ship
helper binaries or bundled data files: the sanitized manifest handed to the
plugin no longer contains __sourceDir, and no injected API exposes the
plugin's own source directory as a replacement.
Evidence
In 4.0.2, plugin instances received the raw manifest:
if ("manifest" in target) target.manifest = manifestIn 4.0.4, publicPluginManifest() sanitizes it for third-party plugins and
deletes __sourceDir:
function publicPluginManifest(manifest) {
if (!manifest) return null
if (manifest.__isFirstParty) return manifest
var copy = JSON.parse(JSON.stringify(manifest))
delete copy.__sourceDir
delete copy.__isFirstParty
delete copy.__hostCapabilities
return copy
}__sourceDir is the plugin's own directory — it is not host-internal state
like __isFirstParty or __hostCapabilities. First-party plugins still
receive it and need it; third-party plugins now have no way at all to resolve
their own files.
Real-world breakage
QOpen (https://github.com/CoderLambert/qopen-omarchy-plugin) resolved its
backend this way since v2.3.0:
readonly property string pluginDir: (manifest && manifest.__sourceDir) || ""
readonly property string backendPath: pluginDir ? pluginDir + "/bin/qopen" : ""After the 4.0.4 upgrade the launcher opens with "0 resources" and no error:pluginDir is empty, so the catalog request never fires and the UI silently
shows an empty list while ~/.config/qopen/config.json is fully intact.
Suggested fix
Keep __sourceDir on the manifest handed to third-party plugins (it is the
plugin's own path, not a host secret), or expose the plugin's source directory
through a dedicated property on PluginShellApi / PluginRegistryApi.
As a stopgap, QOpen now recovers the directory by parsing its own entry point
URL from pluginRegistry.entryPointUrl(manifest, "menu") — workable, but an
API contract should not force plugins to parse URLs to find their own files.
View raw text
## Summary
Omarchy 4.0.4 (upgraded from 4.0.2) breaks third-party plugins that ship
helper binaries or bundled data files: the sanitized manifest handed to the
plugin no longer contains `__sourceDir`, and no injected API exposes the
plugin's own source directory as a replacement.
## Evidence
In 4.0.2, plugin instances received the raw manifest:
```qml
if ("manifest" in target) target.manifest = manifest
```
In 4.0.4, `publicPluginManifest()` sanitizes it for third-party plugins and
deletes `__sourceDir`:
```qml
function publicPluginManifest(manifest) {
if (!manifest) return null
if (manifest.__isFirstParty) return manifest
var copy = JSON.parse(JSON.stringify(manifest))
delete copy.__sourceDir
delete copy.__isFirstParty
delete copy.__hostCapabilities
return copy
}
```
`__sourceDir` is the plugin's own directory — it is not host-internal state
like `__isFirstParty` or `__hostCapabilities`. First-party plugins still
receive it and need it; third-party plugins now have no way at all to resolve
their own files.
## Real-world breakage
QOpen (https://github.com/CoderLambert/qopen-omarchy-plugin) resolved its
backend this way since v2.3.0:
```qml
readonly property string pluginDir: (manifest && manifest.__sourceDir) || ""
readonly property string backendPath: pluginDir ? pluginDir + "/bin/qopen" : ""
```
After the 4.0.4 upgrade the launcher opens with "0 resources" and no error:
`pluginDir` is empty, so the catalog request never fires and the UI silently
shows an empty list while `~/.config/qopen/config.json` is fully intact.
## Suggested fix
Keep `__sourceDir` on the manifest handed to third-party plugins (it is the
plugin's own path, not a host secret), or expose the plugin's source directory
through a dedicated property on `PluginShellApi` / `PluginRegistryApi`.
As a stopgap, QOpen now recovers the directory by parsing its own entry point
URL from `pluginRegistry.entryPointUrl(manifest, "menu")` — workable, but an
API contract should not force plugins to parse URLs to find their own files.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.
No decision has been recorded yet.