Skip to content

Reject disabling unknown plugin IDs in PluginRegistry - #11134

Open
sanjyay wants to merge 1 commit into
omacom:quattrofrom
sanjyay:fix/plugin-disable-unknown
Open

Reject disabling unknown plugin IDs in PluginRegistry#11134
sanjyay wants to merge 1 commit into
omacom:quattrofrom
sanjyay:fix/plugin-disable-unknown

Conversation

@sanjyay

@sanjyay sanjyay commented Sep 10, 2026

Copy link
Copy Markdown
Contributor

What

Guard PluginRegistry.setEnabled against plugin IDs that have neither an installed manifest nor an entry in the active shell configuration when disabling.

Why

PluginRegistry.setEnabled previously only checked for a manifest when enabling (value == true). When disabling a plugin ID with a typo or one that does not exist, the function skipped the guard, made no modifications in shellConfigMutator, but still incremented registryRevision, emitted pluginsChanged, and returned true.

As a result, shell.qml's setPluginEnabled returned "ok" instead of "unknown", and omarchy plugin disable <id> falsely reported success.

With this check, disabling an ID with neither a manifest on disk nor a location in shell.json returns false, while disabling an uninstalled ghost plugin that is still listed in shell.json continues to clean up the configuration entry.

Testing

  • Added test/shell.d/plugin-disable-test.sh covering omarchy plugin disable success, unknown plugin failure, omitted argument, and --help.
  • Added contract assertions to test/shell.d/fixtures/plugin-registry/shell.qml for unknown plugin disable refusal and uninstalled ghost entry cleanup. Verified that reverting the fix causes contract test failure (sabotage check).
  • Validated with qmllint shell/services/PluginRegistry.qml and bash -n test/shell.d/plugin-disable-test.sh.
  • Ran related test suites: plugin-registry-contract-test.sh, plugin-enable-test.sh, plugin-clone-test.sh, plugins-test.sh, plugin-add-test.sh, plugin-validate-test.sh, menu-plugin-test.sh, bar-test.sh, and ./test/cli.
  • Verified in the Omarchy-in-Omarchy development environment (omavm):
    • Reproduced the original bug on a clean boot from snapshot fresh: omarchy plugin disable totally.made.up exited 0 and printed Disabled totally.made.up, and omarchy-shell shell setPluginEnabled totally.made.up false answered ok.
    • Pushed the candidate branch code to /usr/share/omarchy/shell/services/PluginRegistry.qml and restarted the shell.
    • Verified that omarchy plugin disable totally.made.up now exits 1 with plugin 'totally.made.up' is not known; run: omarchy-shell shell rescanPlugins, and raw IPC returns unknown.
    • Verified normal disable and re-enable of real installed plugins (omarchy.agents).
    • Verified ghost plugin cleanup: injecting an uninstalled plugin into shell.json is cleaned up on the first disable call, and subsequent calls correctly fail with plugin is not known.

Related issue

Fixes #11119

PluginRegistry.setEnabled previously only checked for a manifest when
enabling (value == true). When disabling an unknown plugin ID that has
neither an installed manifest nor an entry in shell.json, the function
proceeded through shellConfigMutator without finding any entries to remove,
bumped registryRevision, emitted pluginsChanged, and returned true.

setPluginEnabled in shell.qml therefore answered "ok" instead of "unknown",
causing omarchy plugin disable <typo> to falsely report success.

Guard disabling against plugin IDs that are neither installed nor present
in the active shell configuration, while preserving config cleanup for
uninstalled ghost plugins.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

setPluginEnabled answers ok for an unknown plugin id, so omarchy plugin disable <typo> reports success and does nothing

1 participant