### System details

Intel i9-12900HK, Intel Iris Xe + NVIDIA RTX 3050 Ti Mobile, Omarchy 4.0.0.r1708.g144f4d1-1, Chromium 151.0.7922.137 (Arch)

### What's wrong?

Alt+Shift+L (Copy URL) does nothing — not in Chromium, not in any web app. Same symptom as #4745, which was closed without a diagnosis. I traced it to the root cause; it affects installs that migrated from the pre-package era (`~/.local/share/omarchy`).

**Root cause**

1. Pre-package installs loaded the copy-url extension unpacked from `~/.local/share/omarchy/default/chromium/extensions/copy-url`, and back then its `manifest.json` had no `key`. Chromium derives an unpacked extension's ID from a hash of its load path, so on my machine it got ID `ikkebdkaanlebnifjnbeiaklodhbjcci` (= first 16 bytes of sha256 of the absolute path, mapped to a–p; verifiable).
2. On first load, Chromium recorded the extension's suggested shortcut in the profile: `extensions.commands["linux:Alt+Shift+L"] → ikkebdk…` in `Default/Preferences`. That registration persists indefinitely.
3. Omarchy later moved to `/usr/share/omarchy` and pinned the extension with a manifest `key`, giving it the current ID `bgpiichlckmfanooecilcjemknkcpngb`.
4. Chromium's command service never assigns a suggested key that is already registered to another extension — even one that no longer exists. So the current extension silently never claims Alt+Shift+L, and the keypress dispatches to a ghost.

Everything else checks out on an affected system (native-messaging host manifests and host binary present, `--load-extension` correct in `chromium-flags.conf`), which makes this miserable to debug: clicking the extension's toolbar action copies the URL fine — only the keyboard shortcut is dead. Brave is affected identically via `brave-flags.conf` (same stale entry in its `Default/Preferences`).

Corroborating detail: yt-dlp's Alt+Shift+D worked here because its current key-derived ID (`dedjgkn…`) holds that registration — only copy-url on this machine predates the path move.

**Reproduction (simulates the migration history)**

1. Load an extension with a suggested command key via `--load-extension` from path A, manifest without `key`. Launch once so Chromium registers the shortcut. Quit.
2. Add the manifest `key` (or move to path B) so the extension ID changes.
3. Relaunch. `extensions.commands` in `Default/Preferences` still maps the accelerator to the old ID; the new ID never gets it; the shortcut does nothing.

**Fix verified locally**

With the browser closed, delete the stale `extensions.commands["linux:Alt+Shift+L"]` entry (and the orphaned `extensions.settings["ikkebdk…"]` entry) from `Default/Preferences` in both Chromium and Brave profiles. On the next launch the current extension re-registers Alt+Shift+L by itself and the shortcut works again.

**Suggested resolution**

- A migration that removes stale `extensions.commands` entries whose extension ID is the path-derived hash of `$HOME/.local/share/omarchy/default/chromium/extensions/<name>` (deterministic per user, computable in the migration) for chromium/brave/chrome/edge profile dirs. Needs the browser-not-running case handled, since Chromium rewrites Preferences on exit.
- Same cleanup applies in principle to yt-dlp (`Alt+Shift+D`) for users whose stale registration predates its `key`.
- `whatsapp-slim` still ships without a manifest `key`, so its ID is still path-derived — pinning it now would prevent this bug class recurring if its path or packaging ever changes.