DSCODE 0.7.46

DSCODE 0.7.46

DSCODE now ships self-contained packages for 64-bit glibc Linux, installed and updated the same way as on macOS.

Linux packages

Since 0.7.41 the terminal has shipped only as macOS archives, and install.sh stopped on Linux with Self-contained packages currently support macOS only, although the code itself already ran there under the required Linux e2e workflow. Releases now also carry dscode-<version>-linux-x64-standalone.tar.gz and dscode-<version>-linux-arm64-standalone.tar.gz. Each bundles the official Node 24.21.0 Linux build, verified against checked-in SHA-256 hashes, together with the pinned Harness, compiled TUI, plugins and the Linux prebuilds of node-pty, the system addon, sharp, koffi and ripgrep. No system Node, npm or DSH is required.

The curl installer reads uname to select macOS or Linux and arm64 (arm64/aarch64) or x64 (x86_64/amd64). On Linux it requires glibc, checked with getconf GNU_LIBC_VERSION, and refuses musl systems such as Alpine before downloading anything. It verifies the checksum with shasum or, where that is absent as on minimal Debian images, sha256sum. The launcher, installer and updater resolve their system tools from /usr/bin or /bin, so distributions without a merged /usr work too. dscode update already selected assets by platform name and needs no change; installations, data paths and the update/rollback flow are identical to macOS.

npm run dist now builds all four platforms. Linux archives are cross-built on macOS without running install scripts, so they rely on each dependency's published prebuilds. DSCODE_PREBUILT_PLATFORMS selects a subset, and the older DSCODE_PREBUILT_ARCHS still selects macOS builds.

Behaviour stops there. Commands run under bubblewrap, falling back to Landlock; when neither is usable, sandboxed commands are refused rather than run unconfined, so install bubblewrap. Clipboard image paste, Computer Use and the Desktop package remain macOS-only, dscode trigger install prints a crontab line instead of loading a launchd agent, and Homebrew covers macOS only. The musl variants of sharp are still included in Linux archives, because the lockfile does not record a libc for npm to filter on; they are unused and only add size.

Release and e2e qualification

Release CI keeps building every candidate on macOS and now qualifies the Linux archives on native ubuntu-24.04 and ubuntu-24.04-arm runners with the same verify-standalone.mjs used for Intel macOS. Publication requires all four platforms to pass, and the publish step checks that each Linux archive exists. The Linux e2e workflow gains a step that builds and qualifies the package for its own container on every pull request, and its image moves from Node 22 to Node 24 to match the macOS checks and the bundled runtime.

Verification

Locally, both Linux archives were cross-built on macOS and qualified with verify-standalone.mjs in Debian bookworm containers: linux-arm64 natively and linux-x64 under amd64 emulation. Each passed all eleven checks, including the private runtime, native imports and PTY, cold profile composition, Host diagnostics, runtime isolation, the local shell installer and full-archive replacement. In a fresh container without shasum, curl … | sh against a local release fixture downloaded, verified and installed the arm64 package for an unprivileged user, and the TUI started and rendered in a pseudo-terminal. npm run test:e2e passed all eight steps in 5.1 minutes on Node 24 linux/arm64, including the new package step. node --test tests/standalone-install.test.mjs covers the Linux, aarch64, musl and unsupported-system installer paths; npm run test:unit, node scripts/check-docs.mjs and npm run lint passed after the documentation changes.

Linux x64 on real hardware, the native Linux release runners and public publication are established only by release CI. Distributions other than Debian bookworm, a Landlock-only sandbox, and live model calls from a Linux package have no automated case.