fix(mcp): forward HTTP auth to internal tool fetches

[KooshaPari]

No description provided.

[gemini-code-assist]

Code Review

This pull request introduces an HTTP authentication context for the Model Context Protocol (MCP) server using AsyncLocalStorage to forward credentials (such as bearer tokens, cookies, and API keys) to internal fetches. Feedback on the changes highlights a critical header merging order issue in both server.ts and advancedTools.ts where system-wide API keys can overwrite forwarded user credentials. Additionally, the new test file violates the repository style guide regarding file placement and should be moved to the tests/ directory.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

The current header merging order causes the forwarded Authorization header from getMcpHttpAuthHeadersForInternalFetch() to be overwritten by the default system-wide apiKey (if configured). To ensure forwarded user credentials take precedence over the system-wide API key, place the default Authorization header before spreading the forwarded headers.

Suggested change

	const headers: Record<string, string> = {
	"Content-Type": "application/json",
	...getMcpHttpAuthHeadersForInternalFetch(),
	...(apiKey ? { Authorization: `Bearer ${apiKey}` } : {}),
	...((options.headers as Record<string, string>) || {}),
	};
	const headers: Record<string, string> = {
	"Content-Type": "application/json",
	...(apiKey ? { Authorization: `Bearer ${apiKey}` } : {}),
	...getMcpHttpAuthHeadersForInternalFetch(),
	...((options.headers as Record<string, string>) || {}),
	};

[gemini-code-assist]

The current header merging order causes the forwarded Authorization header from getMcpHttpAuthHeadersForInternalFetch() to be overwritten by the default system-wide OMNIROUTE_API_KEY (if configured). To ensure forwarded user credentials take precedence over the system-wide API key, place the default Authorization header before spreading the forwarded headers.

Suggested change

	const headers: Record<string, string> = {
	"Content-Type": "application/json",
	...getMcpHttpAuthHeadersForInternalFetch(),
	...(OMNIROUTE_API_KEY ? { Authorization: `Bearer ${OMNIROUTE_API_KEY}` } : {}),
	...((options.headers as Record<string, string>) || {}),
	};
	const headers: Record<string, string> = {
	"Content-Type": "application/json",
	...(OMNIROUTE_API_KEY ? { Authorization: `Bearer ${OMNIROUTE_API_KEY}` } : {}),
	...getMcpHttpAuthHeadersForInternalFetch(),
	...((options.headers as Record<string, string>) || {}),
	};

[gemini-code-assist]

According to the Repository Style Guide (Rule 1, File Placement & Organization), all unit tests, integration tests, ecosystem tests, or Vitest files must strictly be placed within the tests/ directory (e.g., tests/unit/, tests/integration/). Please move this test file to the tests/ directory (e.g., tests/unit/mcp-server/httpAuthContext.test.ts).

References

1. All unit tests, integration tests, ecosystem tests, or Vitest files must strictly be placed within the tests/ directory. ^(link)

[diegosouzapw]

Thanks @KooshaPari! Rebased your two commits cleanly onto the current release tip (the PR was base-stale, inflating the diff). The AsyncLocalStorage request-scoped approach is the right one — no cross-request leakage (your does not leak outside wrapped request test confirms it), x-api-key only forwarded alongside its anthropic-version contract header, and forwarding only targets internal same-origin API endpoints (no SSRF / no privilege escalation, since it's the caller's own auth). All 6 vitest cases pass in a clean env. Merging into release/v3.8.40.

Note: precedence is forwarded caller auth then env OMNIROUTE_API_KEY (env wins when set) — preserves prior behavior; #5211's no-env-key path forwards correctly.