Classic confinement for Snap `comate`


  • name: comate

  • description: ​Comate IDE is an AI-powered coding assistant that supercharges development. It combines smart code completion, debugging and agent with a lightweight editor for faster, smarter programming.

  • snapcraft: https://now.bdstatic.com/stash/v1/67aafc6/zhangtianhang01/dfa8f07/snapcraft.yaml

  • upstream: ‘PRIVATE’

  • upstream-relation: I am the core developer and maintainer of the Comate project.

  • supported-category: IDEs

  • reasoning: ​Comate requires classic confinement because, as a VS Code-based development tool, it needs deep integration with the system environment—including access to system toolchains (e.g., compilers, debuggers), dynamic library loading (e.g., GTK/GLib), and support for user extensions that execute external commands. The strict confinement sandbox would block these essential functions: path isolation breaks library dependencies, permission constraints prevent extensions from calling system tools, and file access restrictions degrade development efficiency. We have attempted strict confinement and used snappy-debug for adjustments, but critical issues—such as dynamic toolchain integration and system binary execution—remain unresolved. Therefore, classic confinement is necessary to ensure full functionality and a seamless development experience.

[√] I understand that strict confinement is generally preferred over classic.

[√] I’ve tried the existing interfaces to make the snap to work under strict confinement.

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

Hello @commit6!

comate fits under the category IDEs. The requirements for classic are understood.

However, since this is a private repo and there is no way to verify for us, the way forward is to get your account verified is through the Verified Accounts process. Once that’s completed, we can proceed with granting classic confinement.