Repository navigation
Conversation
ApprovabilityVerdict: Approved at Macroscope's review found this PR approvable — Access settings can now manage saved environments when Local environment is off. Operations retain environment-specific credentials and permission checks, while local backend controls remain limited to the primary environment. You can add or adjust custom eligibility rules. Learn more. |
Thread transfer impact✅ Thread transfer remains within every enforced ceiling.
Baseline: Scenario and decoded snapshot size10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.
Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed. |
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the
Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
No actionable comments were generated in the recent review.
|
| Layer / File(s) | Summary |
|---|---|
Connected-environment authentication commands packages/client-runtime/src/state/environmentHttpAuth.ts, packages/client-runtime/src/state/auth.ts, packages/client-runtime/package.json, apps/web/src/environments/primary/auth.ts, apps/web/src/environments/primary/index.ts, apps/web/src/environments/primary/sessionState.ts, apps/web/src/state/session.ts |
The client runtime adds authenticated HTTP requests and pairing or client-management commands for connected environments. The primary-environment pairing, revocation, and session-state helpers are removed. Session state accepts a nullable environment ID. |
Environment-scoped cloud-link state and operations apps/web/src/cloud/cloudLinkState.ts, apps/web/src/cloud/linkEnvironment.ts, apps/web/src/cloud/linkEnvironmentAtoms.ts, apps/web/src/cloud/primaryCloudLinkState.ts, apps/web/src/cloud/linkEnvironment.test.ts |
Cloud-link reads and mutations use a target environment’s prepared connection. State, refresh, and cached reads are scoped to an environment. Tests check target-specific origins and bearer tokens. |
Environment selection and access management apps/web/src/components/settings/ConnectionsSettings.logic.ts, apps/web/src/components/settings/ConnectionsSettings.logic.test.ts, apps/web/src/components/settings/ConnectionsSettings.tsx, apps/web/src/components/settings/AuthorizedClientsSettings.tsx, apps/web/src/components/settings/AuthorizedClientsSettings.browser.test.tsx, apps/web/src/components/settings/SettingsScopeSentence.tsx, docs/user/remote-access.md |
Access settings resolve a selected environment and use its session state, permissions, and authentication commands. Pairing and client revocation target that environment. The documentation describes selecting an environment and managing a same-machine background service. |
Cloud-link controls and settings integration apps/web/src/cloud/useCloudLinkController.ts, apps/web/src/cloud/useCloudLinkController.browser.test.tsx, apps/web/src/components/cloud/ConnectOnboardingDialog.tsx, apps/web/src/components/settings/SavedEnvironmentRows.tsx, apps/web/src/components/settings/ScheduledTasksSettings.tsx, apps/web/src/components/settings/useAvailableSettingsSearchItems.ts |
The cloud-link controller and settings rows receive an environment ID. The onboarding dialog passes the primary environment ID. |
Estimated code review effort: 4 (Complex) | ~45 minutes
Change: Bug fix · Severity of issue fixed: Medium
Sequence Diagram(s)
sequenceDiagram
actor User
participant ConnectionsSettings
participant useEnvironmentSessionState
participant authEnvironmentCommand
participant ConnectedEnvironment
User->>ConnectionsSettings: Select an environment
ConnectionsSettings->>useEnvironmentSessionState: Read session for selected environment
ConnectionsSettings->>authEnvironmentCommand: Create pairing credential or revoke client
authEnvironmentCommand->>ConnectedEnvironment: Send authenticated request
ConnectedEnvironment-->>authEnvironmentCommand: Return command result
Suggested reviewers: maria-rcks
Merge Risk: 
Minimal · up to d2bc9
-
The change lets Sharing & access work for a connected service when Local environment is off. No blocking risk was found in the reviewed changes. Signed-in T3 Connect and multi-environment selection were not exercised by the author. The T3 Connect onboarding dialog still acts on the primary environment; it behaved that way before this change.
Pre-merge checks: 
4
-
Check name Status Explanation Title check The title is concise, conventional, and accurately describes the main change: showing saved-service access when Local environment is off. Linked Issues check Issue #26420is the only active directly linked target. Its coding requirement: Settings → Sharing & access must show a connected non-primary service when Local environment is off. The page must offer…Out of Scope Changes check The whole-PR summary (merge base d897d3f to head d2bc956) shows changes that serve #26420:
- Environment selection and picker inConnectionsSettingsandresolveAccessEnvironmentId.
- Environment-s…Description check The description is complete and directly addresses the problem, implementation, scope, linked issue, verification steps, evidence, limitations, and review status. It uses custom headings instead of th… Full details: Linked Issues check
-
Explanation
Issue
#26420is the only active directly linked target. Its coding requirement: Settings → Sharing & access must show a connected non-primary service when Local environment is off. The page must offer that service's settings and T3 Connect link/unlink controls, not 'No environment selected'.Evidence at head d2bc956 (whole PR, merge base d897d3f):
resolveAccessEnvironmentIdinConnectionsSettings.logic.tskeeps a listed explicit selection. Otherwise it uses the listed primary environment, then a connected listed environment, then the first listed environment. It returns null only when no environments exist.ConnectionsSettings.tsxoffers a picker when several are listed.- Access queries, session state, scopes, pairing, client revocation and cloud-link rows target the selected environment.
SavedEnvironmentRows.tsxgivesCloudLinkRowanenvironmentId, so the T3 Connect row renders for the selected service. - Cloud-link requests in
linkEnvironment.tsand environment-scoped commands inpackages/client-runtime/src/state/auth.tsrun through the selected environment's prepared connection (executeConnectedEnvironmentHttpRequest). - The rebase adds managed-policy checks that follow the selected service.
AuthorizedClientsSettings.browser.test.tsx(read at head) covers the selected service denying remote clients (pairing disabled) and an unmanaged selected service with a managed primary (pairing enabled). This matches the PR description. - Unproven at head: signed-in T3 Connect link/unlink and guest-link creation through a live tunnel. The issue requires the UI path and environment-scoped requests, and the code provides both. Live tunnel behavior does not change this verdict. Maria's run covers saved-service access and pairing on head 286d53a. It does not cover the later rebase at d2bc956.
Full details: Out of Scope Changes check
-
Explanation
The whole-PR summary (merge base d897d3f to head d2bc956) shows changes that serve
#26420:- Environment selection and picker in
ConnectionsSettingsandresolveAccessEnvironmentId. - Environment-scoped cloud-link state, controller and commands (
cloudLinkState.ts,linkEnvironment.ts,linkEnvironmentAtoms.ts,useCloudLinkController.ts,SavedEnvironmentRows.tsx,ConnectOnboardingDialog.tsxpassing the primary ID). - Environment-scoped pairing and revocation in
packages/client-runtime/src/state/auth.tsandenvironmentHttpAuth.ts. These replace primary-only helpers removed fromapps/web/src/environments/primary/auth.ts,index.tsandsessionState.ts. AuthorizedClientsSettings.tsxchanges: selected-environment pairing and managed-policy checks for that environment. The rebase moved policy checks from the primary to the selected service, which is part of making pairing for the selected service correct.- Primary-only desktop network, Tailscale, WSL and onboarding controls keep the primary target. The PR description and summary state this, and it matches the issue's scope.
- Comment, import and docs updates (
SettingsScopeSentence.tsx,useAvailableSettingsSearchItems.ts,ScheduledTasksSettings.tsx,docs/user/remote-access.md, theenvironmentHttpAuthpackage export) and tests for the changed behavior.
The summary shows no server, server-authorization or native mobile changes. The rebase over PR#27197did not add a file that the summary lists as unrelated. The server typecheck issue inAgentSessionScanner.ts, if present, is a main-branch condition and not a change of this PR.
- Environment selection and picker in
Full details: Description check
-
Explanation
The description is complete and directly addresses the problem, implementation, scope, linked issue, verification steps, evidence, limitations, and review status. It uses custom headings instead of the template headings, but it provides the required information in equivalent sections.
-
Finishing Touches
-
Generate docstrings
-
- Commit to this branch
- Create a new PR
Generate unit tests (beta)
-
- Commit to this branch
- Create a new PR
-
- Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
3da58a7 to
286d53a
Compare
|
Note Written by Verified in a real dev environmentVerified head Used the real dev server, Electron renderer, and repository Playwright with system Chrome. Added a real git project through the app and ran Codex Created a pairing code from saved-service access, paired a fresh Chrome client, then revoked it. The client lost its connection and returned to pairing on reload. Also created/revoked an unused link and verified primary web pairing creation/revocation. Desktop-only network controls remain absent for the saved service. Actual saved-service requests, credentials omitted:
Not verifiedSigned-in T3 Connect linking/unlinking, managed tunnels, and guest links require an external test account that was unavailable. Multi-environment selection was not exercised because this pass used one server. macOS, Windows, native iOS and Android were not exercised on this Linux VM. |
…nvironment is off With Local environment off there is no primary environment, so Sharing & access showed "No environment selected" even while a background service on the same machine was connected, and there was no way to link it to T3 Connect. The page now picks an environment: the primary when there is one, otherwise a connected saved environment, with a picker when several are connected. Access changes, pairing links, revocations, session permissions and the T3 Connect link all run on that environment with this client's own credentials for it, through the shared authenticated environment HTTP helper. Desktop network, Tailscale and WSL controls still appear only for the desktop-managed local environment. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
286d53a to
d2bc956
Compare




