wallet login --no-browser times out after the browser shows "Request approved"

[imajus]

Summary

tempo wallet login --no-browser never completes, even though the browser authorization succeeds. The wallet UI shows "Request approved — You can return to Tempo CLI", but the CLI keeps waiting and exits after ~4–5 minutes with a timeout. tempo wallet whoami stays ready: false and no ~/.tempo/wallet/keys.toml is written.

Reproduced 5 times in a row (mainnet, default network). On the last attempts the login process was confirmed alive for the whole window, and approval was given well within the timeout (about 1 minute after the code was printed).

Environment

• tempo 1.14.0 (installed via curl -fsSL https://tempo.xyz/install | bash)
• tempo wallet / tempo request extensions 0.11.0 (accounts 0.17.3)
• Linux x86_64, Debian 13 (glibc 2.41), headless container, no browser on the host
• Outbound HTTPS goes through a forward proxy set via HTTPS_PROXY (Node prints EnvHttpProxyAgent is experimental). Other HTTPS calls from the same host, including POST https://wallet.tempo.xyz/api/auth/device/token, reach the server fine.
• The person approving is on a different device (phone/desktop browser), hence --no-browser

Steps to reproduce

1. On a headless host:

   tempo wallet login --no-browser

2. The CLI prints:

   Device confirmation code: XXXX-XXXX
   Continue at: https://wallet.tempo.xyz/api/auth/device/verify?user_code=XXXXXXXX
   

3. On another device, open the URL, confirm the code matches, and approve. The page shows "Request approved — You can return to Tempo CLI".
4. Wait on the CLI.

Actual behavior

No further output after approval. No second code or second authorization prompt appears. After ~4–5 minutes:

code: UNKNOWN
message: "Timed out waiting for device code XXXXXXXX. Continue at https://wallet.tempo.xyz/api/auth/device/verify?user_code=XXXXXXXX."

tempo wallet whoami afterwards:

ready: false
wallet: null
key: null

RUST_LOG=debug adds no extra output.

Expected behavior

After approval in the browser, the CLI's device-code polling receives the token, provisions the access key, writes keys.toml, and whoami reports ready: true.

Notes

• The polling timeout appears to be the 5-minute default in accounts' device-code adapter, so the CLI gives up on its own. Holding the agent's command open longer (as SKILL.md suggests, 16+ minutes) doesn't change the outcome.
• SKILL.md mentions "a second authorization round may be required before the host is ready". No second code or prompt was ever printed here.
• Possibly related to Wallet login on testnet issue #106 (browser approval completes but the CLI isn't ready), though in our case mainnet itself never becomes ready.
• A verbose/debug mode that logs the device /token poll responses would help narrow down whether the approval isn't reaching the poll or the poll response isn't being handled. Happy to re-run with one if there is a flag we missed.