can1357/oh-my-pi · warning · Error

Server connection succeeded without OAuth; reauthorization i

Error message

Server connection succeeded without OAuth; reauthorization is not required.

What it means

Thrown during /mcp reauth when the server connects successfully without any credentials and no tool-level auth challenge was observed, AND OAuth discovery metadata (.well-known/oauth-protected-resource / oauth-authorization-server) is not advertised at the server URL. Since the user asked to re-authorize but there is genuinely no OAuth endpoint to acquire tokens from, the controller refuses the reauthorization as unnecessary rather than starting a pointless flow.

Source

Thrown at packages/coding-agent/src/modes/controllers/mcp-command-controller.ts:1237

		try {
			await this.#handleTestConnection(this.#stripOAuthAuth(config), { oauth: false });
			connectionSucceeded = true;
		} catch (error) {
			connectionError = error as Error;
		}

		// Server connected fine without auth. A tool-level challenge overrides
		// this: servers may allow the anonymous handshake yet protect individual
		// tool calls with `_meta["mcp/www_authenticate"]`. Even without such a
		// challenge, a clean `initialize` is only weak evidence — per the MCP
		// spec a server MAY permit unauthenticated `initialize` while requiring a
		// bearer token for `tools/call`. The user explicitly asked to reauth, so
		// honor it when the server advertises OAuth discovery metadata; only
		// refuse when there is genuinely no OAuth endpoint to acquire.
		if (connectionSucceeded && !authChallenge) {
			const discovered = "url" in config && config.url ? await discoverOAuthEndpoints(config.url) : null;
			if (!discovered) {
				throw new Error("Server connection succeeded without OAuth; reauthorization is not required.");
			}
			return discovered;
		}

		// Tool calls can carry richer RFC 6750/RFC 9728 hints than the original
		// connection error. Feed those hints through the same analyzer so
		// resource_metadata and scope reach protected-resource discovery.
		const authError = authChallenge
			? new Error(`${connectionError?.message ?? "HTTP 401"}\n${authChallenge.wwwAuthenticate.join("\n")}`)
			: connectionError!;
		const authResult = analyzeAuthError(authError, "url" in config ? config.url : undefined);
		let oauth = authResult.authType === "oauth" ? (authResult.oauth ?? null) : null;

		if (!oauth && (config.type === "http" || config.type === "sse") && config.url) {
			oauth = await discoverOAuthEndpoints(config.url, authResult.authServerUrl, authResult.resourceMetadataUrl, {
				protectedScopes: authResult.scopes,
			});
		}

View on GitHub (pinned to 9690622007)

Solutions

Nothing to fix if the server truly needs no auth — the credentials are already valid; skip reauth.
Verify you are targeting the correct server URL — an open dev/staging endpoint would explain the anonymous success.
If tool calls DO require auth but no metadata is advertised, invoke a protected tool to produce an auth challenge, or configure static credentials (bearer token auth block) instead of OAuth.
Confirm the server publishes .well-known/oauth-protected-resource; if it doesn't, OAuth discovery cannot work and static auth is the only option.

Defensive patterns

Strategy: validation

Validate before calling

const res = await fetch(serverUrl, { method: "POST", headers: { "content-type": "application/json" }, body: JSON.stringify({ jsonrpc: "2.0", id: 1, method: "initialize", params: {} }) });
const needsAuth = res.status === 401;
const hasMeta = (await fetch(`${origin}/.well-known/oauth-protected-resource`)).ok;
if (!needsAuth && !hasMeta) console.log("Server needs no OAuth; skip /mcp reauth");

Type guard

function isReauthNotRequiredError(err: unknown): err is Error {
  return err instanceof Error && err.message.includes("reauthorization is not required");
}

Try / catch

try {
  await reauthServer(name);
} catch (err) {
  if (err instanceof Error && err.message.includes("reauthorization is not required")) {
    showInfo("Server is already accessible without OAuth — no action needed.");
  } else throw err;
}

Prevention

Confirm the server actually advertises .well-known/oauth-protected-resource before attempting reauth.
Make sure the configured URL points at the intended (auth-protected) environment, not an open dev instance.
If only some tools are protected, trigger the protected tool once so a challenge is captured, then reauth.

When it happens

Trigger: Running /mcp reauth <name> against an http/sse server that (a) accepts unauthenticated initialize/handshake, (b) produced no RFC 6750/9728 auth challenge, and (c) publishes no OAuth discovery metadata at its URL.

Common situations: Reauth issued against a server that needs no auth at all; a server that protects only individual tools but does not advertise metadata and did not raise a challenge this session; a stale belief that the server requires OAuth after it was reconfigured to be open; pointing at the wrong URL/port (e.g. a dev instance without auth).

Related errors

AI-assisted analysis of can1357/oh-my-pi@9690622007 (2026-08-31). Data as JSON: /api/errors/237f3ebb372b81d4. Report an issue: GitHub.