fix(ui): elizacloud.ai apex lands authenticated users on the cloud console (credits/manage), not chat

[NubsCarson]

Problem

elizacloud.ai (the cloud console) and app.elizacloud.ai (the agent app) serve the same packages/app bundle, and CloudRouterShell kept "chat is home" on every host. So when you're signed in, both domains render the identical chat app — and the apex never shows the thing it exists for: add credits / manage your account. (Unauthenticated apex already correctly redirects to Steward /login; this is only the authenticated landing.)

Fix

AppCatchAllRoute now, on an apex control-plane host (elizacloud.ai / www / staging / dev), sends an authenticated visitor who lands on the bare root / to the console home — /settings#billing, the canonical credits/billing surface (every in-app billing link resolves here; its tabbed shell of Billing · Developer/API keys · Connections · Organization is the account-management hub).

Deliberately narrow:

• Unauthenticated apex → /login: unchanged.
• Authenticated apex deep link (a shared agent, a deep link): still renders the app, so those links keep working — only the bare landing is rerouted.
• Every non-apex host (per-agent subdomains, app.elizacloud.ai, localhost): untouched — chat stays home.
• No redirect loop: /settings isn't an apex-console route, so it re-enters the catch-all at a non-root path and renders the app, which reads #billing.

Why /settings#billing and not a bespoke overview

The old @elizaos/cloud-frontend dashboard was dissolved into the app: dashboard/billing → /settings#billing, dashboard/api-keys → /settings#api-keys (see DASHBOARD_REDIRECTS). There is no standalone /dashboard overview route today, and /settings is the management hub (credits front-and-center + tabs for keys/connections/org). If we later want a dedicated overview page, flipping APEX_AUTHENTICATED_HOME is a one-line change.

Verification

• packages/ui unit suite CloudRouterShell.test.tsx — 7/7 pass, including the two new cases: apex+auth+root → console home, apex+auth+deep-link → agent app (deep links preserved). Existing cases (unauth→login, staging→login, per-agent subdomain→app, localhost→app) unchanged.
• biome check clean; tsgo typecheck clean on packages/ui.
• Frontend visual proof: N/A pre-deploy — the render target /settings#billing is an existing, unchanged, already-tested surface; this PR only changes which existing surface the apex root lands on. Once it deploys to staging.elizacloud.ai, an authenticated visit to the apex root should land on the billing/credits page instead of chat (will attach the staging screenshot on deploy).

Closes the console-UX half of the launch console issue. Prod (elizacloud.ai) additionally needs a deliberate develop→prod promote to leave the current frozen build — tracked separately.

[greptile-apps]

Your trial has ended. Reactivate Greptile to resume code reviews.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 819653f4-8e59-4620-bfd8-bb6fcb56fdb7

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/apex-console-lands-on-dashboard

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[lalalune]

Reviewed — the code is merge-ready (fresh, not a stale reformat; base was 3 commits behind; 2 files, no riders; APEX_AUTHENTICATED_HOME = "/settings#billing" guarded on pathname === "/" && !hash; redirect target + apex-host exclusions verified against current tip; 7/7 tests pass on a merge-preview worktree at develop tip; biome clean; merges clean).

Held on one thing: product authorization. This changes the authenticated apex landing from chat to the console/billing surface — a product-behavior change, and this repo's scope-discipline rule is to not ship product behavior without an authorizing issue/comment. I couldn't find one: the body cites "the launch console issue" with no number, and the nearest authority (#10725 — elizacloud.ai becoming minimal, agent-first setup + hosted must-haves incl. billing) is directionally supportive but doesn't specify apex-lands-on-console. The prior documented behavior (chat stays home, from the dashboard→app collapse) is what this changes.

Unblock: a one-line maintainer/product confirmation that authenticated apex should land on console/billing (ideally linking #10725) and this merges as-is — nothing in the code needs to change. Also worth attaching the promised post-deploy staging screenshot to satisfy the packages/ui rendered-evidence gate.

[lalalune]

Reviewed and merged. Clean, narrowly-scoped UI-routing fix: on an apex control-plane host an authenticated visitor on the bare root (path === '/' and no hash) is redirected to the console home (/settings#billing), while unauthenticated → /login (unchanged), authenticated deep links still render the app, and non-apex hosts (app subdomain, per-agent, localhost) are untouched. The no-redirect-loop reasoning holds — /settings isn't an apex-console route so it re-enters the catch-all at a non-root path and renders the app. Guarding on '!location.hash' correctly prevents re-triggering once the #billing hash is present. 7/7 CloudRouterShell tests including the two new apex-root vs deep-link cases.