Architecture: How should the Chrome extension resolve the correct gograb-a...

Documentation for Sessions

🏗️ Architecture: How should the Chrome extension resolve the correct gograb-a...

Date: 2026-02-11
Time: 15:15:45 UTC
Session: gspace1-105.7
Agent: storage
Confidence: 95%
Status: ✅ Documented

📋 Decision Context

Question:

How should the Chrome extension resolve the correct gograb-ai server URL across different workspaces (editor2=5400, gspace1=6400, etc)?

Task: Session 105.3: Implement workspace-resilient port auto-detection for Chrome extension

🎯 Decision Made

Chosen:

Runtime port auto-detection — sidepanel.js probes KNOWN_AI_PORTS=[5400, 6400, 4200] in parallel using fetch HEAD requests, picks the first responding server, and dynamically derives both AI_APP_URL and MAIN_APP_URL from the resolved port's workspace base (Math.floor(port/1000)*1000).

Options Considered:

  1. Hardcode port in dev-ports.js per workspace
  2. Read port from .env.local at build time
  3. Runtime port auto-detection — probe known ports to find running server
  4. Use a fixed port across all workspaces

💭 Reasoning

This is the most resilient approach because: (1) The extension may be loaded from any workspace directory but only one server runs at a time. (2) Hardcoding requires rebuilding/reloading the extension when switching workspaces. (3) Build-time injection from .env.local only works if the extension is rebuilt. (4) Auto-detection at runtime makes the extension work regardless of which workspace it was loaded from — it simply finds whichever gograb-ai server is actually running. The probe is fast (parallel fetch with 2s timeout) and the KNOWN_AI_PORTS list covers all configured workspace ports. MAIN_APP_URL is derived using the workspace port convention: spacePort = workspaceBase + 200 (e.g., 6000+200=6200 for gspace1).

📁 Files Involved

🔗 Related

Auto-generated by MCP Smart Consolidation