Why classic confinement is required — technical justification:
AppImage execution inside the snap — HARBOUR AI is packaged as an Electron AppImage. AppImages
require the ability to mount and execute from arbitrary paths. Strict/devmode confinement blocks the
FUSE mount that AppImage relies on, making execution impossible under any confinement other than
classic.
Electron renderer process — Electron’s Chromium renderer requires access to system libraries and
GPU/display subsystems that are not fully accessible under strict confinement, even with all
available plugs applied.
Local AI model inference via Ollama — The application communicates with Ollama, a system-level
service that the user installs separately. Strict confinement cannot reach a system socket outside
the snap’s mount namespace without classic.
User filesystem access — The backend writes to the user’s home directory (~/.harbouai/ and
adjacent paths) to store the local SQLite database, knowledge graph, uploaded documents, and audio
transcripts. This is core to the product — all data is stored locally by design. Strict confinement’s
home plug does not provide the breadth of access required across all supported distros and
configurations.
Comparable precedents — Other Electron-based snaps with similar requirements use classic
confinement: code (VS Code), slack, discord, electron-mail. HARBOUR AI falls into the same category.
Confirmation of legitimacy:
The application is a genuine desktop productivity tool with a commercial licence
It passed an independent penetration test (June 2026)
It is also distributed via AppImage, .deb, Windows EXE/MSIX, and the Microsoft Store
Build pipeline available on request
I’m happy to provide any further information needed. Thank you.
As I wrote in your other request, please see the requirements for classic confinement on:
Is completely forbidden under our rules for classic confinement (see the list of unsupported use cases on the page linked above, particularly “3rd party installer snaps”)
Either use the opengl interface natively to get access to all the hosts GPU features or make your snap use the GPU content snap to get a snapped variant of these libs and drivers
This should simply go into $SNAP_USER_DATA where you can also access the socket just fine
If your snap can not directly use $SNAP_USER_DATA (like pretty much any other snap does today) you can use the personal-files interface to gain access to something like ~/. harbourai
Please use the snappy-debug tool against your strictly packaged snap first to get proper interface suggestions for all the limitations you list above…
Also note that other electron snaps you point to in your request have not been granted classic because of being electron based but because they did fit one of the supported categories (which your app doesn’t seem to) from the above liked page, the majority of electron snaps in the store is strictly confined …
As already pointed out, this snap unfortunately falls under the unsupported categories mentioned in our Classic Confinement Documentation, so we cannot approve classic confinement at this time (#reject).
We highly recommend following the steps provided by @ogra to get your snap up and running smoothly under strict confinement.
If you run into any issues or need further assistance along the way, please don’t hesitate to ping us here