Generated by AI agent: route portal extension-pages.json at console, not localhost

[Brandoffsky]

Ticket

https://disruptorbeam.atlassian.net/browse/BEAM-XXXX

Brief Description

RemotePortalConfigService.FetchRemotePortalConfig hardcodes the mount-site catalog URL:

-        var url = "http://localhost:4950/" + "/extension-pages.json";
+        var url = PortalCommand.GetPortalBaseUrl(args, PortalType.Console) + "/extension-pages.json";

This is an unreleased regression, not a live outage. The released CLI (7.2.2) derives the URL from the target host, so portal extension * works today against a dev realm. The hardcode is on main only — shipping it would fetch the catalog from localhost:4950 for every realm, for every developer, regardless of what they're pointed at.

Three reasons that's worse than it looks:

1. It fails silently. FetchRemotePortalConfig catches, warns, and returns an empty RemotePortalConfiguration(). So portal extension list-extension-options would report no mount options with nothing user-visible explaining why — only a log line. project new portal-extension, portal extension add-microservice and portal open-extension degrade the same way. A hard failure would at least be noticed.

2. It makes --portal-url inert. GetPortalBaseUrl consults the PortalUrlOption override first; a literal string never does. So while the URL is hardcoded, the documented escape hatch for pointing the CLI at a locally-running portal does nothing — the code is local-only, not local-first.

3. Consistency. BeamoLocalSystem_PortalExtension.cs already calls GetPortalBaseUrl(..., PortalType.Console) for the sibling path. Two call sites for the same catalog currently disagree.

Notes

On the PortalType choice. Both derivations serve the catalog for a dev realm, so Console is a direction/consistency call rather than a correctness one. Measured against /extension-pages.json:

target host	derives	result
dev.api.beamable.com — Console	dev.console.beamable.com	200
dev.api.beamable.com — LegacyPortal	dev-portal.beamable.com	200
api.beamable.com — Console	console.beamable.com	404
api.beamable.com — LegacyPortal	portal.beamable.com	404

Worth correcting an earlier version of this description: it claimed the LegacyPortal default "resolves to portal.beamable.com and 404s". That is true for prod only. The substitution is Replace("dev.", "dev-").Replace("api", "portal"), so a dev host yields dev-portal.beamable.com, which serves. Console is preferred here for consistency with the sibling call site and because the console host is where this is heading — not because Legacy is broken.

Prod does not publish the catalog under either name. That is a hosting-side gap rather than a CLI one, and worth routing to whoever owns console deploys; it is unchanged by this PR.

Also corrects the stale docstring on RemotePortalConfiguration, which still pointed at portal.beamable.com.

Checklist

• Have you added appropriate text to the CHANGELOG.md files?

Testing

No new tests. FetchRemotePortalConfig is a private static whose behaviour is a live HTTP fetch, with no existing coverage.

Verified by dotnet build cli/cli.csproj (0 errors), the endpoint checks in the table above, and end-to-end through beam mcp serve from an external consumer (Wingman coding mode, beamable/BeamableAPI#701) — which is where the silent-empty-config failure mode was observed, and which passes --portal-url through for local-portal development once this lands.

[github-actions]

Lightbeam link