Skip to main content

Project Aria Login Troubleshooting

Login Failures​

"Invalid email address: ... Expected format <username>@tfbnw.net"​

Password login only accepts distributed accounts. You entered an email with @ but not ending in allowed domains.

Fix: Use bare username without domain, or full user@tfbnw.net, or user@*.wptst.com. For Work accounts, use full email — it will auto-detect MMA flow.

Code path: AuthenticationManager.get_email() in _internal/auth_manager.py.

"Login failed" with no details​

Run with verbose flag to see underlying exception:

projectaria_login -v login --username ...

Common causes in logs:

  • AuthenticationError: Getting public key failed — network issue reaching meta.graph.meta.com. Check VPN / proxy.
  • Login failed with response ... — wrong password, or account locked. Verify credentials in browser first.
  • Failed to initiate MMA device flow — cannot reach graph.work.meta.com. Ensure Work VPN or office network if required.

MMA flow times out​

CLI prints URL and code, then polls. If you don't complete browser SSO in time:

AuthenticationError: Device authorization timed out

Fix: Re-run login, complete browser flow within about 5 minutes (the device code expires then). Check that browser opens correct Work SSO page, not cached error page. Try incognito window.

Polling interval defaults to 5s; polling continues until you authorize or until the device code expires (about 5 minutes), after which polling stops and you must re-run login. These are not user-configurable via CLI; use Python API with custom loop if needed.

"Already logged in as ..." but token invalid in other tool​

Token validation is per-tool startup. If you changed password or admin revoked session server-side, each tool will detect on next API call and clear keyring.

Fix: Run projectaria_login logout then login again. This clears stale token everywhere.

Keyring Issues​

"Token could not be saved to keyring" warning​

Keyring backend not available or locked.

macOS: First use triggers Keychain permission popup — click Allow. If denied, open Keychain Access → right-click login keychain → Unlock, then retry.

Linux headless: Install and start gnome-keyring daemon:

sudo apt install gnome-keyring
eval $(gnome-keyring-daemon --start --components=secrets)
# test
python3 -c "import keyring; keyring.set_password('a','b','c'); print(keyring.get_password('a','b'))"

If still fails, check python3 -c "import keyring; print(keyring.get_keyring())" — should show SecretService, not fail or Null.

Windows: Should work out of box with Windows Credential Manager. If using WSL, WSL has no Windows credential passthrough by default — either run native Windows Python (to use Windows Credential Manager), or leave the keyring unavailable and set PROJECTARIA_TOKEN_KEY so the token is persisted to the encrypted-file fallback (see the "No keyring backend" section below). Do not install keyrings.alt's PlaintextKeyring, which stores the token unencrypted.

CI / Docker: The keyring is typically unavailable. Set PROJECTARIA_TOKEN_KEY (at least 12 characters) so the token is saved to and loaded from the encrypted file (~/.projectaria/auth_token.enc) with no prompt. Log in once interactively (or on a host with the same key), then reuse the encrypted file across runs. See Encrypted File Fallback Issues below.

"No keyring backend" in logs​

Python keyring package installed but no system backend found. Install the OS-specific backend package as above so the token is stored in the system keyring.

If no system keyring is available (headless servers, containers, CI/CD), do not install a plaintext keyring backend such as keyrings.alt's PlaintextKeyring. Doing so makes keyring report as "available" and writes the token in plaintext to ~/.local/share/python_keyring/keyring_pass.cfg, which also disables the safer automatic encrypted-file fallback. Instead, leave the system keyring unavailable and set PROJECTARIA_TOKEN_KEY (≥ 12 characters) so the token is persisted to the built-in encrypted-file fallback (AES-256-GCM):

export PROJECTARIA_TOKEN_KEY='your-strong-passphrase'  # at least 12 characters

Encrypted File Fallback Issues​

When no keyring backend is available, projectaria_login stores the token in an encrypted file at ~/.projectaria/auth_token.enc. See Token Storage → Encrypted File Fallback for the full model.

"Token could not be saved" even though the keyring is down​

No usable key material was found. The PROJECTARIA_TOKEN_KEY env var and any entered passphrase must be at least 12 characters; shorter values are rejected and the token is not saved.

Fix: Set a strong PROJECTARIA_TOKEN_KEY (≥ 12 chars) before logging in, or enter a passphrase of at least 12 characters at the prompt.

verify/logout keeps prompting for a passphrase​

The file was saved with an interactive passphrase (key_source: passphrase), so it must be re-entered to decrypt. If you would rather avoid prompts, log in again with PROJECTARIA_TOKEN_KEY set so the file uses the env-var key source.

"Failed to decrypt the encrypted token file" and it disappears​

This message means decryption was actually attempted and failed, so the file is removed to avoid failing on every subsequent run. It applies in two cases: the file uses an env-var key (key_source: env) and PROJECTARIA_TOKEN_KEY is wrong or the data was tampered with — the key is present, so decryption runs immediately on load — or the file is structurally unusable regardless of the key (a malformed blob, an unsupported format version or KDF, an out-of-range iteration count, or content that decrypts cleanly but is not a valid Aria token).

A wrong interactive passphrase is handled differently and does not remove the file: it is treated as recoverable (up to 3 attempts, and the file is kept even if you decline or exhaust them), so a single typo never deletes a still-valid token. A file that needs PROJECTARIA_TOKEN_KEY while the variable is unset is likewise kept, because decryption is never attempted.

Fix: Use the same key material as at login. For an env-var file, set the correct PROJECTARIA_TOKEN_KEY (and, if the file was already removed, run projectaria_login login --username ... again). For a passphrase-protected file, re-run and enter the full passphrase (a too-short passphrase at the decrypt prompt is re-prompted rather than attempted).

Logout says the server-side session was not invalidated​

Server-side logout needs a usable token. If the encrypted file cannot be decrypted (or no passphrase is provided), logout clears local state or keeps the file but skips the server call.

Fix: Re-run projectaria_login logout providing the correct passphrase (or with PROJECTARIA_TOKEN_KEY set). To force-remove the local file without a server-side logout, delete ~/.projectaria/auth_token.enc.

Network and Proxy​

All endpoints use HTTPS:

  • Password flow: meta.graph.meta.com, meta.graph.meta.com/graphql
  • MMA flow: graph.work.meta.com, api2.work.meta.com
  • Token validation: GraphQL endpoint via RequestHelper
  • Logout: graph.oculus.com/logout

If behind corporate proxy, set standard env vars — aiohttp respects HTTP_PROXY, HTTPS_PROXY, NO_PROXY.

Test connectivity:

curl -v 'https://meta.graph.meta.com/passwords_encryption?version=2' -H "Authorization: Bearer FRL|..."
# expect 401 or 400 without valid token, not timeout

Legacy Migration Issues​

Migration of the pre-2024 unencrypted ~/.projectaria/auth_token file is no longer supported. If such a file exists, it is neither read nor migrated.

Fix: Delete it manually and log in again: rm ~/.projectaria/auth_token && projectaria_login login --username ...

Getting Help​