Gemini: /models generates error

[Statter]

The same installation and steps to reproduce #6018

Now my attempt to get a models list generates the following:

Any way I still can get a model directly and auto-completion is working:

I'm using "Red Shield VPN". One key finding is that I'm trying to use the "codewhale" under VPN from a country that is blocked (Lithuania)
After I had switched to "Poland | Gemini AI" location, all is working fine

[github-actions]

Thanks @Statter for the report.

This issue is staying open for maintainer triage. CodeWhale gets better because people bring us real edge cases from real machines, providers, regions, and workflows.

If you can add a reproduction, logs, version output, screenshots, or the provider/model involved, that makes it much easier for us to verify and harvest the fix. Maintainers may comment /lgtmi to mark recurring issue reporters as approved so this intake note is skipped next time.

[Hmbown]

Diagnosed. It is our bug, not a Gemini one — but the fix is not the one-liner it first looks like, so recording the whole thing here.

What you are actually seeing

Look closely at the message in your first screenshot:

Failed to fetch models from Google Gemini: Invalid request (400):

It ends at the colon. That colon introduces the provider's reason, and the reason is missing. Gemini did tell us why — something like User location is not supported for the API use. — and we discard it before showing you.

Cause: Client::models_document fetches the catalog via send_with_retry_error_body(build, false), and that flag decides whether the HTTP error body is read at all:

let body = if include_error_body {
    sanitize_http_error_body(...)   // the provider's reason
} else {
    String::new()                   // <- what /models gets
};

So the error becomes InvalidRequest { status: 400, message: "" } and renders as Invalid request (400): with nothing after it. That is why this was so hard to diagnose from your side: a geo-blocked region, a bad key, and a wrong endpoint all produce the identical empty message. You had to find the region cause by changing VPN exits, which you should not have had to do.

Why the obvious fix is wrong

I flipped that flag to true and it worked — the geo-block reason came through, and a regression test reproduced your exact string. Then the full suite caught this:

later_page_http_and_transport_errors_do_not_expose_cursor_or_key mounts an error body that deliberately contains the API key, the pagination cursor, and a header value, and asserts none of them reach the user:

{"error":{"message":"bad cursor {CURSOR}; key {KEY}; custom-header-canary"}}

A provider — or anything impersonating one at a URL you typed during setup — can echo your API key back inside an error body. The catalog fetch is exactly where an untrusted base_url gets probed, so suppressing the body there is a deliberate, tested decision, not an oversight. The streaming path can afford true because by then the endpoint is established.

So I reverted it. Surfacing the body without a redaction step would trade an unhelpful message for a credential leak, which is a bad trade.

What the real fix looks like

Show the provider's reason, but only after removing material the client itself knows is secret — the configured API key, the configured custom header values, and the pagination cursor — and fall back to today's suppressed behavior if any of them still appear. The client has all three to hand, so this is tractable; it is just a trust-boundary change that deserves review rather than a 4am flag flip.

That keeps your case working (Gemini's geo-block text contains none of those) while keeping the canary test honest.

Deliberately not proposing: special-casing region errors into bespoke advice. Showing the provider's own words is the general fix and does not go stale when Google changes its wording.

Filing that as the follow-up. Thank you for the screenshot — the truncated colon is the entire tell, and it would not have been visible from the text alone.

[Hmbown]

claiming: implementing the redaction-then-surface fix from the diagnosis — show the provider's own reason from a catalog error body, after removing what this client knows is secret, and fall back to today's suppressed body if anything survives.

Files: crates/tui/src/client.rs (send_with_retry_error_body takes a disclosure policy instead of a bool; models_document passes the guarded one), and crates/tui/src/client/catalog_tests.rs. The later_page_http_and_transport_errors_do_not_expose_cursor_or_key canary stays exactly as it is — it is the gate this has to pass, not a test to loosen.

[Hmbown]

Fixed by 87754c1c9 on fix/lost-work-batch-a-20260915 (local branch — not pushed).

@Statter — your screenshot was the whole diagnosis. The message ending at the colon is what told us Google's reason was being thrown away rather than never sent. You should not have had to find the cause by changing VPN exits, and after this you would have seen Google's own words: User location is not supported for the API use.

What changed, following the plan in the comment above rather than the flag flip:

send_with_retry_error_body's include_error_body: bool is now an ErrorBodyDisclosure. Full is the established-endpoint path, unchanged. Guarded is the catalog probe, and it redacts before it surfaces:

• the active API key, at any length — no MIN_EXACT_SECRET_CHARS floor here, because a short key echoed back by an untrusted endpoint is still a leaked key;
• every user-configured HTTP header value, not only the auth-shaped ones;
• everything already in model_bound_secret_values;
• the request's own query values — the pagination cursor — in both decoded and percent-encoded form, since a provider that parsed it and one that quoted the URL back echo different bytes.

Redaction runs on the raw body, before sanitize_http_error_body truncates it, so a secret cannot be split across the truncation boundary and survive as a fragment. The sanitized result is then re-checked against the same set and dropped entirely if anything survived — so the failure mode is exactly today's suppressed message, not a weaker guard.

catalog_error_secret_values is a second list rather than a widening of model_bound_secret_values, deliberately: that one answers "what must never reach a model" and its auth-header-only, 8-character-minimum shape is correct for that question. This one answers "what must never come back out of an endpoint the user typed during setup". Same values, different boundary, different rules.

The canary is untouched. later_page_http_and_transport_errors_do_not_expose_cursor_or_key still mounts a body containing the key, the cursor and a custom header value, and still passes — now because all three are redacted rather than because the whole body is dropped.

test result: ok. 14 passed; 0 failed; 0 ignored; 0 measured; 12728 filtered out; finished in 1.14s  (client::catalog_tests::)
test result: ok. 520 passed; 0 failed; 0 ignored; 0 measured; 12222 filtered out; finished in 7.10s (client::)

New test: catalog_errors_surface_the_provider_reason_without_client_secrets reproduces your case — a 400 whose body is Google's FAILED_PRECONDITION message — and asserts the reason reaches the user. Against the old code the surfaced string is Invalid request (400): and it fails. A second mock returns the same reason plus the key and a custom header value, and asserts the reason survives while they do not.

cargo fmt --all -- --check clean; CI's clippy line clean on -p codewhale-tui --all-targets --all-features.

Limits, stated rather than implied. This removes what the client knows is secret; a credential configured outside Codewhale (in a proxy, for instance) is not in that set — the same limit redact_model_bound_text already has, now written down beside the code. And no special-casing of region errors into bespoke advice: showing the provider's own words is the general fix and does not go stale when Google changes its wording.

Not verified against a live geo-blocked endpoint — I have no VPN exit in a blocked region. The evidence is the mocked 400 above plus your screenshot.