Frontend 1.51.10: Partner/API Nodes fail on remote non-Cloud origins due to cloud.comfy.org workspace CORS

### Prerequisites

- [x] I am running the latest version of ComfyUI
- [ ] I have custom nodes enabled

### What happened?

Partner/API Nodes fail with `Unauthorized: Please login first to use this node` when ComfyUI is accessed through a remote non-Cloud origin such as RunPod's HTTPS proxy:

`https://-8188.proxy.runpod.net`

I reproduced this with:

- ComfyUI `0.35.0`
- `comfyui-frontend-package 1.51.10`
- Linux / RunPod
- Chrome/Chromium

I am correctly signed into my Comfy account. The frontend shows the logged-in user, but when a Partner/API Node is executed it reports that login is required.

The browser console shows that the frontend repeatedly requests:

`https://cloud.comfy.org/api/workspaces`

from the RunPod origin, but the request is blocked by CORS:

> Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.

The console also reports:

`[teamWorkspaceStore] Init failed`
`WorkspaceApiError: Network Error`

After that initialization failure, executing an API Node such as `OpenAIGPTImageNodeV2` results in:

`Unauthorized: Please login first to use this node.`

### Important comparison

The issue is NOT reproducible with the same new frontend on a normal local installation:

- Windows / Pinokio
- ComfyUI `0.35.0`
- Frontend `1.51.10`
- `http://127.0.0.1:8188`

Partner/API Nodes work correctly there.

The issue also disappears on RunPod if I downgrade ONLY the frontend:

- ComfyUI `0.35.0`
- Frontend `1.49.6`

With this combination, the same Partner/API Node works correctly through the RunPod proxy.

So the observed behavior is:

| Environment | Frontend | Result |
|---|---:|---|
| Windows / localhost | 1.51.10 | ✅ Works |
| RunPod remote HTTPS proxy | 1.51.10 | ❌ CORS / Unauthorized |
| RunPod remote HTTPS proxy | 1.49.6 | ✅ Works |

This strongly suggests a regression or behavioral change affecting remote self-hosted/non-Cloud origins rather than a problem with ComfyUI 0.35.0 itself or the Partner API service.

### Steps to Reproduce

1. Start ComfyUI `0.35.0` with `comfyui-frontend-package 1.51.10` on a RunPod instance.

2. Expose ComfyUI port `8188` through RunPod's HTTPS proxy and open:

`https://-8188.proxy.runpod.net`

3. Sign in to a Comfy account from the ComfyUI frontend.

4. Add an official Partner/API Node such as:

`OpenAIGPTImageNodeV2`

5. Connect it to `Preview Image`.

6. Run the workflow.

7. The frontend displays:

`Sign In Required to Use API Nodes`

even though the user is already signed in.

8. The ComfyUI backend logs:

`Unauthorized: Please login first to use this node.`

9. Open Chrome DevTools → Console / Network.

10. Observe requests to:

`https://cloud.comfy.org/api/workspaces`

failing with CORS from origin:

`https://-8188.proxy.runpod.net`

11. Install frontend `1.49.6` without changing the ComfyUI backend:

`python -m pip install --force-reinstall --no-deps comfyui-frontend-package==1.49.6`

12. Restart ComfyUI and run the same API Node again.

13. The API Node now executes successfully through the same RunPod proxy.

### Workflow

N/A — the issue is not workflow-specific.

It can be reproduced with a minimal workflow containing only:

`OpenAIGPTImageNodeV2 → PreviewImage`

No custom nodes are required to trigger the authentication/CORS issue.

### How is this affecting you?

Workflow won't execute

### ComfyUI Frontend Version

1.51.10

### Browser

Chrome/Chromium

### Console Errors

```javascript
Access to XMLHttpRequest at 'https://cloud.comfy.org/api/workspaces'
from origin 'https://-8188.proxy.runpod.net'
has been blocked by CORS policy:

Response to preflight request doesn't pass access control check:
No 'Access-Control-Allow-Origin' header is present on the requested resource.

GET https://cloud.comfy.org/api/workspaces net::ERR_FAILED

[teamWorkspaceStore] Init failed: WorkspaceApiError: Network Error
```

