claude-code - 💡(How to fix) Fix [BUG] agent view disabled by gatewayAuth gate on Max+Stripe accounts [1 comments, 2 participants]

Preflight

• Searched existing issues — no exact match (closest: #34452, #35877, both adjacent symptoms on the same auth path)
• Single bug report
• Using latest version (2.1.140)

What's Wrong?

claude agents falls back to the legacy subagent-list renderer instead of mounting agent view, on a Pro/Max subscription account with hasExtraUsageEnabled=true and billingType=stripe_subscription. The CLI prints N active agents followed by configured subagents and exits, exactly matching the official troubleshooting symptom ("agent view is unavailable in your environment").

The documented exclusions are Bedrock / Vertex AI / Foundry. None of those apply here — no CLAUDE_CODE_USE_* env is set, no ANTHROPIC_API_KEY/ANTHROPIC_AUTH_TOKEN/apiKeyHelper is set, no managed-settings.json exists at any documented path, and no disableAgentView setting is present. The account routes through Anthropic's first-party auth, not a third-party gateway. Yet isAgentsFleetEnabled() returns false.

What Should Happen?

A Max-subscription account with no third-party gateway envs should be eligible for agent view, per the docs' stated availability ("Pro, Max, Team, Enterprise, and Claude API plans").

Error Messages / Logs

No error — silent fallback. The CLI just prints:

18 active agents

Plugin agents:
  ...
Built-in agents:
  claude · inherit
  Explore · haiku

Steps to Reproduce

1. Be on a Claude Max plan with hasExtraUsageEnabled: true and billingType: "stripe_subscription" (visible in ~/.claude.json under oauthAccount.*).
2. Confirm no relevant disabling envs/settings: env | grep -E "CLAUDE_CODE_USE_|CLAUDE_CODE_DISABLE_AGENT_VIEW|ANTHROPIC_API_KEY|ANTHROPIC_AUTH_TOKEN" returns empty; no disableAgentView in any settings file; no managed-settings.json at the documented paths.
3. Run claude --version → 2.1.140.
4. Run claude agents → expected: dashboard mounts. Actual: legacy subagent listing, then exits.
5. (Optional confirmation that the gate isn't the GrowthBook side) Run CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 claude agents — still falls back. This forces Q7()=true in the gate, so failure here proves xWH() is the active blocker, not tengu_slate_meadow.
6. Run claude logout && claude login and retry — no change. The server re-injects the same gateway routing on each fresh login.

Root cause (from 2.1.140 binary trace)

Binary inspection of the bundled gate functions:

// isAgentsFleetEnabled
function yc() { return !xWH() && (Q7() || D_("tengu_slate_meadow", false)) }

function xWH() {
  return SH(process.env.CLAUDE_CODE_DISABLE_AGENT_VIEW)
      || VS()?.settings.disableAgentView === true
      || NN1()
}

function NN1() {
  return SH(process.env.CLAUDE_CODE_USE_BEDROCK)
      || SH(process.env.CLAUDE_CODE_USE_VERTEX)
      || SH(process.env.CLAUDE_CODE_USE_FOUNDRY)
      || SH(process.env.CLAUDE_CODE_USE_ANTHROPIC_AWS)
      || SH(process.env.CLAUDE_CODE_USE_MANTLE)
      || _$() !== null   // ← this is the trigger
}

function _$() { return g_.gatewayAuth }

All five CLAUDE_CODE_USE_* envs are unset, disableAgentView is unset, CLAUDE_CODE_DISABLE_AGENT_VIEW is unset → xWH() is true only because g_.gatewayAuth !== null.

Inspecting persisted secure storage to find where gatewayAuth is restored from:

• All Claude Code-credentials* keychain entries on the machine contain only claudeAiOauth.{accessToken,refreshToken,expiresAt,scopes,subscriptionType,rateLimitTier} and mcpOAuth.plugin:* blobs.
• No enterpriseGateway blob is persisted to secure storage on this machine (the field that fZ1() reads via d4().readAsync() to populate gatewayAuth).
• Yet gatewayAuth is non-null at runtime — confirmed by the gate firing closed.

This means gatewayAuth is being populated from the OAuth response claim itself during login, not restored from disk. Which is why claude logout && claude login doesn't help: the server re-emits the same claim on the new token.

The dispatcher path (claude agents → ensureFleetGateHydrated → isAgentsFleetEnabled → either mountFleetView or fallthrough to agentsHandler (kHO) that renders the listing) is correct; only the gate evaluation is wrong for this account class.

Suggested fix

Either:

1. Stop emitting the gateway-auth claim for Stripe-subscription accounts on the OAuth response (these accounts route through standard Anthropic auth, not a third-party gateway), or
2. Tighten NN1() so gatewayAuth !== null only disables agent view when the gateway URL is actually a third-party origin (Bedrock / Vertex / Foundry / AWS / Mantle), not for the first-party Anthropic-managed gateway that handles Stripe-subscription accounts.

Option 2 is the smaller change and likely matches the design intent — the comment in NN1() lumping gatewayAuth with the CLAUDE_CODE_USE_* envs strongly suggests the original intent was "third-party-only" exclusion.

Related

• #34452 — hasAvailableSubscription: false despite active Stripe subscription (closed not-planned). Same auth-path tangle, different symptom (Remote Control).
• #35877 — hasAvailableSubscription: false despite active Max subscription (open, no response). Same tangle.

These three together (agent view, Remote Control, and the hasAvailableSubscription flag) are all downstream of the same OAuth claim handling for Stripe-subscription + extra-usage accounts.

Environment

Claude Code: 2.1.140 (latest on npm as of 2026-05-13)
OS: macOS 15.6 (Darwin 24.6.0)
Plan: Claude Max 20x (oauthAccount.organizationType = "claude_max")
billingType: stripe_subscription
hasExtraUsageEnabled: true
hasAvailableSubscription: false  ← also broken, see #34452/#35877
hasAvailableMaxSubscription: false