[bug] bl auth login --console never completes on Chrome: local callback server omits Access-Control-Allow-Private-Network

Summary

Update (follow-up comment below): I have since tested this on every engine. Chrome, Brave and Arc block it as described here; Safari blocks it too, as mixed content, which no server header can fix; Firefox is the only browser that completes the flow. Importantly, adding the header below is necessary but not sufficient on Chrome 152 — I proxied the callback with Access-Control-Allow-Private-Network: true present and Chrome still refused to send the POST, because it is now gated by a permission. See the follow-up for the full matrix, the proxy evidence, and revised suggestions.

bl auth login --console never completes in Google Chrome. The browser page reaches "Authorize CLI Login", the click succeeds against the console backend, but the token is never delivered to the CLI: the local callback server rejects the browser's Private Network Access preflight, so the fetch is blocked and the CLI waits forever.

The fix is one response header on the local callback server.

Environment

bl --version	1.20.0
Node.js	v24.15.0
OS	macOS 26.6.2 (arm64)
Browser	Google Chrome 152.0.7977.83
Console site	international (--console-site international)

Reproduced consistently. Not specific to one account.

Steps to reproduce

1. Make Google Chrome the default browser.
2. Run:

   bl auth login --console --console-site international
   

3. The CLI prints Opened the login page in your default browser... and starts listening on 127.0.0.1:<port>.
4. Chrome opens https://modelstudio.console.alibabacloud.com/console-login?notice=127.0.0.1:<port>&state=<state>.
5. Click Authorize CLI Login.

Expected

The page posts the token to http://127.0.0.1:<port>/?state=<state>, the CLI stores access_token in the active profile of ~/.bailian/config.json, and the command exits successfully.

Actual

The button shows a loading state forever. The CLI keeps waiting and writes nothing: ~/.bailian/config.json is unchanged and has no access_token, so every bl usage ... subcommand keeps failing with:

{"error":{"code":3,"message":"No console access token found.","hint":"Run `bl auth login --console`."}}

Chrome DevTools console on the authorize page:

Access to fetch at 'http://127.0.0.1:55259/?state=<state>' from origin
'https://modelstudio.console.alibabacloud.com' has been blocked by CORS policy:
Permission was denied for this request to access the `loopback` address space.

POST http://127.0.0.1:55259/?state=<state> net::ERR_FAILED
authorize failed: TypeError: Failed to fetch

Note that the console API calls on that page succeed — the account is authenticated and the token is minted. Only the hand-off to the CLI fails.

Root cause

Chrome enforces Private Network Access: when a public HTTPS page requests a loopback address, Chrome sends a CORS preflight carrying Access-Control-Request-Private-Network: true, and the local server must answer with Access-Control-Allow-Private-Network: true. Otherwise the request is blocked before it is sent.

The CLI's local callback server answers the preflight without that header:

$ curl -i -X OPTIONS "http://127.0.0.1:55259/" \
    -H "Origin: https://modelstudio.console.alibabacloud.com" \
    -H "Access-Control-Request-Method: POST" \
    -H "Access-Control-Request-Private-Network: true"

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, POST, PUT, PATCH, OPTIONS
Access-Control-Allow-Headers: Content-Type
Date: Fri, 04 Sep 2026 14:56:56 GMT
Connection: keep-alive
Keep-Alive: timeout=5

Access-Control-Allow-Private-Network is absent, so Chrome denies the loopback access and the POST never leaves the page. The server itself is healthy — a direct request from outside the browser reaches it and is answered (HTTP 400 for a bare GET /, as expected).

Suggested fix

Echo the header on the preflight response of the login callback server, only when the browser asks for it:

if (request.method === 'OPTIONS') {
  const headers = {
    'Access-Control-Allow-Origin': '*',
    'Access-Control-Allow-Methods': 'GET, POST, PUT, PATCH, OPTIONS',
    'Access-Control-Allow-Headers': 'Content-Type',
  };
  if (request.headers['access-control-request-private-network'] === 'true') {
    headers['Access-Control-Allow-Private-Network'] = 'true';
  }
  response.writeHead(204, headers);
  response.end();
  return;
}

This is backward compatible: browsers that do not send the request header are unaffected.

Two things worth considering alongside it:

• Fail loudly instead of hanging. Today the command waits forever with no output. A timeout that prints "the browser could not deliver the token" would turn a silent hang into a diagnosable error.
• Offer a manual fallback. Printing the callback URL, or accepting a pasted token, gives users a way through when the browser blocks the hand-off for any reason.

Workaround for other users

Until this is fixed, set a browser that does not enforce Private Network Access (Safari or Firefox) as the system default before running bl auth login --console, since the CLI opens the default browser.

Alternatively, capture the token in Chrome DevTools (the authorize request returns {"access_token": "...", "token_type": "Bearer", "expires_in": 86400}) and write it as access_token into the active profile of ~/.bailian/config.json.

Impact

Chrome is the default browser for a large share of users, and this blocks the only console-login path. On a Token Plan Personal account there is no alternative: bl auth login --open-api cannot substitute for it, because minting the CLI token via GenerateCLIAccessToken returns NoPermission for a personal account (verified with AliyunTokenPlanReadOnlyAccess, AliyunTokenPlanFullAccess and AliyunBSSReadOnlyAccess all attached). So for those users, every bl usage token-plan is unreachable on Chrome.

Comece pela implementação por trás de bl auth login --console e pelo servidor de callback local correspondente; em seguida, reproduza o preflight OPTIONS descrito na issue. Verifique o comportamento do Chrome, Brave, Arc, Safari e Firefox no acompanhamento antes de escolher uma correção. O trabalho estará concluído quando a transferência para o navegador for concluída de forma confiável ou falhar com uma mensagem diagnosticável e um fallback documentado.