fix: stop a pasted /v1 turning into a 404, and name the real failure

[brunobuddy]

Reported against the Wingman drawer inside a Manifest dev dashboard: a healthy gateway answering 404 Cannot POST /v1/v1/chat/completions. Reproduced, plus four more failures in the same area.

What was wrong

The base URL was concatenated with the format's endpoint path, unnormalised. The shapes people actually paste all break:

typed base URL	POSTed to	result
…/v1	…/v1/v1/chat/completions	404
…/v1/chat/completions	…/v1/chat/completions/v1/chat/completions	404
http://host	—	fetch threw Failed to parse URL, nothing sent
localhost:3001	https://wingman.manifest.build/localhost:3001/…	API key POSTed to our own origin

That last one is the one to look at twice: a schemeless base URL isn't a host the browser completes, it's a relative URL, so it resolved against Wingman's origin and shipped the user's bearer token there.

The failure diagnosis was wrong in the most common case. When fetch rejects, the browser reports DNS failure, connection refused, a CORS rejection and an address-space block identically. Wingman resolved that ambiguity by always blaming CORS. But an HTTPS page calling a gateway on localhost is gated by Chrome's Local Network Access permission — it replaced Private Network Access, and no server header satisfies it. Telling someone to add an origin to their allow-list sends them to fix something that was never broken. errorKind was computed in send.ts and rendered nowhere, so the UI showed a bare Failed to fetch.

The health badge went green next to a base URL that would 404. It resolved an absolute path against the origin, discarding the base path, so …/v1 probed the right health endpoint, reported reachable · 5ms, and then the send 404'd. That mismatch is most of the "works sometimes" feeling.

Changes

• normalizeBaseUrl — trims, infers a scheme (http:// for loopback hosts, https:// otherwise), validates the host, strips a duplicated endpoint path or trailing /v1. Provider bases that legitimately carry a path (Groq's /openai, OpenRouter's /api, Fireworks' /inference) are left alone; a gateway at …/api/v1 still resolves correctly.
• The connection panel shows the resolved POST <url> under the Base URL field, with a note when normalising changed something — a doubled /v1 is now visible before you hit Send.
• An unusable base URL is rejected before fetch sees it, with the reason shown.
• local-network and mixed-content failures are classified separately from CORS, and the guidance is rendered.
• The health badge names the URL it probed, so a green badge can't be read as more than it checked.

Tests

The repo had no test runner. Added vitest (60 tests) over the URL and diagnosis logic, wired into CI.

One test earns its keep immediately: Chrome accepts spaces in a host and percent-encodes them, where Node and jsdom throw. Relying on new URL() to reject not a url at all passed in jsdom and still let the request through in the real browser — caught by browser testing, now covered by an explicit host check.

Verification

Driven through a real Chrome against a local Manifest gateway (/serve), both standalone and inside the dashboard drawer:

• 16-case base-URL matrix: 7/16 correct before → 16/16 after (the two non-2xx are genuinely unreachable hosts, now correctly diagnosed rather than blamed on CORS).
• 9-case drawer matrix — streaming, all three wire formats, and each previously-404ing URL shape: 9/9, zero console errors. The displayed POST URL matched the actual POST URL in every case.

The drawer also needs mnfst/manifest#2579 — Chrome blocks the hosted HTTPS SPA from reaching a localhost gateway regardless of what Wingman does. This PR makes that failure legible; that one makes the drawer work.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
wingman	Ready	Preview	Jul 27, 2026 11:14am