### Logs

```shell
ComfyUI version: 0.35.0
comfyui-frontend-package version: 1.51.10
comfyui-workflow-templates version: 0.11.57
comfyui-embedded-docs version: 0.5.11
Python version: 3.12.3
PyTorch version: 2.10.0+cu130
GPU: NVIDIA GeForce RTX 3090
OS: Linux
ComfyUI-Manager: 3.41

[INFO] got prompt
[ERROR] !!! Exception during processing !!! Unauthorized: Please login first to use this node.

Traceback (most recent call last):
File "/workspace/ComfyUI/comfy_api_nodes/nodes_openai.py", line 751, in execute
response = await sync_op(
File "/workspace/ComfyUI/comfy_api_nodes/util/client.py", line 142, in sync_op
raw = await sync_op_raw(
File "/workspace/ComfyUI/comfy_api_nodes/util/client.py", line 272, in sync_op_raw
return await _request_base(cfg, expect_binary=as_binary)
File "/workspace/ComfyUI/comfy_api_nodes/util/client.py", line 841, in _request_base
raise Exception(msg)

Exception: Unauthorized: Please login first to use this node.

[INFO] Prompt executed in 0.18 seconds
```

### Additional Context

### Regression isolation

I tested different frontend/backend combinations to isolate the problem.

#### Failing

```text
ComfyUI: 0.35.0
Frontend: 1.51.10
Environment: RunPod
Origin: https://-8188.proxy.runpod.net
Result: ❌ Partner/API Nodes fail

Working after changing only the frontend

ComfyUI: 0.35.0
Frontend: 1.49.6
Environment: same RunPod setup
Origin: same *.proxy.runpod.net domain
Result: ✅ Partner/API Nodes work

Also working locally with the new frontend

ComfyUI: 0.35.0
Frontend: 1.51.10
Environment: Windows / Pinokio
Origin: http://127.0.0.1:8188
Result: ✅ Partner/API Nodes work

This makes RunPod itself unlikely to be the root cause. The issue appears to be the combination of the newer frontend workspace/auth flow and a remote non-Cloud browser origin.

Possibly related frontend change
This may be related to:
- #15164 — feat(workspace): enable local credit workspace switching FE-1584
- #15558 — backport of #15164 to core/1.51

The current workspace URL logic routes non-Cloud distributions to the Comfy Cloud gateway:

export function workspaceApiUrl(route: string): string {
return isCloud
? api.apiURL(route)
: `${getComfyCloudBaseUrl()}/api${route}`
}

This means a remote self-hosted ComfyUI instance is treated as non-Cloud and requests:
https://cloud.comfy.org/api/workspaces
The Local/Desktop workspace work specifically mentions CORS support for non-Cloud clients / loopback origins.
This could explain the difference:
http://127.0.0.1:8188
→ allowed / works

https://-8188.proxy.runpod.net
→ CORS blocked
I have not performed a commit-by-commit bisect, so #15164 / #15558 are only suspected as the regression area, not confirmed as the exact root cause.
Why this matters
This potentially affects remote self-hosted ComfyUI installations such as:
- remote GPU servers
- Jupyter/hosted proxies
- reverse-proxied ComfyUI
- custom HTTPS self-hosted domains
These installations are still non-Cloud/OSS ComfyUI from the frontend distribution perspective, but their browser origin is not localhost.
A remote self-hosted origin should ideally be able to use Partner/API Nodes without workspace authentication failing because the origin is not part of a fixed CORS allowlist.

Start with the workspaceApiUrl logic and the changes referenced in #15164 and #15558. Reproduce the workspace request and Partner/API Node failure on a remote RunPod origin, then compare frontend 1.51.10 with 1.49.6. Done means a remote non-Cloud origin can load /api/workspaces and execute the API node without the false sign-in error.

Written by the indexing model from the issue text.