Classic confinement request — harbour-ai (Electron/AppImage, local AI platform)

Why classic confinement is required — technical justification:

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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 …

1 Like

This request has been added to the queue for review by the @reviewers team.

Hello @loosekeyz,

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 :slight_smile: