Feature/local workspace run

[zhoumzh]

🚀 Feature: Full Local Workspace Execution & Dynamic UI Hot-Reloading

📝 Overview

This Pull Request introduces the capability to fully deploy and execute the OpenAgents Workspace (Backend + Frontend) in a localized environment, entirely decoupled from Docker. It also enhances the OpenAgents Launcher by enabling dynamic, runtime configuration of the Workspace Endpoint directly from the Settings UI, streamlining the developer experience and drastically reducing latency.

✨ Key Features & Enhancements

1. 🔄 Dynamic Workspace Switching (Hot-Reloading)

• UI Configuration: Added a new Default Workspace Endpoint input field in the Launcher's Settings -> Workspaces tab.
• Immediate Hot-Reload: Changing the endpoint dynamically hot-reloads the core AgentConnector via IPC without requiring a Launcher restart. Developers can seamlessly toggle between production (workspace-endpoint.openagents.org) and local endpoints (http://localhost:8000).

2. 🏠 Localized Workspace Deployment

• Rapid Local Startup: Added make dev-local-frontend and make dev-local-backend scripts to the Workspace Makefile, allowing developers to spin up the FastAPI backend and Next.js frontend instantly without Docker overhead.
• Database Migration Fixes: Resolved PostgreSQL UUID type mismatch issues in Alembic migration scripts (005) that caused foreign key failures during initial local schema setup. Provided the missing script.py.mako template to ensure future local autogenerations work flawlessly.

3. 🌐 Intelligent Browser Routing

• Smart Local Mapping: When an agent is connected to a local workspace (localhost:8000), clicking "Open Workspace in Browser" inside the Launcher now correctly maps the URL to the Next.js local frontend port (http://localhost:3001/...) instead of the production domain, establishing a perfect end-to-end local loop.

🧪 How to Test

1. Start the local backend: cd workspace && make dev-local-backend
2. Start the local frontend: cd workspace && make dev-local-frontend
3. Launch the OpenAgents desktop app: cd packages/launcher && npm run start
4. Go to Settings -> Workspaces, set the endpoint to http://localhost:8000, and save.
5. Return to the Dashboard and create/connect a workspace to see the immediate effect against your local backend.

📚 Changelog

• Maintained detailed notes in changelogs/notes/2026-04-24-local-workspace-run.md.
• Appended features to root CHANGELOG.md under [0.6.9].

[vercel]

Someone is attempting to deploy a commit to the Raphael's projects Team on Vercel.

A member of the Team first needs to authorize it.

[zomux]

Hey @zhoumzh — the Gemini bits from this PR landed via #357 (8d79ed0 + revert 9f5b3f7). For the rest, we'd like to merge the launcher-side improvements but need to ask you to remove the alembic migration changes before we can take this PR. Brief explanation:

Why the alembic changes are blocking

The catchup migration 1c617c141e29_catchup_missing_tables.py (revises 007) was auto-generated against a fresh local DB, so it tries to:

• op.create_table('files'), create_table('browser_usage'), create_table('browser_tabs')
• op.add_column('channels', 'title_manually_set'), add_column('channels', 'resume_from')
• op.add_column('workspace_members', 'description')
• op.alter_column('browser_contexts', 'shared_with', JSON → JSONB)

Every one of those tables/columns already exists on the production workspace-backend DB (Railway Postgres, restored from Supabase last weekend with alembic_version=007 and full schema). The next deploy after this lands would run alembic upgrade head in entrypoint.sh, hit relation "files" already exists, exit 1, and the workspace-backend container won't boot.

The modifications to migrations 005 and 006 are also problematic — alembic only checks revision IDs, not migration content, so once a DB has applied them, it won't re-apply. Anyone bootstrapping a fresh DB after these land gets a different schema than anyone who set up before, which means schema drift across environments.

What we'd like

Could you split this PR into two:

1. Keep here (we can merge after a rebase):

   • workspace/Makefile — dev-local-backend / dev-local-frontend targets
   • packages/launcher/src/renderer/{index.html,renderer.js} — Settings UI for switching workspace endpoint, smart localhost:3001 browser routing
   • packages/launcher/src/main/main.js — IPC reload-on-workspaceEndpoint-change handler
   • The CHANGELOG + notes file for local-workspace-run

2. Submit separately as a properly-idempotent PR (or a non-alembic init script):

   • The three alembic files (005, 006, 1c617c141e29)
   • Real fix is either IF NOT EXISTS / conditional op.execute() blocks in a single forward migration, or a separate workspace/backend/scripts/init-local.sql that bypasses alembic for the local-bootstrap case

The local FK type mismatch in 005 is a real bug (we hit it ourselves trying to apply alembic to a fresh DB during the #363 review), so a proper fix is welcome — just needs to not break already-applied DBs.

Once you've got the rebase ready, ping us and we'll pull it in. Thanks for the launcher polish work — the dynamic-endpoint + localhost:3001 routing in particular is going to make local dev a lot less painful.

[zomux]

Review — Changes Requested

This PR has grown beyond its original scope and has several issues to address:

Blocking

1. Merge conflicts — PR cannot be merged as-is. Needs rebase on develop.

2. CI failures — Lint, sdk-tests (3.10-3.12), and client-tests (3.10-3.12) all fail.

3. Security: backend binds 0.0.0.0 — The Makefile dev-local-backend target uses --host 0.0.0.0, exposing the backend to the entire LAN with hardcoded Postgres credentials (postgres:postgres). Should bind 127.0.0.1.

4. Global polling interval regression — BaseAdapter polling changed from 2s/15s-max to 1s/3s-max. This 5x increase in request frequency affects ALL adapters hitting production, not just local. Needs to be gated on local mode or made configurable.

5. Migration path broken for existing databases — Migration 006 was gutted to pass, but the catchup migration creates browser_tabs with context_id from scratch. This only works for fresh databases — existing production databases that already ran the original 006 will have a broken migration path.

Should Address

6. Scope creep — PR bundles three separate features: (1) local workspace support, (2) full Gemini adapter (~426 lines), (3) launcher dev-mode improvements. These should be separate PRs for reviewable, bisectable history.

7. No tests — Zero test coverage for the Gemini adapter, endpoint switching, or local routing.

8. Blog post in production code — changelogs/blogs/2026-04-23-gemini_integration_journey.md doesn't belong in the repo's main branch.

Recommendation

Split into at least two PRs (Gemini adapter vs. local workspace), rebase on develop, fix CI, scope the polling change, and validate the migration path for existing databases.