feat(secrets): auto-select auth broker type for login-style secret names

[guohai]

Summary

In console/secrets, the Type dropdown now auto-follows the secret Name for login-style credentials:

• As the user types a name (personal or org create form) containing EMAIL, ACCOUNT, USER, USERNAME, or NAME (names are uppercased, so USER/NAME also cover USERNAME), the Type auto-switches to the live auth broker type (first live broker matching /auth|session|login/i, i.e. auth-session).
• If no such broker is currently live/registered, nothing changes — Runtime stays the default.
• Non-clobbering: only toggles Runtime ↔ the auth type. If the user manually selected a different live broker type, it's left alone; the Type resets to Runtime only when the name no longer matches and the current value was the auto-set auth type.

Applies to both the Personal and Org secret create forms.

Scope

Client-only (console-secrets.tsx). Uses the existing /api/broker-types live-broker query; no schema/server changes.

Testing

• npm run check (tsc) — clean.

Generated with SMT smt@agora.io

[github-actions]

🤖 Codex Code Review

Findings

• client/src/pages/console-secrets.tsx:89 — The auto-selection clobbers any non-runtime broker when the name matches. nextBrokerTypeForName() returns authBrokerType for every matching name without checking current, so if another live broker type is added and the user selected it manually, typing EMAIL/USER switches it away. This violates the PR’s “never clobber a different live broker type” behavior; the match branch should only switch when current is "runtime" or already the auth type.
• client/src/pages/console-secrets.tsx:90 — The reset path cannot distinguish an auth type that was auto-set from one the user selected manually. If a user manually chooses auth-session for a non-login secret and then edits the name, the next non-matching name change resets Type to Runtime. That contradicts “resets to Runtime only when the current value was the auto-set auth type” and likely needs explicit “auto-selected” state per form.
• client/src/pages/console-secrets.tsx:88 — If /api/broker-types is still loading when the user enters a matching name, the helper returns the current Runtime value and nothing re-evaluates when authBrokerType later becomes available. A live auth broker can therefore fail to auto-select depending on query timing. Consider re-running the same non-clobbering logic in an effect when authBrokerType changes.

No security issues found in this client-only change.

[github-actions]

🤖 Claude Code Review

Findings

1. Client heuristic diverges from the existing server one — and omits PASSWORD (client/src/pages/console-secrets.tsx:83)

The server already owns this exact heuristic, with a comment saying it exists to drive this UI:

// server/auth-session.ts:273-277
const AUTH_FIELD_RE = /USERNAME|PASSWORD|ACCOUNT|EMAIL/i;
/** Default brokerType suggestion for a secret name (Task 6: pre-selects the UI toggle). */

The new client regex is /EMAIL|ACCOUNT|USER|NAME/ — a different rule, and notably PASSWORD is not in it. Since the form always sends an explicit brokerType (null for runtime, line 102/152), the server's provided === undefined default path never fires for this UI, so nothing else backstops the omission. Result: typing AGORA_CONSOLE_EMAIL auto-flips to Auth Session, but AGORA_CONSOLE_PASSWORD stays on Runtime — i.e. the login password is stored as an agent-exposed secret and handed to the target agent at dispatch, while its paired email is correctly Core-only. The feature's own success on the email field is what makes a user trust the form and not hand-correct the password.

Fix: import/reuse the server rule rather than restating it (defaultBrokerTypeForName is already exported), or at minimum add PASSWORD and drop the over-broad NAME/USER alternatives — those match AGENT_NAME, APP_NAME, HOSTNAME, USER_ID, USER_AGENT, none of which are login credentials, and a false positive here silently withholds the value from the agent (server/storage.ts:2598).

2. Fuzzy broker-type match vs. hardcoded "auth-session" elsewhere in the same file (console-secrets.tsx:84)

authBrokerType is picked by /auth|session|login/i.test(t) over live types, but the rest of the file compares against the literal string: the isTestAccount payload (lines 103, 153), the hint text (282, 434), and the attestation checkbox (287, 439). Today KNOWN_BROKER_TYPES = ["auth-session"], so it happens to line up. If a second type ever registers (login, auth-session-v2), .find() picks whichever comes first in the array and auto-selects it — at which point the attestation checkbox no longer renders, isTestAccount is never set, and shared-tier dispatch is blocked by server/storage.ts:2638 (brokerType === "auth-session" && isTestAccount) with no UI explaining why. Use the shared constant and check membership in brokerTypeOptions instead of a regex.

3. Auto-select re-fires on every keystroke, overwriting a deliberate manual choice (console-secrets.tsx:87-92)

nextBrokerTypeForName runs on each name onChange. Sequence: user types USER_ID → forced to Auth Session → user manually sets Runtime → user appends a character to the name → forced back to Auth Session. The comment says "never clobber a different broker type the user picked manually," but Runtime is a manual pick and it does get clobbered. Given how broad the regex is (finding 1), this is reachable with ordinary names. Track whether the user has touched the Select and suppress auto-select afterwards, or only apply it on the first name edit.

4. Minor: races the broker-types query (console-secrets.tsx:84)

authBrokerType is null until /api/broker-types resolves, and nextBrokerTypeForName returns current unchanged in that case. Nothing re-evaluates when the query lands, so a user who finishes typing the name before the fetch completes gets no auto-selection at all — the feature works or doesn't depending on network timing.

The refactor into one shared helper used by both the personal and org forms is the right call, and gating on a live broker being present is a good touch.