eyaltoledano/claude-task-master · warning

getInstance called with config after initialization; config

Error message

getInstance called with config after initialization; config is ignored.

What it means

AuthManager is a singleton: getInstance(config) only applies config on the very first call that constructs the instance. If a config is passed on a later call, it is silently ignored and this warning is logged so misconfiguration doesn't go unnoticed.

Source

Thrown at packages/tm-core/src/modules/auth/managers/auth-manager.ts:70

		);

		// Pass the supabase client to OAuthService so they share the same instance
		this.oauthService = new OAuthService(
			this.contextStore,
			this.supabaseClient,
			config
		);
	}

	/**
	 * Get singleton instance
	 */
	static getInstance(config?: Partial<AuthConfig>): AuthManager {
		if (!AuthManager.instance) {
			AuthManager.instance = new AuthManager(config);
		} else if (config) {
			// Warn if config is provided after initialization
			AuthManager.staticLogger.warn(
				'getInstance called with config after initialization; config is ignored.'
			);
		}
		return AuthManager.instance;
	}

	/**
	 * Reset the singleton instance (useful for testing)
	 * Also resets SupabaseAuthClient to ensure clean state for test isolation
	 */
	static resetInstance(): void {
		AuthManager.instance = null;
		ContextStore.resetInstance();
		SupabaseAuthClient.resetInstance();
	}

	/**
	 * Get access token from current Supabase session

View on GitHub (pinned to c0c98d367c)

Solutions

Call getInstance with the full config at the application's earliest entry point, before anything else touches AuthManager.
Remove redundant config arguments from later getInstance calls and use the existing instance.
In tests, reset the singleton (e.g. AuthManager.instance = undefined via any provided reset) before configuring.
Refactor to pass config through an init/configure method instead of relying on first-call semantics.

Example fix

// before
const a = AuthManager.getInstance(); // constructed with defaults
const b = AuthManager.getInstance({ apiUrl }); // ignored + warning
// after
const a = AuthManager.getInstance({ apiUrl }); // first call wins
const b = AuthManager.getInstance();

Defensive patterns

Strategy: validation

Validate before calling

const first = AuthManager.getInstance(config); // apply config exactly once, at startup
// elsewhere:
const manager = AuthManager.getInstance(); // no config arg

Type guard

null

Try / catch

null

Prevention

Centralize AuthManager construction in a single bootstrap module.
Never pass config to getInstance after application startup.
Reset singletons between tests via the designated reset hook, then re-apply config.
Load env/config before any code path touches AuthManager.

When it happens

Trigger: Calling AuthManager.getInstance({ customApiUrl }) after some other code (e.g. the CLI constructor or a domain facade) already created the singleton, typically during 'called by: constructor' initialization paths.

Common situations: Multiple modules each calling getInstance with their own config; tests reusing a singleton across test cases; env/config loaded lazily after the first getInstance call.

Related errors

AI-assisted analysis of eyaltoledano/claude-task-master@c0c98d367c (2026-08-29). Data as JSON: /api/errors/09dab79798a7fadb. Report an issue: GitHub.