Server update buttons silently do nothing for connections paired before the environment:maintain split#17034

Thanks for the detailed report. I checked it against main at d7202109, and the diagnosis holds.

Confirmed on main

• sessionGrantsScope returns session.permissions.includes(scope) whenever the server sends permissions (L186). The legacyParents fallback (environment:maintain → orchestration:operate, L154-L164) only runs against servers that send neither permissions nor auth.serverUpdateScope.
• Upgraded servers send the stored grant as-is. getSessionState spreads authScopeResponse(session.scopes), which sets permissions to the stored scopes. #10298, which landed with #9786, deliberately removed scope expansion ("Existing credentials keep their recorded grants"). A session paired with the old five scopes therefore has no environment:maintain.
• The server would refuse the update anyway. RpcAuthorization.ts L77-L79 requires environment:maintain for server.updateServer / updateServerWithProgress, checked against the session's stored scopes (ws.ts L3159). So the client-side gate itself is consistent with the server.
• Banner / row button: canUpdate feeds disabled={manualCommand === null && !canUpdate} (L333, and L316 for the icon variant). Nothing explains why it's disabled. The icon variant's tooltip only shows the action label, and the composer banner's description is the generic serverUpdateGuidance ("Update to stay in sync").
• "Update all": savedServerUpdateTargets doesn't look at the session's permissions. ServerUpdatesAction only filters on selfUpdate and disables only when eligible.length === 0 (L159). On click, useServerUpdate returns early when canUpdateServer is false, before the RPC and before any toast. That matches the silent no-op you saw.
• The only hint is PermissionUpdateNotice. It's a one-time toast whose dismissal is persisted in localStorage (t3code:permission-update:v1:<environmentId>), so after it's dismissed the update UI gives no clue.

Root cause

The permission split (#9786 / #10298) intentionally leaves pre-split sessions without environment:maintain, and the update UI gates on that permission without telling anyone. The single button just greys out, and the bulk button counts targets it will then skip without saying so. Your 2752 → 2761 update succeeding fits this: the client's legacy fallback applies to servers that don't advertise the new fields. I haven't verified exactly which release tags carry which commits.

Possible fixes (untested)

1. Surface the reason (safe part). When the button is disabled because environment:maintain is missing, show something like "This connection needs to be paired again to update the server", ideally with an "Open Connections" action. Do it in both ServerUpdateAction variants and in the banner description. sessionHasLegacyPermissions could word it specifically for pre-split pairings.
2. Make "Update all" honest. Either leave targets without environment:maintain out of savedServerUpdateTargets (so the button hides or disables when none qualify), or have the click toast which servers were skipped and why, instead of returning silently.
3. Letting old sessions update again would mean treating orchestration:operate as granting environment:maintain for legacy grants. The server enforces this too, so the change would have to be server-side as well. That widens what existing credentials can do and reverses an explicit decision in #10298, so it's a security/product call for the maintainers, not a straightforward bug fix.

Workaround

Pair the environment again with a fresh link (Settings → Connections → Add Environment with the new link or code; see remote-access.md). Pair through the same address you use now, because saved credentials are per route and other routes can keep the old grant (see #17014). Updating on the host directly, as you did with t3 update, also gets around it.

Related

• #6204 (open, currently conflicting) adds a disabled-state tooltip to ServerUpdateAction, but only for "not connected yet". It doesn't cover permissions, though the same tooltip pattern could carry this reason.
• #13072 may involve the same gate for older Tailscale pairings. Not confirmed.
• #16804 is the same family (missing providers:manage), but on freshly issued mobile sessions, so it's a different cause.
• #17013 is another settings regression from #9786, with an unrelated mechanism.
• #15835 is a different update-guidance gate (incompatible environments).

Additional data point from t3 triage: the browser side panel is also greyed out for the same reason, not only the update button.

Environment

• Client: T3 Code desktop, 0.0.46-nightly.20261008.2801 (d7202109), Windows 11 x64
• Remote: a saved remote environment ("agentic-gui"), paired before the permission split

Symptoms

• The server update nudge for the remote shows, but its Update button is disabled, with no explanation.
• The browser/preview side panel for threads on that remote is disabled too, also with no explanation.

Diagnosis (same mechanism) The preview UI is gated on preview:operate (AuthPreviewOperateScope), for example in PreviewPanel.tsx L37, LegacySidebar.tsx L409, ChatMarkdown.tsx L2581, ElectronBrowserHost.tsx L130 and _chat.tsx L40. Like environment:maintain, it is a child of orchestration:operate in legacyParents. sessionGrantsScope never falls back to that parent once the server returns permissions, so pre-split pairings lose the browser panel as well as server updates, and nothing in the UI says why.

Suggestion Whatever fix lands for the update button's disabled reason (fix 1 above) should also cover the preview/browser panel entry points and any other control gated on a child scope. A shared "needs re-pairing for permission X" hint driven by sessionHasLegacyPermissions would cover all of them. The one-time PermissionUpdateNotice toast is easy to miss or dismiss.

Workaround: run npx t3@nightly pair on the host (the default standard scopes include environment:maintain and preview:operate), then use Add Environment with the new link through the same route.

Comment drafted by Claude Opus 5.5 (Claude Code) via t3 triage.

Fresh triage: this is a bug report, with no exploitable vulnerability described. No duplicate found in the open-issue scan (19 pages, 948 issues).

On the locally cached main commit b5a226e49c, source inspection still shows useServerUpdate returning skipped without feedback when canUpdateServer denies the session, and ServerUpdatesAction counting targets without checking that permission. The per-server button still disables without a permission explanation.

Runtime reproduction was not performed. Fetching main failed with HTTP 503. The automated triage hard stop prevents changes to permission handling, including the permission-dependent update availability and explanation here. Leaving this open for Julius; no implementation changes or PR.

Reproduced on current main a50cd989ae in the web dev app on Linux. The isolated fixture advertises the reported server version and boot-service capability; the real auth CLI issued a pairing grant without environment:maintain (the removed review:write scope was omitted).

After dismissing the one-time permissions notice, the composer Update button is disabled without an explanation. In Settings → Connections, a saved connected server with the same grant keeps Update all enabled. Clicking it produces no notification or update RPC; the button remains enabled.

Click recording. No duplicate found in the 926 open issues scanned. The historical binary upgrade and macOS Electron shell were not exercised.