token auth on native Windows: the device-code request fails its TLS handshake (curl_code=35), so the browser never opens

Closed
  • Is something wrong?
#56 5 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
52/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
cpp
Domain
authentication, operating-systems

Research direction

Start with DeviceAuth::RunDeviceAuthFlow in src/modules/token-auth/src/token_auth.cpp, then run just test-winvm using docs/reference/windows-vm-system-test.md with no cached credentials. Inspect [NEVR.AUTH] lines and record the ShellExecuteA return value, then investigate the listed thread, COM, browser-handler, and elevation cases. Done means the cause is addressed and the VM log shows the expected state.

Written by the indexing model from the issue text.

Description

Reported by the owner on 2026-09-30: on Windows, with a completely vanilla build, the browser does not open automatically when the token auth (device-code) flow starts.

Held for investigation; nothing below the report has been measured for this issue yet.

Reported

  • Native Windows, vanilla build (no config files, no plugins).
  • The token auth flow starts but the browser is not opened.

What the code does (read, not run)

DeviceAuth::RunDeviceAuthFlow (src/modules/token-auth/src/token_auth.cpp:325):

  • On Windows the opener is ShellExecuteA(nullptr, "open", url, nullptr, nullptr, SW_SHOWNORMAL) (:331).
  • The call happens at :382, after DisplayLinkingCode. A result of 32 or less is a failure: showOpenFailure then shows a modal MessageBoxA with the URL and the device code (:383-385, :332-336). If that dialog returns 0 the flow stops (:388-392).
  • The flow runs synchronously on the bootstrap thread in client mode (#37).

Not established (to find out)

  • Whether the fallback message box appeared. If it did, ShellExecuteA returned 32 or less and the result code in the message says why. If it did not, ShellExecuteA returned above 32 (it reports success) yet nothing opened, which points at the caller's environment (for example a default-browser handler, or the call not running on a thread the shell can use) rather than at the failure path.
  • What [NEVR.AUTH] lines the boot log has for that run, and whether the device code was shown at all.
  • Whether it depends on how the game is launched (elevated, from a launcher, from a service-like context) and on the default browser.
  • Whether ShellExecuteA needs COM initialised on the calling thread here. Unverified; it is a documented ShellExecute caveat, not a finding.

Plan

  1. Reproduce on the win11-dev VM (just test-winvm, docs/reference/windows-vm-system-test.md) with no credentials cached, so the device-code flow starts, and read the [NEVR.AUTH] log lines.
  2. Record the ShellExecuteA return value in the log (today a success is silent), so a run says what it got.
  3. If the browser is reached but does not open, try opening the URL from another thread with COM initialised, and check the default-handler and elevation cases.
  4. Fix, then verify on the VM with the log showing the expected state.
Dominant language
C++
Stars
2
Forks
5
Avg merge
4h 51m
Merged PRs (30d)
937

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from EchoTools/nevr-runtime

All issues in EchoTools/nevr-runtime

Similar issues

More C++ issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.