Determine Whether a New Request Is Actually Expected
If Nano X keeps asking to pair in Ledger Live, distinguish a legitimate new association from a connection loop or an unsolicited request. The current app name is Ledger Wallet. A successful retained pairing does not normally require repeating its original code comparison until the relationship is forgotten or rebuilt as applicable.
Do not accept every request to make notifications stop. Confirm only the matching exchange you deliberately initiated, and cancel any mismatch or request whose source you cannot identify.
Check Whether the Previous Attempt Finished
Review both screens and identify the last accepted step. A phone confirmation without the required hardware completion is not the same result as a completed app session. If you repeatedly leave the flow midway, another request may represent unfinished setup rather than an independent device fault.
Ledger’s pairing troubleshooting shows discovery, code comparison, and final device interaction as separate stages. Use Nano X button controls for the intended prompts; do not apply a touchscreen gesture or hold both buttons when a short confirmation is requested.
After one successful exchange, test a device-dependent action. A remembered entry in phone settings can exist while the app still fails to communicate, and cached balances do not settle that question.
Remove Competing Attempts
Close another phone session or wallet app that might be trying to connect to the same Nano X. Start only one app-led pairing flow near the hardware. Do not open both general phone pairing and the app scanner and then mix their prompts without knowing which exchange each belongs to.
If requests appear while you are not attempting a connection, reject them. A nearby familiar-looking name does not establish the intended peer. Keep the Ledger locked or disconnected when you are not carrying out the task, using its normal controls rather than weakening phone protection.
Check for Inconsistent Saved Records
Forgetting the relationship on one side while leaving other records can produce repeated attempts that never establish a stable session. Use the official coordinated cleanup if ordinary readiness and permission checks do not resolve the loop.
On Nano X, read the Reset pairings command under the Control Center’s Settings and Security area. Ledger’s physical-menu reference distinguishes that command from Reset device. Keep the wallet initialized and do not intentionally erase it to suppress a Bluetooth notification.
Remove stale app and phone entries as instructed, then make one fresh attempt. Compare all code digits, complete both sides, and observe whether the next intended app use reconnects normally instead of creating another new exchange.
Interpret a Continued Loop
Record when the new request appears: after every lock, after app relaunch, only on one phone, or immediately before final confirmation. Those timings can narrow the problem toward lifecycle, permission, or stored-state behavior without claiming a cause prematurely.
Check current compatible app software through official distribution and note recent OS maintenance. If firmware is still progressing, preserve its host and connection before any restart or pairing experiment. Do not clear app data during the device update.
Record whether the repeated request occurs before selection, after code approval, or only after reopening the app.
Repeated-Request Questions
Could Accepting a Different Code Eventually Stabilize It?
No. Cancel mismatched exchanges. Accepting an unexplained peer does not repair a loop and can connect the wrong devices.
Will Resetting Pairings Change Account Ownership?
It changes connection state, not the wallet’s underlying keys. Rebuild supported account visibility only if that separate local information is missing.
Should I Share a Phrase to Authorize a Permanent Pairing?
No. Backup words never belong in phone or support forms for Bluetooth authorization. Keep secrets offline and use hardware confirmations for the intended exchange.