Omarchy plugin security: the pitfalls that get plugins blocked

This is a field guide distilled from the marketplace's own review history: all 5,130 submission issues in omacom/omarchy-plugin-marketplace (July to September 2026) and the roughly 5,500 review comments on them. The marketplace's security review is performed by an AI review agent run by the maintainer, which reads the full tree at the exact commit; the static baseline scanner is separate and much narrower. "Reviewer" below means that agent. Every pitfall below was a real blocking finding, most of them many times over. The counts are approximate numbers of review comments raising that point, so you can see what the reviewers actually spend their time on.

Read it before you write the plugin, not after the first needs-fixes. Every review round costs about a day, and reviewers re-read the whole tree on every push, so new findings appear after the first fix. Harden everything before the first submission.

The goal of this skill is that a plugin passes review on the first round.

The reviewer's threat model in five sentences

Understand these and most of the rules below become obvious.

1. The plugin runs inside one long-lived, shared process. omarchy-shell is Quickshell and it hosts every widget. Anything that makes it allocate without bound, block, or fetch a URL affects the whole desktop, and it is "the one process on the desktop that should not be stoppable by a file".
2. Everything you did not type yourself is input. API responses, MPRIS metadata, window titles, device names, filenames, notification bodies, clipboard, hyprctl output, settings and state files, and the output of your own helper script. A window title is set by a web page. A USB stick sets its own product string.
3. Another process running as the same user is in scope. Any sandboxed app, browser tab or other plugin can plant a symlink, a FIFO or an oversized file at a predictable path, read /proc/<pid>/cmdline, or connect to your socket. A 0700 directory does not remove that boundary. (Since 4 September 2026 pure same-UID availability issues are classed as hardening rather than blockers, but reviewers still ask for the fixes and everything involving secrets, privilege or remote data still blocks. Do them anyway.)
4. The check must be bound to the object you use. A pathname test followed by a second open is a race. A byte cap applied after the data is in memory is "a consumer-after-allocation guard". A fix that moves the problem one layer over is called out as "the boundary moved rather than closed".
5. Documentation is not mitigation. A README sentence, a warning, a comment, or a prompt instruction to an LLM never substitutes for code. A README claim the code does not honour is itself a finding, in both directions: a README that promises a protection the code lacks, and a README that describes weaker or different behaviour than the code has ("trust on first use" in the README while the code demands an explicit pin). Reviewers verify the mechanism and treat the mismatch as the defect.

Two things reviewers say constantly: "This finding does not state that the plugin is malicious", and "Verification applies only to this exact snapshot and is not a security audit". Do not argue intent; fix the mechanism.