[saphid]

Disabled desktop update controls showed “Check for updates” without explaining why they could not be used. The desktop process now sends its existing disabled reason in the existing update-state message, and the sidebar tooltip/accessibility label and Settings About show it. Update actions and provider/server update summaries retain their existing behavior.

Credit: @saphid’s original fix and native evidence in #18404. Maintainer takeover preserves the contributor’s commits and merges current main without rewriting history.

Verification at c259374217:

• 98 focused tests pass across DesktopUpdates, desktopUpdate.logic, SidebarUpdatePill, and updateEverything.logic. Desktop service coverage now checks configure → channel change → broadcast with no disabled update check; 38→39 desktop tests and 41→40 web logic tests (79 total remains). Restoring main production code produces three expected failures, including loss of the configured disabled reason.
• Desktop and web package typechecks, targeted lint/format, and whitespace checks pass.
• Independent full-diff review round 1: Claude Opus 5.5 and GPT-6-Sol found no blockers. The existing Settings disabled-button tooltip is an older issue; the visible row now explains the reason.
• Linux live web renderer against an isolated dev server, with a temporary desktop-bridge fixture: disabled sidebar tooltip and accessible label, About description, channel change, and enabled idle controls checked. Matching base/head images below use identical state and viewport. Fixture code is not published.

Before — current main renderer:

After — rebuilt renderer:

Limits: this verifies the web renderer and service tests, not native Electron IPC, packaged Linux/macOS/Windows updates, or real downloads/installations. No iOS/Android behavior changes. Current-head CI/review status must be checked before merging; this PR is left unmerged.

Implementation: GPT-6.1-Sol (high), tests: GPT-6-Astra (high), reviews: Claude Opus 5.5 and GPT-6-Sol; Codex/Claude harnesses through T3 Code.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

• Configuration used: Path: .coderabbit.config.ts
• Review profile: CHILL
• Plan: Advanced
• Run ID: d9970886-1774-494a-804e-679afaa3bad3

📥 Commits

Reviewing files that changed from the base of the PR and between eeaac49 and ee40538.

📒 Files selected for processing: 6

• apps/desktop/src/updates/DesktopUpdates.test.ts
• apps/desktop/src/updates/DesktopUpdates.ts
• apps/web/src/components/desktopUpdate.logic.test.ts
• apps/web/src/components/desktopUpdate.logic.ts
• apps/web/src/components/settings/SettingsPanels.tsx
• apps/web/src/components/sidebar/SidebarUpdatePill.tsx

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 8 remain after this review.

📝 Walkthrough

Desktop update state now carries a disabled reason. Web settings and sidebar update surfaces display that reason when updates are unavailable, while enabled or absent update states retain their existing prompts.

Changes: Desktop update availability messaging

Layer / File(s)	Summary
Carry disabled reasons in desktop update state apps/desktop/src/updates/DesktopUpdates.ts, apps/desktop/src/updates/DesktopUpdates.test.ts	State construction now accepts an optional disabled reason and uses it as the state message. Configuration and channel changes skip updater work when a reason exists. Tests check the .deb message and the unmarked-package reason.
Resolve unavailable reasons and idle tooltip content apps/web/src/components/desktopUpdate.logic.ts, apps/web/src/components/desktopUpdate.logic.test.ts	New helpers derive the disabled reason and idle tooltip from update state. Tests cover supplied and missing messages, enabled state, and absent state.
Show disabled reasons in update surfaces apps/web/src/components/settings/SettingsPanels.tsx, apps/web/src/components/sidebar/SidebarUpdatePill.tsx	The settings description uses the disabled reason when no update action is available. The sidebar tooltip and accessible label include the reason when updates are unavailable.

Priority: ⬇️ Low

Estimated code review effort: 3 (Moderate) | ~20 minutes

Change: Bug fix

Suggested reviewers: juliusmarminge

Merge Risk: ⚪ Minimal · up to ee405

This change explains in the sidebar tooltip and in Settings why updates are unavailable. No actionable merge-blocking risk was found in the supplied context.

Security architecture risk: ⚪ Minimal · up to ee405

The change explains why updates are unavailable without changing update permissions or behavior. The existing message format remains compatible, and the reviewed paths preserve update-action controls. No material security risk was identified in this change.

Retained concerns
No architecture-level concerns identified.

Security review details

Security Blast Radius

• inferred — The effective changed exposure is availability information displayed in the existing application UI. The reviewed change does not expand which update artifacts, services, tenants, or environments the application can modify.

Trust Boundaries and Controls

• observed — The routed entrypoints are existing React presentation components. Settings retains its state-derived disabled button and installation confirmation; the sidebar retains its interaction guard before dispatching actions. The new explanation is not an authorization input.

Resilience and Maintainability Implications

• observed — Base-state reconstruction preserves enabled=false and status=disabled when a reason exists. Existing action reservations continue to serialize channel changes and release ownership on failure or interruption. Normal update transitions clear message, while failures and install recovery replace it with operation-specific information rather than using it to enable actions.

Pre-merge checks: 4

Check name	Status	Explanation
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.
Title check		The title clearly and concisely describes the primary change: explaining why the desktop update button is disabled.
Description check		The description explains the problem, implementation, scope, verification results, limitations, screenshots, and agent usage. It does not use the template headings, and the approval context is less ex…

Full details: Description check

Explanation

The description explains the problem, implementation, scope, verification results, limitations, screenshots, and agent usage. It does not use the template headings, and the approval context is less explicit than requested, but the required information is mostly complete.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

_{Comment @coderabbitai help to get the list of available commands.}

[macroscopeapp]

Approvability

Verdict: Approved at c259374

Macroscope's review found this PR approvable — This is a contained desktop update UX fix that carries an existing disabled reason through the current state and displays it in the sidebar and About section. Existing update actions, polling, channel behavior, and enabled paths remain unchanged, with focused tests covering the new state and presentation logic.

^{You can add or adjust custom eligibility rules. Learn more.}

Dismissing prior approval to re-evaluate a6c40d6

Dismissing prior approval to re-evaluate ee40538

Dismissing prior approval to re-evaluate 0adc7fb

[juliusmarminge]

Taking over this one as maintainer for batch desktop-app-05. I will keep the focused disabled-reason fix, bring in current main without rewriting your history, simplify tests, and run independent implementation and review passes. Thanks @saphid for the fix and platform evidence.

Dismissing prior approval to re-evaluate c259374