[Bug] OAuth login fails silently with "fetch failed" — browser never opens for authorization

[anubhavsinghmaar]

Environment

Field	Value
Kane CLI version	0.2.11
OS	macOS 15.7.5 (Apple Silicon - M4 MacBook Pro)
Install method	Homebrew

Description

When attempting to log in via OAuth (browser), after selecting "OAuth (browser)" → "+ Create new profile" → entering a profile name, the CLI immediately shows a "Login failed — fetch failed" error. The browser never opens to complete OAuth authorization. No URL is shown, no redirect happens, no actionable error message is provided.

Steps to Reproduce

1. Run kane-cli login
2. Select "OAuth (browser)" as auth method
3. Select "+ Create new" profile
4. Enter a profile name (e.g. "anubhavs")
5. Press Enter to confirm

Expected Behavior

Kane CLI should open the system default browser to the TestMu AI consent page. After signing in and approving, tokens should be stored at ~/.testmuai/kaneai/profiles/<profile>/<env>/credentials and login confirmed.

Actual Behavior

CLI immediately shows:
"Login failed — fetch failed"
No browser opens. No URL or redirect is shown. No actionable error is provided.

Additional Context

• Chrome works fine from terminal: open -a "Google Chrome" https://google.com succeeds
• $BROWSER environment variable is not set
• Network: WiFi, no VPN
• An existing profile "asd" had an expired token (expired 2026-05-12), which prompted this re-login attempt
• Basic Auth was NOT tested as a workaround
• Command used: kane-cli login (interactive wizard, no --oauth flag)
• No active profile existed at time of reproduction

---

Update — Root cause (from NODE_DEBUG=undici trace)

The underlying Node error is UNABLE_TO_GET_ISSUER_CERT_LOCALLY on the call to POST https://auth.lambdatest.com/oauth2/register. The CLI surfaces it only as "fetch failed".

Reason: auth.lambdatest.com serves only the leaf certificate in the TLS handshake — the intermediate (Thawte TLS RSA CA G1) is not included, and the leaf has no AIA "CA Issuers" URL. curl and browsers work because they have the intermediate cached; Node's fetch (undici) requires the server to send the full chain and fails to validate.

Reproducible without kane-cli:

node -e "fetch('https://auth.lambdatest.com/').catch(e => console.log(e.cause?.code))"
// → UNABLE_TO_GET_ISSUER_CERT_LOCALLY

Workaround that confirms diagnosis: NODE_TLS_REJECT_UNAUTHORIZED=0 kane-cli login --oauth succeeds.

Suggested actions

1. Server: configure auth.lambdatest.com (and likely other LambdaTest endpoints on the same cert) to serve the full chain incl. the Thawte intermediate.
2. CLI: when fetch fails, surface error.cause.code and the target URL instead of the bare "fetch failed" — would have made this triagable in one step.

[anubhavsinghmaar]

adding screenshots for reference:

[shravan-lambdatest]

Looked into this — the OpenSSL error you traced (UNABLE_TO_GET_ISSUER_CERT_LOCALLY) is a Node trust-store gap. Node uses its bundled Mozilla CA list and doesn't read the macOS keychain by default, which is why curl and browsers work on the same machine. Common in environments where corporate endpoint security or a TLS-inspecting proxy is in the handshake path.

Quickest workaround — tell Node to also trust the system keychain via its built-in env var (Node 22.19+ / 24.6+):

export NODE_USE_SYSTEM_CA=1
kane-cli login

Docs: https://nodejs.org/api/cli.html#node_use_system_ca1. On macOS this reads the default and system keychains using the same trust policy your browser uses, so whatever root makes curl and your browser work will work for kane-cli too.

If you're in a corporate setup and on older Node, the equivalent is pointing NODE_EXTRA_CA_CERTS at a PEM file from your IT/security team:

export NODE_EXTRA_CA_CERTS=/path/to/corp-ca.pem
kane-cli login

Looking into auto system-CA pickup in kane-cli so this isn't needed by default. The clearer error message you suggested is going into the next release.

Thanks for the detailed undici trace.