Store recovery codes where you can actually find them

Give the codes an address before you need them

A recovery-code download is easy to forget: one text file among receipts, installers and old attachments. When your phone disappears, remembering that you saved it is less useful than knowing which account it belongs to, where the current copy lives and how to reach it.

This guide uses a personal GitHub.com account in a desktop browser, with two-factor authentication already enabled. It covers the code file and its storage routine; managed workplace accounts and self-hosted GitHub installations may have different requirements. You can complete the storage check without signing out or spending a code.

GitHub recovery codes are single-use alternatives when your usual second factor is unavailable. Keep them private. Their purpose is to preserve access, so a copy that requires the missing phone to unlock is a poor emergency copy.

The practical target is modest: one protected everyday location, one independently reachable fallback if needed, and a non-secret reminder that tells you where to look. More copies mean more places to maintain and protect.

Save the current set, without replacing it accidentally

Use your own trusted computer. Open GitHub directly and check that you are signed into the intended username, especially if you have separate personal and work identities. Keep that working session available throughout.

1. Open your profile picture, choose Settings, then select Password and authentication in the sidebar’s Access section.
2. Beside Recovery codes, click View. Viewing the existing set is different from generating a replacement.

   ↗ Open full size

3. Choose Download, Print or Copy, according to your storage destination. GitHub documents all three options in its recovery-method instructions.

Downloading leaves a file that still needs a protected home. Copying leaves sensitive clipboard contents. Printing creates a physical secret. Choose the destination before taking the action, and avoid shared printers or computers for this task.

For an existing set, leave Generate new recovery codes alone. Generating a replacement invalidates earlier codes; it is not a refresh of the display. If an expected control is missing, consult the official instructions rather than changing security settings to make the example appear.

Choose storage you can open with the phone unavailable

A password-manager entry for everyday retrieval

GitHub recommends secure password-manager storage. Save the codes in a protected field or secure note, with a searchable title such as “GitHub recovery codes — personal username.” Check the complete text after saving; do not assume a successful paste preserved every line.

Now consider the manager itself. If its only sign-in approval comes from the phone you are preparing to lose, storing GitHub’s codes there does not solve that particular emergency. Work out the manager’s independent recovery route or choose a protected paper fallback for GitHub. A vault already unlocked on another device helps today, but does not establish that a replacement device can open it.

A paper copy for an independent route

Store a legible copy with important documents in a locked place you can reach. An envelope can keep the contents out of casual view; it does not provide the access control of a locked container. Keep it away from the laptop bag or phone case whose loss you are planning for.

Consider the keys too. A container whose only key is in that same bag defeats the arrangement. If you need protection against losing access to your home, a second protected location may help, but only if you can retrieve it and maintain its contents.

An emailed copy, chat attachment or ordinary cloud note creates another place where the secret can be exposed. Check what account is needed to open it and who can access it. Avoid sending codes through several services just to make them searchable.

Label the set, and keep a separate location reminder

Put enough context beside the protected codes to distinguish accounts and replacement sets. Include the service address, username, the date you saved or replaced the set, and any used-code markings. A saved date is your housekeeping record, not proof of when GitHub originally generated those codes.

For example, a hypothetical protected record might read: “GitHub.com / sample-nora / personal account / saved 31 October 2026 / used codes crossed out.” This example contains no usable credential. Avoid titles such as “backup final new,” which become ambiguous after the next replacement.

Keep a separate reminder containing only the location: “GitHub recovery record: password manager entry; paper fallback in document box.” Put it somewhere you can find without opening GitHub. Do not include codes, the vault password or the container combination in that ordinary reminder.

If you downloaded a temporary file, verify the protected copy before removing the loose download. Check for duplicate downloads and clipboard-history entries where applicable. Removing a file from Downloads does not revoke its contents or guarantee erasure from synced folders, backups or other devices.

Rehearse finding the record

Leave your phone aside without signing out of anything. Start from your location reminder, retrieve the protected record and check that it names the correct account. Can you read the entire set? Can you reach the physical copy and open its container? Correct an inaccessible location or incomplete copy while your working session remains available.

This is a retrieval check. It does not prove that GitHub will accept a particular code. Compare the saved text with the authenticated code display privately if necessary; never paste codes into a search engine, support chat or screenshot for someone else to inspect.

If you deliberately choose an actual sign-in check, keep the original session open and use a separate browser profile on your own computer. GitHub’s recovery instructions specify signing in, then choosing More options → 2FA recovery code, entering one code and selecting Verify. This spends the code. Mark it used on every maintained copy after success.

A recovery code does not simply replace a forgotten password at the ordinary password field. GitHub documents a separate password-reset route that can use recovery codes. Preserve access to the associated email account as well.

Replace obsolete copies as one maintenance job

If you suspect exposure, use your surviving authenticated access to generate a replacement set, save it immediately, and update each maintained location. Earlier codes stop working when the new set is generated. There is no overlap period to rely on and no undo that makes the old paper valid again.

A hypothetical two-copy arrangement needs two updates: the vault entry and the paper record. Updating only the vault leaves a convincing but unusable fallback. Destroy superseded paper, remove obsolete digital working copies where practical, and revise the date on the current record. If the old secret may have escaped, replacement is what invalidates it.

If GitHub reports Recovery code authentication failed, check the account and set first. Its troubleshooting guidance says to enter one code at a time and try another unused code. Each has two groups of five alphanumeric characters separated by a hyphen. A set replaced later, including after disabling and re-enabling 2FA, is obsolete. Search for github-recovery-codes.txt if you are locating the original download.

If every recovery route is gone, GitHub warns that support cannot restore access. Do the quiet maintenance now: confirm the location, label the current set and replace every obsolete copy together.