claude-code - 💡(How to fix) Fix [BUG] claudeCode.disableLoginPrompt: true silently stops working after async CLI auth check resolves with loggedIn: false [1 comments, 2 participants]

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

The claudeCode.disableLoginPrompt: true VS Code setting is supposed to suppress the Anthropic login screen for users on third-party auth (Bedrock, Vertex, custom apiKeyHelper setups). It works on the first state load, but the login screen appears anyway shortly after VS Code opens, because the setting’s effect is bypassed by a race condition in the async CLI auth check.

What Should Happen?

According to Claude's own analysis:

When claudeCode.disableLoginPrompt: true is set, the login screen should never appear regardless of what claude auth status returns. The disableLoginPrompt guard should apply as a fallback at every point where authStatus would otherwise be returned as null/undefined.

A minimal fix in the channel manager would be:

// Before (broken):
return this.cachedCliAuthStatus;

// After (respects disableLoginPrompt):
return this.cachedCliAuthStatus ?? this.authManager.getAuthStatus();
This is the same pattern already used correctly in the !cachedCliAuthStatusFetched branch.

Error Messages/Logs

Steps to Reproduce

1. Configure Claude Code with an apiKeyHelper in ~/.claude/settings.json (e.g. a Databricks/Bedrock token helper).
2. Set "claudeCode.disableLoginPrompt": true in VS Code User settings.
3. Allow the OAuth access token managed by the helper to expire (or simulate by temporarily breaking the helper).
4. Open VS Code.

Expected: Login screen does not appear; the extension uses apiKeyHelper for actual API calls as normal. **

**: The login screen (with options for Claude.ai Subscription, Anthropic Console, Bedrock/Foundry/Vertex, “Run Claude in terminal”) appears a moment after the sidebar loads.

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

No response

Claude Code Version

2.1.128

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

According to Claude:

Root Cause (traced from extension.js)

The VS Code extension has two separate auth-status code paths:

1. q2.getAuthStatus() (AuthManager) — respects the setting correctly:

getAuthStatus() {
  if (this.disableAuthLogin)   // set from claudeCode.disableLoginPrompt
    return { authMethod: "not-specified", email: null, subscriptionType: null };
  // ...
}

1. Channel manager getAuthStatus() — bypasses q2 after the first async check:

getAuthStatus() {
  if (!this.cachedCliAuthStatusFetched) {
    // First call: fires async CLI check, returns authManager.getAuthStatus() immediately.
    // → disableAuthLogin is respected here, login screen hidden ✓
    return this.refreshCliAuthStatus().then(...), this.authManager.getAuthStatus();
  }
  // Subsequent calls: returns cachedCliAuthStatus DIRECTLY, no fallback to authManager.
  return this.cachedCliAuthStatus;  // ← can be undefined!
}

1. refreshCliAuthStatus() runs claude auth status --json as a subprocess. The result is processed by aE4():

function aE4(result) {
  if (!result.loggedIn) return;  // returns undefined when loggedIn: false
  // ...
}

When the CLI auth check returns loggedIn: false (e.g. token expired, helper temporarily unavailable), cachedCliAuthStatus is set to undefined. The channel manager then returns undefined from getAuthStatus(), bypassing q2 entirely.

1. The webview receives authStatus: undefined and shows the login screen:

// In webview requestInit handler:
if ($.state.authStatus !== void 0)
  this.authStatus.value = $.state.authStatus;
else if (this.authStatus.value === void 0)
  this.authStatus.value = null;  // ← triggers login screen

// isAuthenticated computed:
isAuthenticated = () => {
  if (this.authStatus.value !== null) return true;  // null → false → login screen shown
  // ...
};

The setting disableLoginPrompt is never consulted again after cachedCliAuthStatusFetched becomes true.

Environment

Workaround

Keep the underlying auth token perpetually fresh so claude auth status never returns loggedIn: false. On macOS this can be done with a LaunchAgent:

# ~/Library/LaunchAgents/com.example.claude-token-refresh.plist
# StartInterval: 14400 (4 hours)
# ProgramArguments: databricks auth token --profile <profile> --force-refresh

This prevents the symptom but does not fix the underlying bug in the extension.