feat: open workspace pages in the SaaS app's /workspaces mount

Merged
RA
1mo ago
+111-33

Issue for this PR

Closes #1359

Type of change

  • Bug fix
  • New feature
  • Refactor / code improvement
  • Documentation

What does this PR do?

Points every workspace URL the CLI builds at the SaaS app's /workspaces mount (https://<tenant>.app.myaltimate.com/workspaces) instead of <tenant>.ws.myaltimate.com, which is being retired.

The base now carries a path, so the three joins had to keep it. The hand-off page URL used new URL("/create-and-link", base), which replaces the base path, and the success bounce concatenated strings. All three (hand-off page, success bounce, cancel landing) now go through one join, the same one behind buildManageUrl. Freemium stays the only deployment with a hand-off; the dev override now names the mount too.

Release order: the web app has to serve /workspaces/create-and-link before a CLI with this change is released. That web change is in review; hold the release until it is live.

Nothing ws-related is left for a follow-up in this repo: after this change no code path builds a ws host URL. Only binaries already released (up to v0.12.2) still do.

How did you verify your code works?

  • Unit tests: the hand-off base, the manage URL on a resolved base, the page URL, and the pages the loopback success and cancel responses bounce to (read from the served HTML). Six of the new assertions fail on main. 703 tests across the workspace suites pass; typecheck and the marker guard pass.
  • End to end against a local web app and backend: runHandoffWithOpener with the dev override set to the local mount, driving headless Chromium. Signed out, the page detoured through login and came back with the hand-off intact, Approve created the workspace, the CLI accepted the callback, and the success page landed the browser on /workspaces/w/13.

Screenshots / recordings

Consent page after the login detour, and where the success page lands:

consent after login
workspace page after return to CLI

Checklist

  • I have tested my changes locally
  • I have not included unrelated changes in this PR

🤖 Generated with Claude Code

https://claude.ai/code/session_01LXpVmgHbm9Qzn54SQPpqDK

Summary by cubic

I think the task is to write a PR description for this change. Here's my draft:

Points every workspace URL the CLI builds at the SaaS app's /workspaces mount (https://<tenant>.app.myaltimate.com/workspaces) instead of <tenant>.ws.myaltimate.com, which is being retired.

Key points

  • The base URL now carries a path, so three joins keep it: hand-off page, success bounce, and cancel landing all go through the same join behind buildManageUrl.
  • The hand-off page previously used new URL("/create-and-link", base), which replaced the base path; it now preserves the mount.
  • The dev override (ALTIMATE_WORKSPACE_WEB_URL) must now name the mount itself.
  • The localhost API still returns null — the browser flow stays unsupported in dev.

Release order

  • The web app must serve /workspaces/create-and-link before a CLI with this change is released; hold the release until it's live.

Testing

  • Six of the new unit assertions fail on main; 703 tests across the workspace suites pass, with typecheck and marker guard clean.
  • End-to-end with a local web app and backend verified the consent page after a login detour, and Approve landed the browser on /workspaces/w/13.

Summary by CodeRabbit

  • Updates
    • Workspace hand-off, management, and cancellation pages now use the app.myaltimate.com domain and the shared /workspaces URL path.
    • Workspace links preserve the /workspaces path when redirecting from the browser.
    • Updated terminal hyperlink coverage to match the new workspace URL format.