Bug report: Device code login crashes when autoOpenLinksInBrowser is enabled

[eschoeller]

Description

m365 login --authType deviceCode crashes with TypeError: Expected a 'target' when autoOpenLinksInBrowser is true, because MSAL's DeviceCodeResponse.verificationUri can be undefined at runtime. Similarly crashes with copyDeviceCodeToClipboard enabled when response.userCode is undefined.

Steps to reproduce

m365 cli config set --key autoOpenLinksInBrowser --value true
m365 login --authType deviceCode

Expected results

Device code login proceeds, optionally opening browser if URI is available.

Actual results

TypeError: Expected a `target`
    at open (node_modules/open/index.js:315:9)
    at Auth.processDeviceCodeCallback

Proposed solution

Guard browserUtil.open() and clipboardy.writeSync() calls with null checks on response.verificationUri and response.userCode.

[Adam-it]

@eschoeller sorry to hear you are having trouble using CLI for M365.
TBH in the latest version I tired to reproduce the bug using the steps you provided and it seems all works fine

@pnp/cli-for-microsoft-365-maintainers can someone else do a recheck of this as well?

[milanholemans]

Tried it, browser pops open just fine, and was able to log in.

[milanholemans]

@eschoeller could you clarify a bit how we can reproduce this issue or troubleshoot on your end what goes wrong?

[eschoeller]

Thanks for looking into this. I was (sort of) able to reproduce this. Perhaps there have been some upstream changes between now and when I attempted this before. The important context, which I likely failed to mention, is that I was attempting this through a remote session from a Mac laptop to an Ubuntu workstation.

Environment:

• m365 v11.6.0
• Node v20.19.4
• Ubuntu Linux (Wayland session), connecting via SSH

Reproduction — SSH without X forwarding:

m365 login --authType deviceCode with copyDeviceCodeToClipboard: true crashes because clipboardy calls xsel which requires a display. Full stack trace:

Error: Couldn't find the `xsel` binary and fallback didn't work.
    at makeError (clipboardy/lib/linux.js:35:16)
    ...
    at Auth.processDeviceCodeCallback (Auth.js:375:30)
fallbackError: Can't open display: (null)

Reproduction — SSH with X11 forwarding (ssh -X):

No crash, but xdg-open opens the browser on the remote workstation via D-Bus/xdg-desktop-portal, not on the local laptop. I think this may defeat the purpose of device code auth — isn't it designed for environments where a local browser may not be available?

Suggested fix:

Both autoOpenLinksInBrowser and copyDeviceCodeToClipboard should gracefully degrade when the operations fail, since device code auth is specifically designed for environments where a local browser or clipboard may not be available. Wrapping the browserUtil.open() and clipboardy.writeSync() calls in try/catch would prevent the crash while still printing the device code for the user to copy manually.