Meta Muse OAuth fails after dashboard risk acknowledgement when using admin authentication

[sechmachine727]

Client or integration

OpenCodex dashboard

Area

Authentication and account pool

Summary

On OpenCodex v2.66.0, Meta Muse login from the dashboard fails with 403 oauth_consent_required after I accept the OAuth risk warning and click Continue with OAuth.

The dashboard is running against a hub and is authenticated with the normal management/admin credential. Other OAuth providers work from the same setup. For example, sending the same /api/oauth/login request for google-antigravity returns 200 with an OAuth URL. Anthropic login also does not require a gui-session.

I expected the Meta Muse login flow to start after accepting the warning, or at least for the dashboard not to offer a flow that the backend will always reject in this authentication state.

Reproduction

1. Run OpenCodex v2.66.0 in hub mode.
2. Access the dashboard over an allowed HTTPS origin. The dashboard is authenticated with the management/admin credential.
3. Go to Providers → Meta Muse Code (CLI) → Log in.
4. Check I understand the risk and want to continue with OAuth anyway.
5. Click Continue with OAuth.
6. The request fails with 403 oauth_consent_required.

Minimal equivalent request:

curl 'https://<hub>/api/oauth/login' \
  -H 'content-type: application/json' \
  -H 'origin: https://<hub>' \
  -H 'x-opencodex-api-key: <redacted-admin-token>' \
  --data-raw '{"provider":"meta-muse"}'

Response:

{
  "error": "Meta Muse login requires acknowledgement in the OpenCodex dashboard.",
  "code": "oauth_consent_required"
}

Control test from the same hub and authentication path:

{"provider":"google-antigravity"}

returns 200 with the Antigravity OAuth URL.

Where the inconsistency appears to be

The frontend treats Anthropic, Antigravity, and Meta Muse the same way for the high-risk warning:

gui/src/oauth-tos-risk.ts:10

const HIGH_RISK = new Set(["anthropic", "google-antigravity", "meta-muse"]);

gui/src/pages/Providers.tsx:494-500 shows the warning for any provider in that set:

const requestLoginOAuth = (provider: string, addAccount = false, accountId?: string) => {
  if (busy === provider) return;
  if (oauthTosRisk(provider)) {
    setOauthTosPending({ provider, addAccount, ...(accountId ? { accountId } : {}) });
    return;
  }
  void loginOAuth(provider, addAccount, accountId);
};

After the user accepts the warning, Providers.tsx:740-744 just continues into the normal OAuth login path:

onContinueOauthTos={() => {
  const pending = oauthTosPending;
  if (!pending) return;
  setOauthTosPending(null);
  void loginOAuth(pending.provider, pending.addAccount, pending.accountId);
}}

That reaches POST /api/oauth/login in gui/src/pages/use-providers-oauth.ts:101-105.

But the backend has a Meta-Muse-only principal check in src/server/management/oauth-account-routes.ts:189-194:

function metaMuseConsentRequired(provider: string, principal: ManagementContext["principal"]): Response | null {
  if (provider !== "meta-muse" || principal === "gui-session") return null;
  return jsonResponse({
    error: "Meta Muse login requires acknowledgement in the OpenCodex dashboard.",
    code: "oauth_consent_required",
  }, 403);
}

and applies it before starting the OAuth flow at lines 226-227:

const consentRequired = metaMuseConsentRequired(provider, principal);
if (consentRequired) return consentRequired;

So the dashboard can record that the user accepted the warning, but that acknowledgement does not affect the server-side check. The request still fails unless its resolved principal is specifically gui-session.

This is also inconsistent with the other providers in the same frontend HIGH_RISK group: Antigravity and Anthropic do not have the same backend gui-session requirement.

Version

2.66.0

Operating system

Linux ARM64 (OCI VM)

Provider and model

Meta Muse Code (meta-muse). The failure happens during login before model selection.

Logs or error output

HTTP 403
{"error":"Meta Muse login requires acknowledgement in the OpenCodex dashboard.","code":"oauth_consent_required"}

Screenshots and supporting files

The dashboard shows the Meta Muse OAuth risk acknowledgement modal. After checking the acknowledgement and clicking Continue with OAuth, the provider login returns the error above.

Redacted configuration

{
  "runtimeRole": "hub",
  "corsAllowOrigins": [
    "https://<redacted>.ts.net"
  ]
}

The same dashboard/origin can start other OAuth flows successfully.

Checks

• I searched existing issues and documentation.
• I removed secrets, tokens, account details, request credentials, and personal data.

[lidge-jun]

Resolved on dev by #5911, carried in bug-PR merge train batch 9D, #5986 (merge 6b2b66d), following the decision recorded in structure/decisions/ADR-5877-oauth-login-continuations.md. Meta Muse management OAuth can only start from a dashboard gui-session, and provider discovery now advertises it only to that principal. An admin-token session is therefore no longer offered a flow that fails after the risk acknowledgement. Closing; please reopen if a build that includes 6b2b66d still offers the flow and then fails.