Keep Extension ID Stable on Reimport

An unpacked browser extension can receive a different ID after it is moved, copied, or loaded as a separate package. That matters when a website, another extension, or an external integration expects one specific extension origin. In MaskPilot, replacing an existing local extension through Reimport is different from importing another local extension: reimport keeps the existing managed identity.

Why an unpacked extension ID can change

The browser derives an extension ID from its identity information. Chrome’s official key Manifest documentation explains that a fixed public key keeps the ID consistent when an extension is loaded during development.

Without a fixed identity, loading the same source from another location can create a different ID. A changed ID can affect:

• integrations that allow one chrome-extension:// origin;
• messages sent from approved websites or other extensions;
• access rules for extension resources;
• troubleshooting records that identify the extension by ID.

Do not treat matching names and versions as proof that two entries have the same identity. Compare the actual extension ID.

What MaskPilot preserves during reimport

On the first import, MaskPilot creates a managed copy of the reviewed folder or ZIP. If its Manifest already contains a valid identity key, the managed copy uses it. If the key is absent, MaskPilot creates an identity for that managed copy instead of relying on the source folder’s path.

When you choose Reimport from the existing local extension’s detail page, MaskPilot reuses that extension’s current identity before saving the replacement package. The source path and version may change, but the managed identity remains attached to the existing entry. Existing profile selections are also preserved.

MaskPilot does not add the generated identity to your original source folder. It belongs to the managed copy on the current device. Close every profile using the extension before reimporting so no running browser process still depends on the old package.

Know when the ID should stay the same

Action	Expected identity result
Reimport from the existing local extension’s detail page	Keeps the existing managed identity
Import a package that already contains a valid fixed key	Uses the package identity
Import a keyless package as a new local extension	Creates a new device-local identity
Delete a keyless local extension, then import it again	Creates a new identity because the earlier managed record is gone
Import the same keyless source on another device	Creates a separate identity because local extensions do not sync
Import the same trusted package with its fixed key on another device	Uses the fixed package identity

Use Reimport for a new build that should replace the current local extension. Use a separate import only when you intentionally want another independently managed extension.

Reimport without changing the ID

1. Finish work in every profile that uses the extension, then fully close those profiles.
2. Open Extensions and select the existing local extension.
3. Choose Reimport from its detail page.
4. Select the replacement root folder or ZIP package.
5. Review the name, version, minimum browser requirement, website access, browser capabilities, and any newly added access.
6. Confirm the replacement, then launch one disposable test profile that already selected the extension.
7. Open the browser’s extension management page and compare the ID with the value recorded before reimporting. Test any workflow that depends on the extension origin.

The permission and compatibility review still matters even though the identity stays the same. Follow the local extension permission checklist before expanding the replacement to production profiles.

If the ID appears different

Check these boundaries before editing a Manifest:

1. Confirm that you used Reimport on the existing detail page rather than the main import action.
2. Check whether the old entry was deleted first. A deleted keyless extension cannot recover its earlier device-local identity through a new import.
3. Compare the same browser profile and extension entry. Two packages can display the same name and version while having different IDs.
4. Fully close and relaunch the profile so you are not inspecting a process that loaded an earlier package.
5. Check for duplicate local-extension entries and keep only the one whose identity and profile assignments you intended to preserve.

Do not copy a key from an unrelated extension, edit MaskPilot’s managed package, or weaken Manifest validation to force an ID match. If the extension developer intentionally changed identity, keep the old and new packages separate while you validate the migration instead of disguising the new package as the old one.

If reimport does not reach the confirmation screen, use the local extension import error checklist. For the normal package and device boundaries, see import a local browser extension.

Plan for another device

Local packages, generated identities, and profile selections remain on the device where they were imported. If the same extension must have the same ID on several devices, use one trusted package that already contains the developer’s valid fixed key before importing it on each device. For an extension you develop, follow the official key documentation above instead of inventing or borrowing identity data.