Bugfix: Why did 'Sign in with GoGrab' in Vitto Desktop open the land...

Documentation for Sessions

🐛 Bugfix: Why did 'Sign in with GoGrab' in Vitto Desktop open the land...

Date: 2026-02-26
Time: 19:14:38 UTC
Session: gspace1-144.14
Agent: angular
Confidence: 97%
Status: ✅ Documented

📋 Decision Context

Question:

Why did 'Sign in with GoGrab' in Vitto Desktop open the landing page instead of the gograb-ai app?

Task: Fix Vitto Desktop auth redirect and local dev workflow

🎯 Decision Made

Chosen:

Changed desktopAuthBaseUrl from 'https://app.gograb.space' to 'https://ai.gograb.space' in environment.prod.ts. The gograb-ai app is deployed to Cloudflare Pages project 'gograb-ai-app' which maps to ai.gograb.space (per deploy-ai.sh), NOT app.gograb.space.

Options Considered:

  1. Change desktopAuthBaseUrl to ai.gograb.space (chosen — matches deploy-ai.sh)
  2. Create CNAME app.gograb.space → gograb-ai-app.pages.dev (fragile — two sources of truth)
  3. Use relative URL /auth/desktop (won't work — Tauri loads from file://, not a web origin)

💭 Reasoning

ROOT CAUSE: The Cloudflare Pages deployment script (deployment/cloudflare/deploy-ai.sh) deploys the gograb-ai Angular app to project 'gograb-ai-app' with PROD_URL='https://ai.gograb.space'. But environment.prod.ts had desktopAuthBaseUrl set to 'https://app.gograb.space' — a completely different domain that serves the gograb-landing marketing page. When the user clicked 'Sign in with GoGrab', TauriBridge opened the system browser to app.gograb.space/auth/desktop, which loaded the landing page SPA (which catches all routes with a 200 but renders marketing content, not the auth form). The /auth/desktop route only exists in the gograb-ai app at ai.gograb.space. EARLY WARNING: Always verify desktopAuthBaseUrl matches the PROD_URL in deploy-ai.sh after any deployment infrastructure change.

📁 Files Involved

🔗 Related

Auto-generated by MCP Smart Consolidation