Files
OmniRoute/docs
diegosouzapw 384f06aa41 feat(cli): deliver the Antigravity credential straight to the remote install
`omniroute login antigravity` already runs the OAuth where it actually works — the
operator's own machine, the only place Google's firstparty/nativeapp loopback
resolves — but it stopped at PRINTING a credential blob to copy into the remote
dashboard by hand.

Every piece needed to close that loop was already in place:

- `omniroute connect <host>` saves an admin-scoped token in the active context;
- `apiFetch()` injects that context's baseUrl + Bearer automatically;
- `/api/oauth` requires admin scope (src/server/authz/accessScopes.ts) and stays
  remote-reachable — routeGuard.ts loopback-gates only `/api/oauth/cursor/auto-import`,
  with an explicit comment that the rest must remain reachable;
- `isAuthenticated()` accepts a Bearer management token;
- `/api/oauth/<provider>/paste-credentials` already decodes a blob and persists.

So the CLI now POSTs the blob itself whenever the active context points at another
machine. No paste, and no SSH tunnel.

What it deliberately does NOT do is make the push mandatory. This helper exists
because it needs no route to the VPS at all — it talks only to Google, so it works
from behind a firewall. A failed push therefore falls back to printing the blob
rather than discarding an authorization the operator just completed in a browser.
`--no-push` forces the old behaviour, `--push` forces delivery, `--context <name>`
targets a specific install.

A successful push does not echo the blob: it wraps a refresh token and it already
landed. Printing it would only widen the exposure.

Note for the follow-up: `oauth start --provider antigravity` cannot substitute for
this. `runBrowserFlow` asks the SERVER to start the flow and then polls the server,
so the callback still has to reach the server's loopback — it hangs on a remote
install exactly like the dashboard does.
2026-07-28 04:07:13 -03:00
..
2026-06-29 08:40:06 -03:00
2026-07-13 09:12:40 -03:00

title, version, lastUpdated
title version lastUpdated
OmniRoute Documentation 3.8.40 2026-06-28

OmniRoute Documentation

Navigable index of the OmniRoute documentation set. Topics are grouped by intent so you can find what you need quickly.

Looking for the project overview, install steps, or release notes? See the root README.md, CHANGELOG.md, and CONTRIBUTING.md.


For Non-Tech Users

Simple guides for using OmniRoute — no technical background needed.

getting-started/

guides/


For Tech Users

Technical documentation for developers and contributors.

architecture/

How the system is put together — read these to understand the runtime, code layout, and resilience model.

reference/

Lookup material — API surface, environment variables, CLI flags, provider catalog.

frameworks/

Pluggable subsystems exposed to clients, agents, and operators.

routing/

Combo routing, scoring, and replay.

security/

Guardrails, compliance, stealth, and the mandatory patterns for handling public credentials and error messages.

compression/

Prompt compression engines, rules, and language packs.

providers/

Provider-specific integration guides.

comparison/

ops/

Release, deployment, proxies, tunnels, coverage, database, monitoring.

diagrams/

Mermaid sources and exported SVG/PNG diagrams referenced from the docs above. See diagrams/README.md.

i18n/

Translated mirrors of the documentation in 43 locales. See i18n/README.md for the supported language list.

screenshots/

Static screenshots used by the dashboard and the README. Not part of the doc body.


Auto-generated artifacts

  • reference/PROVIDER_REFERENCE.md is generated by scripts/docs/gen-provider-reference.ts from src/shared/constants/providers.ts. Do not edit by hand.
  • The /docs UI is backed by Fumadocs MDX source generation from the subfolders above.