Just to be clear, the Linux environment used is an emulated environment
I acknowledge that emulated Virtual Machine is not currently a supported environment; therefore, this can be regarded as an experiment or feature request post rather than a bug report
Description
When running the Docker container in a headless ARM64 Linux environment (specifically Linux CLI without GPU hardware acceleration), the script gets stuck during the OAuth sign-in flow at login.live.com/oauth20_authorize.srf. It continuously outputs
[WARN] MOBILE [LOGIN] Unknown state at login.live.com/oauth20_authorize.srf], waiting
until it hits
Fatal error: Login timeout: exceeded maximum iterations.
The exact same container configuration runs successfully on standard Windows/Linux desktop hardware.
To Reproduce
- Set up a headless ARM64 Linux environment without a GUI or hardware GPU drivers.
- Run the script via Docker Compose with valid credentials in .env (without pre-existing sessions/).
- View logs (docker compose logs -f).
Specifically in my case, I used UTM on an iPhone 14 Pro Max. The emulated environment was an ARM64 Linux using QEMU 10.0 ARM Virtual Machine on UTM's emulate mode and ran Debian 13 as the operating system. The installation and setup process was trivial (install git, docker. docker-compose then follow the usual setup using docker).
Expected behavior
The script detects login form elements, processes credentials/TOTP, saves browser session files, and proceeds to daily searches.
Actual behavior
Playwright loops on the OAuth URL, unable to find the standard login inputs, and eventually times out:
Diagnosis
-
Potential cause: Microsoft's OAuth endpoint serves anti-bot verification or alternative JS frames when it detects headless Chromium environments running software low-tier CPU rendering instead of native x86/GPU hardware.
-
Impact: Playwright cannot locate standard form selectors because Microsoft presents a security challenge page that cannot be completed in headless mode.
Resolving the problem can pave the way for the use of VM to run the script on iOS devices and potentially android devices. Of course, executing the script on a computer or a proper virtual machine with proxies will work. However, people can't always have a computer ready to use or proxies/virtual machine (they're often paid, investing money might not be fruitful in case of account suspension). Moreover, having more devices to utilize allows people to earn using more accounts and on different IPs (they can execute the script somewhere else with a different IP).
Alternatively, suggesting other methods for executing the script on iOS (and android devices) is also good. I'm just experimenting with running the script on smartphones without any fees (everything is free of charge).
Just to be clear, the Linux environment used is an emulated environment
I acknowledge that emulated Virtual Machine is not currently a supported environment; therefore, this can be regarded as an experiment or feature request post rather than a bug report
Description
When running the Docker container in a headless ARM64 Linux environment (specifically Linux CLI without GPU hardware acceleration), the script gets stuck during the OAuth sign-in flow at login.live.com/oauth20_authorize.srf. It continuously outputs
[WARN] MOBILE [LOGIN] Unknown state at login.live.com/oauth20_authorize.srf], waitinguntil it hits
Fatal error: Login timeout: exceeded maximum iterations.The exact same container configuration runs successfully on standard Windows/Linux desktop hardware.
To Reproduce
Specifically in my case, I used UTM on an iPhone 14 Pro Max. The emulated environment was an ARM64 Linux using QEMU 10.0 ARM Virtual Machine on UTM's emulate mode and ran Debian 13 as the operating system. The installation and setup process was trivial (install git, docker. docker-compose then follow the usual setup using docker).
Expected behavior
The script detects login form elements, processes credentials/TOTP, saves browser session files, and proceeds to daily searches.
Actual behavior
Playwright loops on the OAuth URL, unable to find the standard login inputs, and eventually times out:
Diagnosis
Potential cause: Microsoft's OAuth endpoint serves anti-bot verification or alternative JS frames when it detects headless Chromium environments running software low-tier CPU rendering instead of native x86/GPU hardware.
Impact: Playwright cannot locate standard form selectors because Microsoft presents a security challenge page that cannot be completed in headless mode.
Resolving the problem can pave the way for the use of VM to run the script on iOS devices and potentially android devices. Of course, executing the script on a computer or a proper virtual machine with proxies will work. However, people can't always have a computer ready to use or proxies/virtual machine (they're often paid, investing money might not be fruitful in case of account suspension). Moreover, having more devices to utilize allows people to earn using more accounts and on different IPs (they can execute the script somewhere else with a different IP).
Alternatively, suggesting other methods for executing the script on iOS (and android devices) is also good. I'm just experimenting with running the script on smartphones without any fees (everything is free of charge).