[ragnorc]

A managed target now signs in with Studio's own OAuth client wherever its cluster offers sign-in, and uses the CLI's login only where the cluster offers none (spec 016). modernrelay-og-cluster has offered sign-in since the managed control plane turned it on for existing clusters.

How it decides

The connection holds the CLI's login back until the cluster's first 401 answers, so that request carries no token.

• The 401 names resource_metadata: the cluster signs people in itself. The login is dropped, and the connection signs in the way an anonymous target's does. A sign-in the keychain kept is refreshed without asking, and the CLI is never asked for a token.
• The 401 names none: the login becomes the token source and is asked at once from then on. Such a cluster costs one request without a token per connection.
• The connection has no sign-in context: it takes the login too.

Organization

A sign-in must be in the organization the target's CLI profile names. Studio reads it once per profile, with the target listing, from omnigraph credentials status --profile NAME --json (owner.organization_id), which reads no secret and contacts no service. A token in another organization is refused before it is sent, and the message names both organizations. If the CLI won't describe a profile, Studio shows a notice and leaves the check to the server. A change of organization drops a held sign-in and any sign-in service already read.

Tests

graph_store:

• sign_in::tests::a_managed_target_signs_in_where_its_cluster_offers_it
• sign_in::tests::a_managed_target_uses_the_clis_login_where_its_cluster_offers_no_sign_in
• sign_in::tests::a_sign_in_to_a_managed_target_must_be_in_its_organization

All three fail with the hold-back disabled; I checked by disabling it. cli_tokens::tests::the_targets_are_listed_as_the_cli_describes_them is extended, and cli_tokens::tests::a_managed_profile_the_cli_cannot_describe_is_said is new.

The full local gate passes: cargo fmt --check, the layer, design-token and brand scripts, cargo clippy --workspace --all-targets -- -D warnings and cargo test --workspace.

Not covered here: managed targets on Windows, which the CLI's login keeps refused, and choosing an organization for a person in several. Both are listed under Deferred in the spec.

---

Note

Medium Risk
Changes authentication branching for managed targets and OAuth org validation, but behavior is spec-driven and covered by new integration tests rather than broad refactors.

Overview
Managed cluster targets no longer always connect with the CLI’s exchanged data token. The connection holds back that login until the first unauthenticated request gets a 401: if the challenge includes resource_metadata, Studio drops the CLI credential and signs in with its own OAuth client (like an anonymous server target); if not, it activates the CLI login as the token source from then on (one tokenless probe per connection).

Target listing now runs credentials status --profile NAME --json once per managed profile (deduped) and stores organization on CliCredential::Managed. That value flows through TokenSource::organization into OAuth discovery and token checks so a sign-in must match the profile’s org; mismatches are refused before the token is sent, and org changes clear a held sign-in. Profiles the CLI can’t describe still land with a notice and server-side checks only.

Specs, UI tooltips, and tests cover both cluster behaviors plus organization enforcement.

^{Reviewed by Cursor Bugbot for commit 296959e. Bugbot is set up for automated code reviews on this repo. Configure here.}

[cursor]

Bugbot couldn't run - usage limit reached

Bugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit.

A user or team admin can review and increase usage limits in the Cursor dashboard.

(requestId: 614288b6-4519-46d8-8d1b-65e973b22717)