"Error: 'utf-8' codec can't decode byte 0x80 in position 0: invalid start byte" when running any CCI command after connecting Github service

[camerongoodman]

Describe the bug

After connecting to github using cci service connect github , any CCI command ran returns "Error: 'utf-8' codec can't decode byte 0x80 in position 0: invalid start byte"

This is happening using an Ubuntu 20.04 image in WSL2 on Windows.

The cci service connect github in WSL2 console opens the default browser in Windows, performs the authorization and appears to be successful except for this message in the terminal.

Enter this one-time code: XXXX-XXXX Opening https://github.com/login/device in your default browser... tcgetpgrp failed: Not a tty Successfully authorized OAuth token (gho_L6h...) No service name specified. Using 'default' as the service name. Service github:default is now connected

The resulting ~/.cumulusci/services/github/default.service file is full of weird characters and appears corrupted.

Fix is to delete ~/.cumulusci/services/github/default.service and revert ~/.cumulusci/DEFAULT_SERVICES.json to previous version (remove github from it)

Reproduction steps

1. in WSL2 run cci service connect github
2. complete authorization process
3. attempt CCI command in WSL2, observe error "Error: 'utf-8' codec can't decode byte 0x80 in position 0: invalid start byte"

Your CumulusCI and Python versions

CumulusCI version: 3.57.0 Python version: 3.8.10

Operating System

Ubuntu 20.04 in WSL2 in Windows 11

Windows environment

WSL

CumulusCI installation method

pipx

Error Gist

No response

Additional information

No response

[jstvz]

Hi @camerongoodman. Unfortunately, SFDX is not officially supported on WSL, and we are aware that there are likely to be keyring-related issues in that environment. Our recommendation is to use the native Windows command prompt (cmd.exe) or PowerShell. Did this recently stop working?

[camerongoodman]

Hi @camerongoodman. Unfortunately, SFDX is not officially supported on WSL, and we are aware that there are likely to be keyring-related issues in that environment. Our recommendation is to use the native Windows command prompt (cmd.exe) or PowerShell. Did this recently stop working?

Understood however David asked me to write it up.

Also, cannot say if it recently stopped as this is the first time Ive tried this using WSL2