With Local environment off, the Linux desktop client showed "No environment selected" in Sharing & access despite being connected to a background service. The page now selects a connected service and offers a picker for multiple services. Access and T3 Connect actions use the selected service's credentials, permissions and organization policy; desktop network controls still belong only to the backend the app manages.
Closes #26420
Evidence
Verified head
d2bc956caf92ebc74dbe49e2b5952af2e16c1c55. No code changed during this verification.Unverified live path: production Clerk account authentication and live relay provisioning/revocation, managed connector startup, tunnel reachability, and guest links through that tunnel. The recording uses fixture Clerk/relay responses and real current-head desktop/server code. Initial linking keeps the existing loopback-origin restriction.
Linux desktop
Current-head Electron 44.10.0 on physical corex, with two separate current-head bundled servers at
127.0.0.1:27731and127.0.0.1:27732, isolated data and Local environment off. Both services were enrolled through the normal Add environment UI. The service launcher uses the sameservecommand inapps/server/src/serviceLauncher.ts.The app used Electron's production
gnome_libsecretbackend through a task-isolated GNOME secret-service session collection. Its persisted connection catalog is encrypted. This pass did not use Electron's basic store or a mock keychain.The screenshots above came from a build without cloud public configuration. The cloud-enabled recording below covers the Connect controls and selected-service publish-only linking/unlinking. Web and macOS/Windows desktop use the same
ConnectionsSettings,AuthorizedClientsSettingsandexecuteConnectedEnvironmentHttpRequestpath exercised here. No native mobile UI changes are included.The earlier before build at
48a292364ab37574c67fb377b5227e5d281d9203reproduces the connected-service empty page:linux-before.mp4
Cloud-enabled Linux desktop and real server proof
Recorded on physical corex at
d2bc956caf92ebc74dbe49e2b5952af2e16c1c55, using the production Electron renderer and two real bundled servers. Local environment is off. Both saved services are connected through normal pairing and Electron's productiongnome_libsecretcredential store. No app source, hooks, controller, environment-auth helper, or/api/connectserver handler was replaced.The 56-second recording shows Local environment off, both connected services, Labs to Sharing & access, the enabled T3 Connect controls, then publish-only cloud linking for A and B. Unlinking A leaves B enabled; returning to B shows that state before unlinking B. These actions use production
useCloudLinkControllerandlinkEnvironmentToCloud/unlinkEnvironmentFromCloud. They do not start a managed tunnel. Idle pauses were shortened, with a fixture caption added below the actual Electron viewport.cloud-selected-service.mp4
Only unavailable external boundaries were faked: Clerk FAPI session/token responses and its account widget, plus a task-local HTTPS relay. The real Clerk SDK reads those responses. The relay fixture verifies the actual server's Ed25519 proof before returning an invented per-environment credential and a valid mint public key. The task certificate uses Electron's
--ignore-certificate-errors; this is not production TLS or live account verification. The managed T3 Connect switch is shown but stays off.After every recorded publish toggle, authenticated reads of both real servers and SHA-256 comparisons of their relay secret files verify the selected service changed and the other service did not. All five checkpoints passed, including the final both-unlinked state.
Separate commands against those same real current-head servers prove manual and managed link-proof signatures, exact claims and loopback ports, unauthorized and wrong-port rejection, and relay-configuration persistence. Both processes were restarted with their original isolated homes and ports. Exact secret bytes, 0600 modes, preferences and signing keys survived. A conflicting account was rejected without modifying files; A's bearer was rejected by B; unlinking A left B's state and files unchanged.
Build provenance and real-server commands/results
Reproduce the real-server proof
Run the script below against two isolated current-head
serveprocesses, each with its own base directory and port. Its private input JSON is{ "services": [{ "name": "service-a", "origin": "http://127.0.0.1:27731", "baseDir": "/tmp/t3code-26464-cloud/service-a", "bootstrapCredential": "<fresh CLI pairing code>" }, { "name": "service-b", "origin": "http://127.0.0.1:27732", "baseDir": "/tmp/t3code-26464-cloud/service-b", "bootstrapCredential": "<fresh CLI pairing code>" }] }. Keep that file private. Runprepare, restart both processes with the same arguments, then runverify-after-restart. No external account or relay server is needed for these production server-handler checks.Recording fixture boundary and isolation assertions
The recording fixture below only fulfills external
clerk.fixture.testnetwork requests and listens as the external relay. The application's service requests go directly to the unmodified real servers. The account widget is stubbed; T3's controls and business logic are not. Browser input uses cua-driver, and CDP screencast records the owned Electron viewport.After each UI action, run
node ui-state-check.mjs <baseline|link-a|link-b|unlink-a|unlink-b>:Checks and review
vp run check:changed "$FLEET_SOURCE_BASE"passed on this head againstd897d3f3f00f2cb534c813e637154d39c8d1cff6: 67 tests across 8 files, 39 affected package typechecks, 15 selected React compiler checks, format, lint, both knip checks and unused patches. The browser regression covers opposing primary and saved-service organization policies and failed with the primary-only lookup restored. The cloud HTTP regression also failed first with the wrong bearer token.Changed-file check output
Ready check also compared this head with live
mainat30654b3e91a51937d1dba18fc83af19d8003f5ca. The merge is clean. Since the tested base, the overlapping main changes only trim pasted scheduled-task paths and select scope grants without changing their result. Access selection, cloud operations and pairing paths are unchanged.GitHub reports 29 passed checks and 8 skipped checks, with none pending or failing. Macroscope approved; the independent Codex review found no open findings. Maria's earlier independent Linux verification also verified pairing a fresh browser and revoking its access at
286d53a8f18ce56c9a431d0ed7bec0f79c4ec711.Implemented and rebased by Claude Opus 5.5 in Claude Code. Investigated, tested and independently reviewed by GPT-6.1 Sol in Codex through T3 Code.