Repository navigation
Conversation
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
ApprovabilityVerdict: Approved at Macroscope's review found this PR approvable — Clarifies the Linux update message so AUR and other package users know to update using their installation tool. Automatic-update eligibility and behavior are unchanged. You can add or adjust custom eligibility rules. Learn more. |
|
No actionable comments were generated in the recent review.
|
| Layer / File(s) | Summary |
|---|---|
Update eligibility message apps/desktop/src/updates/DesktopUpdates.ts |
When Linux is detected without an AppImage or .deb package, the disabled reason now directs users to update other installations with their installation tool. |
Estimated code review effort: 1 (Trivial) | ~4 minutes
Change: Other
Possibly related PRs
- pingdotgg/t3code#27644: Updates Linux package detection and the disabled-update message in
DesktopUpdates. - pingdotgg/t3code#13575: Introduces Linux
.debupdate eligibility and the related disabled-update message.
Suggested reviewers: t3dotgg
Merge Risk: 
Minimal · up to d910c
-
No actionable merge-blocking risk remains in this copy-only update.
Pre-merge checks: 
4
Finishing Touches
-
Generate unit tests (beta)
-
- Create a new PR
-
- Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Usage-based review receipt
- Mode: Continue automatically
- Reviewed files: 1
- Charged: $0.25
- View usage details
Note
This review was completed with usage-based billing: files reviewed beyond your plan's included limits are billed at $0.25/file. View usage-based billing.
Problem
On Linux, Settings > About says "Automatic updates on Linux require the AppImage or the .deb package." when the app is packaged but has neither
$APPIMAGEnor the .deb marker. The AUR packages hit this case: their PKGBUILDs download the official AppImage, extract it, and launch the extracted payload. So AUR users read that they need the AppImage, when the AppImage is exactly what they installed. The message doesn't tell them what to do instead.Change
Only that one reason string changes. It now says that automatic updates work only for the AppImage and .deb downloads, and that other installs, such as AUR packages, update with the tool that installed them.
The code still checks the same two signals,
$APPIMAGEand the .debpackage-typemarker. The new text names AUR packages only as an example, so it makes no claim the code can't back up. Update enablement and every other disabled reason stay the same.Scope and approval
This is a very small fix for misleading copy, with no behavior change, so it qualifies without a prior issue. I kept it to the copy and added no package detection. #13178 had per-package-manager messages and was folded into #13177, and #13575 replaced that PR and shipped without them.
Verification
Before: the AUR
t3code-nightly-binpackage (0.1.6-nightly.20261031.3977), opened as a separate instance with fresh, isolated app data. I clicked Settings, then About.After: this branch built with
node scripts/build-desktop-artifact.ts --platform linux --target dir --arch x64. I added the AUR package'sapp-update.ymltoresources/, since adirbuild doesn't write one, then launchedlinux-unpackedthe same way: no$APPIMAGEand nopackage-typemarker, like the AUR install. I clicked Settings, then About.vp test run src/updates/DesktopUpdates.test.tsinapps/desktop: 35 passed. The existing Linux case still shows .deb installs as enabled and unmarked installs as disabled.vp run check:changed 1d626d02d95f9a2343553f6498037ee82290d304: format, lint, knip, typecheck and tests pass.I didn't add a test, because AGENTS.md says to leave out tests for copy text. The captures are the proof.
Not checked:
Prior PRs
Generated with Claude Opus 5.5 and GPT-6.1 Sol in T3 Code Nightly