Classic Confinement request: jetbrains-toolbox

store-requests classic-confinement
1

  • name: jetbrains-toolbox

  • description: Snap package of JetBrains Toolbox App by JetBrains, used to download, install, update, and manage JetBrains IDEs (IntelliJ IDEA, PyCharm, WebStorm, etc.) across arbitrary user-defined locations on Linux systems.

  • snapcraft: jetbrains-toolbox-snap/snapcraft.yaml at main · jnsougata/jetbrains-toolbox-snap · GitHub

  • upstream: PRIVATE

  • upstream-relation: Independent community maintainer (not affiliated with JetBrains)

  • supported-category: Developer tools

  • reasoning:

    JetBrains Toolbox functions as a meta-manager for full-featured IDEs that are distributed as standalone binaries (not as snaps). Its core functionality requires capabilities that cannot be achieved under strict confinement:

    1. Arbitrary installation paths Toolbox allows users to select custom installation directories for IDEs. These locations may reside anywhere in the filesystem (e.g., /opt, secondary drives, custom mount points). Strict confinement restricts filesystem access to predefined paths and cannot accommodate arbitrary user-selected install locations.

    2. Execution and management of external, non-snap binaries Toolbox downloads and launches IDE binaries that live outside the snap sandbox. These IDEs expect unrestricted filesystem access for development workflows. Strict confinement prevents reliable execution and updating of such externally managed applications.

    3. System integration requirements Toolbox performs integration tasks such as:

      • Creating desktop entries
      • Installing command-line launchers (e.g., into /usr/local/bin or user-specified paths)
      • Managing local caches and configuration outside $SNAP These operations exceed what available interfaces (including home, removable-media, and system-files) can reasonably provide.

    4. Developer workflow compatibility The IDEs managed by Toolbox require broad access to arbitrary project directories, mounted volumes, container paths, SDK installations, and toolchains. Constraining filesystem visibility would break common development setups and defeat the purpose of the application.

    5. Upstream design expectations Toolbox is distributed upstream as a traditional tarball application designed to run with standard user-level system access. Strict confinement would significantly alter expected behavior and prevent normal operation.

    Because Toolbox effectively acts as a package manager and launcher for non-snap development tools, strict confinement cannot provide sufficient access without fundamentally breaking its functionality.

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.

2

This request has not been added to the review queue. It should be placed in the appropriate store-requests subcategory using the subcategory template for classic-confinement, privileged-interfaces and aliases requests.

3

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

4

@yomonokio Any updates or a tentative ETA on this? Just checking in to see if you need any further info from my side.

5

Hey @jnsougata

I think this snap does not fit in the supported categories defined in Process for reviewing classic confinement snaps. Moreover, 3rd party installer snaps (eg, for native packages, appimages, flatpaks, snaps, etc) are explicitly unsupported.

In addition, classic confinement is a sensitive matter and it is reserved for mature, well-known applications published by mature, well-known entities. Part of the criteria is that the snap must be published by the upstream project or one of the trusted groups listed in Process for performing Snap Publisher Vetting

For the reasons mentioned above, we cannot proceed with this request right now (#reject)