cinnamon-spices-applets is the reviewed catalogue of Cinnamon applets

A catalogue where the review is the product

This repository hosts all the applets available for the Cinnamon desktop environment. Users can install spices from the Cinnamon Spices website, or directly from within Cinnamon and then System Settings.

What makes it more than a folder of scripts is stated in the section on self-containment. These repositories exist so that third-party developers can publish their spices and users can install them safely. When a spice is hosted here, it is reviewed when it is added and again on every update, and the maintainers are able to watch for security and safety problems in the code. The README is explicit that this oversight is the whole reason the Spices repositories and the website exist, and that it is what lets users install spices with confidence.

That framing has consequences for everyone involved. For a user, the guarantee is that the code you are about to run has been looked at by someone other than its author. For a developer, publishing here means submitting to that review, and the README says submissions are not accepted if they break the self-containment rules.

The scale is visible in the directory listing. There are applets such as AlwaysOn, AutostartPrograms, BgRadio, Bps, CassiaWindowList, Cinnamenu, CustomApplicationsMenu, Exit, FM-Radio, Gears, GraphicalSystemMonitor, IntelTurboBoost, MessagingMenuV3, MonitorInputSource, NightLightSwitch, PDFManager, ProcessMemoryMonitor, Radio3.0, ScreenLocker, ScreenShot, Sensors, SettingsPlus, ShellTools, ShutdownApplet, SpiceSpy, SpicesUpdate, ThemeRefresh, VPN-Sentinel, airaware, anime-wallpaper, any-alarm, app-drawer, app-launcher, auto-dark-light, backgroundroll, bash-sensors, battery-view, batterymonitor and batterypower, among many more. The naming convention carries the author, with a UUID directory followed by an at sign and the author's handle, and the license is GPL-3.0.

The last push was on 2026-10-19 and the repository publishes no GitHub releases, which fits a catalogue that is updated by pull request rather than by version.

The UUID directory convention, and why the payload sits one level down

Each spice has a UUID, a name that uniquely identifies it, and the layout is fixed. The README describes the structure as UUID/info.json, UUID/screenshot.png, UUID/README.md, and then UUID/files/ containing UUID/metadata.json, UUID/applet.js and UUID/icon.png.

There are two directories that matter, and the distinction is the part that trips people up.

UUID/ is the root level directory, and it includes the files used by the website and on GitHub. UUID/files/ represents the content of the ZIP archive that users download from the website or that is sent to Cinnamon when installing the spice from System Settings, and this is the content interpreted by Cinnamon itself.

The nesting inside files/ is the subtle part. The content of the spice is not placed inside UUID/files/ directly but inside UUID/files/UUID/ instead, and the README explains that this guarantees files are not extracted directly onto the file system but placed in the proper UUID directory.

The presence of that UUID directory inside files/ is not actually needed by Cinnamon, which creates it if it is missing, but it is needed to guarantee a proper manual installation, that is, when users download the ZIP from the Cinnamon Spices website.

And the rule that follows from all this is strict: the UUID/files/ directory has to be empty, which means it should contain only the UUID directory, or else the spice will not be installable through System Settings.

So the structure is not cosmetic. A spice that is otherwise perfect will be rejected by the installer if it has an extra file in the wrong place.

info.json, a screenshot, and a README that may be optional

At the root level, the files carry the metadata and the human-facing description.

info.json contains information about the spice, and the README gives the example that matters most for a contributor: this is the file which contains the GitHub username of the spice's author. It is also where the author field changes hands later on.

screenshot.png is a screenshot of the spice in action, and it is what the website shows.

README.md is optional and can be used to show instructions and information about the spice, and it appears both on GitHub and on the website.

That trio is the whole of the required root content, and the optionality of the README is the one detail worth pausing on. A spice without a README still installs and still appears in the catalogue, which tells you that the review is focused on the code rather than on documentation. It also means the user-facing instructions are at the discretion of the author, and an applet with a settings screen and no explanation of what it does is entirely possible.

The author and UUID rules sit alongside this in the definitions section. Each spice is given a name which uniquely identifies it, and that name is their UUID and it is unique. Each spice has an author, and the GitHub username of the author is specified in the spice's info.json file.

So the identity of a spice in this system is a directory name, and the person behind it is a field in a JSON file inside it. That combination is what makes handover possible.

validate-spice and test-spice are the contributor's tools

The repository ships two scripts, and between them they cover the whole contributor loop.

