AI-Chat Command Authentication Integrity Automation: Every Question Answered With HTTP 401, Zero Rows in the History Table

A feature that fails loudly and inconsistently gets noticed and reported quickly — someone hits an error, describes it, and it gets triaged. A feature that fails the exact same way every single time, from the very first day it shipped, is a different and more dangerous kind of invisible: there's no "it used to work" moment to notice, no intermittent success to contrast the failure against, and a person trying it once and seeing a generic error message has no way to tell whether the feature is fundamentally broken or whether they simply asked a bad question. The failure blends into the background as "this feature apparently doesn't work well," rather than surfacing as the specific, fixable defect it actually is.

An endpoint that enforces authentication before running any of its own business logic is doing exactly what a secure endpoint should do — reject an unauthenticated caller immediately, before spending any compute on a request that was never going to be allowed through anyway. That correct design choice has a specific consequence when the CALLING code accidentally omits the credentials it's supposed to send: the failure becomes total and uniform. There's no partial success, no "it works for simple questions but not complex ones" — every single call fails at the exact same gate, for the exact same reason, which paradoxically makes the defect harder to diagnose from the outside precisely because the failure never varies.

The defect was discovered as part of a wider audit of Run's infrastructure settings screens, and its root cause traces to an earlier, unrelated refactor: the natural-language command feature's edge function had been renamed from an older, related function used for a different purpose, and during that rename, the two headers the calling code needs to send — an API key header and a bearer authorization token — were dropped from the fetch call. Because the target edge function runs with strict JWT verification enabled, meaning it authenticates the caller before executing a single line of its own logic, every request arriving without valid credentials was rejected immediately with HTTP 401.

The proof this was a complete, 100% failure rather than an intermittent one is direct and measurable: the database table the edge function writes a row to on every successfully processed question had exactly zero rows. Not a low number, not a recent gap — zero, for the entire time the feature had been reachable. Compounding the diagnosis, the two now-unused import statements for the exact functions needed to construct those missing headers were still present in the file, unreferenced by any code — a clear signature that the header-sending logic used to exist in this file and was deleted, most likely by accident during the rename, rather than the feature having shipped incomplete from the start.

The fix restores both headers to the request: the API key header set to the project's public anonymous key, and the bearer authorization header set to the user's own stored access token when one exists (falling back to the anonymous key otherwise, matching the same pattern already used by a comparable feature elsewhere in the product). The fix goes one step further than restoring bare functionality: where the request previously threw a bare, unadorned HTTP status code with no further detail, it now attempts to read and include the server's own error message (capped at 200 characters) in the thrown error — specifically so that a future failure, whatever its cause, arrives as a diagnosable message rather than a status code that looks identical whether the actual problem is an AI usage quota, a malformed question, or something else entirely.

Someone opens the operations command box and asks a plain-language question about the current workload. Before the fix, this always produced the same generic "Error: HTTP 401," regardless of the question — the request never got past the edge function's own authentication check. After the fix, the same question reaches the AI backend, gets a real answer, and is logged as a genuine row in the history table for the first time.

A feature that had answered zero questions since it shipped now genuinely answers them, with every request actually reaching the backend it was always meant to reach. And because the fix also preserves the server's own error detail rather than a bare status code, a future failure — a usage limit, a malformed request, anything else — now arrives as something a person can actually act on, rather than the same uninformative message this feature always produced before.

This is a fix to an authentication defect that made an existing feature completely non-functional — it does not add new capabilities to the natural-language command feature's own underlying logic, which was never the actual problem. A team expecting new question types or expanded scope from this specific fix will not find that here; what changed is that the feature's existing scope is now actually reachable.

Reporting a bare HTTP status code on failure treats every possible cause the same way — a missing credential looks identical to a usage-quota limit, which looks identical to a malformed request. Centriu Run's fix specifically preserves the backend's own error detail in what gets thrown to the user, so that whatever causes a future failure, the resulting message actually distinguishes it from every other possible cause, rather than repeating the same uninformative code regardless of what actually went wrong.