Linuxbrew package mirror: updater and AppImage sandbox policy

[t8d7]

I'm working on an external Linuxbrew cask for T3 Code:

• uBlue Homebrew tap draft PR: [WIP] Add T3 Code Linux cask ublue-os/homebrew-tap#585

This is not a request to add another Linux artifact to T3 Code's release pipeline. The cask uses the official x86_64 AppImage, verifies its checksum, extracts it once during brew install, and installs a launcher, desktop entry, and icon. That seems consistent with the project's preference for externally maintained package mirrors.

The motivation is that some uBlue/GNOME OS-derived systems do not provide all of the runtime prerequisites expected by AppImages. This is not based on an assumption that uBlue will remove AppImage support; it gives those systems a package-manager-managed path that does not depend on AppImage execution being available in the base OS. The uBlue tap also explicitly calls out important AppImages that need conversion as part of its scope.

I would appreciate guidance on two integration details before the cask is finalized.

Update ownership

T3 Code supports T3CODE_DISABLE_AUTO_UPDATE=1. The Linux updater otherwise downloads another AppImage, which is not the desired update path for a Homebrew-managed installation. The proposed cask will set this variable explicitly and rely on brew upgrade --cask t3-code-linux instead.

Is T3CODE_DISABLE_AUTO_UPDATE=1 intended to be a stable interface for external package maintainers?

Chromium sandbox policy

The current AppImage's desktop entry launches:

AppRun --no-sandbox %U

However, the bundled AppRun already probes unshare -Ur true and adds --no-sandbox only when unprivileged user namespaces are unavailable. T3 Code's build configuration does not appear to add the unconditional flag itself; it appears to come from electron-builder 26.15.6's AppImage default. electron-builder 27 changed this behavior to rely on the conditional AppRun check.

The cask currently removes the unconditional desktop-entry flag, leaving AppRun's compatibility check in control. In a Dakota/Bluefin GNOME OS VM, that path launched successfully without a global --no-sandbox flag, and the Chromium child process used separate user/PID namespaces with seccomp enabled.

Is the unconditional --no-sandbox flag an intentional T3 Code compatibility policy, or would the conditional behavior be preferable upstream too? If conditional behavior is preferred, electron-builder 26 can be overridden with linux.executableArgs: [], or the project could pick up electron-builder 27's new default when otherwise ready to upgrade.

The answer will help the external cask match upstream's security and compatibility intent instead of just guessing.

Related context:

• AppImage FUSE/sandbox report: AppImage fails on Ubuntu 24.04+ (requires manual apt install and use of --no-sandbox) #1482
• Maintainer guidance favoring external package mirrors: feat(packaging): add deb and rpm desktop targets #5139 (comment)
• Earlier discussion that specifically mentioned extending Homebrew support to Linux: feat(release): publish a Linux .deb alongside the AppImage #4887 (comment)