Validation comes first. To check if a spice with a UUID satisfies the requirements, run the validate-spice script in the repository:

./validate-spice UUID

Local testing comes second, and it exists because there is no quick way to try a change in a live Cinnamon install. To facilitate easier testing of applets locally, run the test-spice script, which validates and then copies a spice with a UUID:

./test-spice UUID

The same script has two other modes. Skipping validation, which the README marks as not recommended, and then copying a spice:

./test-spice -s UUID

And removing all locally installed development copies of spices:

./test-spice -r

The cleanup mode exists because of the last note in that section: local copies of spices for development and testing purposes have a devtest- prefix attached, for easier identification and cleanup. So a test install is deliberately distinguishable from a real one, and there is a supported way to remove every one of them at once.

That is a good design detail to note. Most plugin systems of this kind leave you with a directory of copies you have to remember to delete, and here the naming convention and the cleanup flag exist together for that reason.

The repository also carries a validation workflow badge in its README, named Validate spices, which is the continuous integration counterpart of the same script.

Authors must keep the applet self-contained and reviewable

The author conditions in the README are the real specification of what may be submitted.

An author is in charge of the development of the spice, and may modify it under conditions that are worth reading closely. They need to respect the file structure and workflow defined in the repository. They cannot introduce malicious code or code which would have a negative impact on the environment. They cannot direct users to install code or functionality from outside the Spices ecosystem. They cannot ship pre-compiled blobs, besides icons and images, nor any code which is not open source, nor source code for binary compiled languages, other than something like GLSL. And settings should be maintained with Cinnamon's xlet settings interface, with no GSettings schemas and no directly editing Cinnamon's JSON files.

The self-containment section explains the reasoning in more depth. Anything a user installs from outside these repositories is outside the review and outside the maintainers' control, so authors may not direct or encourage users to download additional code, plugins, add-ons or an enhanced, full or pro version from anywhere outside the ecosystem. A spice may not fetch and execute code from external sources at runtime. It may not withhold or disable features in the published version to push users towards an externally hosted one. And it may not use the spice, its README, screenshots or settings to advertise or link to such downloads. The README says this applies regardless of whether the external version is paid or free, and that the point is not money, and that everything a user runs should be the code that has been reviewed and published here.

The AI-assisted coding section is also notable. All submissions may be subject to AI code review as well as human review, and contributors coding with an AI tool are told to use the review agent's instructions in .github/copilot-instructions.md as a context guide, to perform their own code review based on it before submitting, and that a human should read it as well.

A system where the machine reviews the machine's output before a human looks at it is an unusual arrangement, and it is a good one to know about before you submit.

Handover, abandonment and the original_author field

The last part of the README covers what happens when a developer leaves.

Authors are able to accept or refuse changes from other people which modify the features or the look of their spice. That is a strong statement of ownership, and it matters for anyone thinking about contributing to an applet they do not own.

Authors may choose to pass on development of their applet to someone else, and in that case the author field in UUID/info.json will be changed to the new developer and the original_author field will be added to give credit to the original developer. So a handover is recorded in metadata rather than in a rename, and the history of an applet stays visible in its info.json.

If an author abandons their applet, the Linux Mint team will take over maintenance of the applet or pass it on to someone else. Several factors are used to determine if an applet is abandoned, including prolonged activity, failure to respond to requests, and serious breakages that have occurred due to changes in API, and the README asks that anyone planning to abandon an applet notify the maintainers so they do not have to guess.

That is a governance section rather than a technical one, but it is the part of a shared catalogue that determines its long term health. A repository of applets maintained by whoever wrote them needs a rule for the ones whose authors disappear, and this one has a written one, with a named field to record the transition.

The repository listing also shows the supporting infrastructure, a .translation-tables directory for the translation work, a COPYING file and a LICENSE, and a .github directory that holds the review agent instructions the AI-assisted section points to.

Editorial conclusion

Cinnamon users who want a vetted applet rather than an arbitrary script should install from this repository, and developers who want their applet in front of that audience should follow the structure and validation rules here, because the review is what makes the catalogue safe. It is the wrong place for a project that needs to fetch code, ship binaries or depend on software that is not packaged for the user's distribution, since those are explicitly ruled out. Before submitting, run validate-spice against your own UUID, read the author conditions in the README, and check that your settings use the xlet settings interface rather than editing Cinnamon's JSON directly.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. linuxmint/cinnamon-spices-applets on GitHub
4. Project website
5. README