Files
OmniRoute/tests
ikelvingo bbb967d584 fix(oauth): explain the LAN-IP loopback mismatch with an actionable panel
#8046 already stops the doomed login when a PKCE_CALLBACK_SERVER_PROVIDERS
provider (codex / xai-oauth / grok-cli) is connected from a LAN IP, but it
explained itself as one long English sentence rendered in the generic red
"Connection failed" step. Two concrete problems with that:

- the operator had to parse prose to work out WHICH ports to forward, and the
  command shipped with `<port>` / `<omniroute-host>` placeholders to resolve
  by hand;
- it forwarded a single port. Both are required: the dashboard port is what
  makes the origin true-localhost (a LAN origin never reaches the
  callback-server branch at all), and the provider's fixed callback port is
  where the browser is actually sent back to. Forwarding either one alone
  still fails.

buildPkceLoopbackMismatchHint() now returns the diagnosis as structured data
with the detected host and both ports already filled in, and a dedicated
OAuthLoopbackMismatchPanel renders it as: what happened -> how to fix, in
three numbered steps with copy-to-clipboard fields. No "Try again" button —
retrying the same origin fails identically. The panel yields to the
paste-token tab so grok-cli (which is in both provider sets) never stacks the
two views.

The flat warning string stays exported for non-UI callers.

docs: REMOTE-MODE.md gains a "Connecting Codex / Grok on a remote install"
section with the fixed-callback table and the two-port tunnel, mirroring the
existing Antigravity section.

i18n: 9 new oauthModal keys, hand-written for en + pt-BR and propagated to the
remaining 40 locales as `__MISSING__:` sentinels (runtime falls back to the
clean English value per #7258).
2026-07-24 17:25:37 -03:00
..
2026-07-13 09:12:40 -03:00
2026-07-06 02:25:17 -03:00
2026-07-13 09:12:40 -03:00
2026-06-13 17:27:40 -03:00