**System details:** Omarchy `quattro` @ 7488eade (post-4.0.0), QEMU/KVM VM. Found by an automated QA pass; reproduced on a disposable worker VM.

Two commands in `bin/` are committed without the executable bit, which makes them invisible to the dispatcher and unreachable from the menu:

```
$ git ls-files -s bin/ | awk '$1 != "100755"'
100644 bin/omarchy-remove-service-dropbox
100644 bin/omarchy-remove-service-tailscale
```

Those are the only two of 424 `bin/omarchy-*` files that are not 755. The dispatcher discovers commands with `[[ -f $file && -x $file ]]` (`bin/omarchy:315`) and resolves routes with the same `-x` test (`bin/omarchy:400`), so both are absent from `omarchy commands --all` and exit 127:

```
$ omarchy remove service dropbox; echo "rc=$?"
Unknown Omarchy command: omarchy remove service dropbox
rc=127

$ bin/omarchy-remove-service-dropbox; echo "rc=$?"
bash: bin/omarchy-remove-service-dropbox: Permission denied
rc=126
```

The two menu entries that drive them — `default/omarchy/omarchy-menu.jsonc:297-298`, Remove → Services → Dropbox / Tailscale — run `omarchy-launch-floating-terminal-with-presentation omarchy-remove-service-dropbox`, so the user picks Remove → Dropbox and nothing happens.

This hits anyone whose `OMARCHY_PATH` is a checkout, i.e. everyone who has run `omarchy dev link`. On a released ISO the packaged copies are `-rwxr-xr-x`, so installed users are not affected today — but the repo is wrong and it is one packaging change away from shipping.

Worth fixing alongside: **`omarchy commands --check` cannot catch this.** Its "Missing binary" test at `bin/omarchy:719-722` iterates `COMMAND_KEYS`, which by construction only contains files that already passed the `-x` test — so the check is unreachable for exactly the failure it exists to find. It reports `Command metadata check passed (422 commands)` while two commands are dead. A check that walks `bin/omarchy-*` on disk and asserts each is executable would have caught it.

---

**Correction, after an independent review of this report:**

The consequence was wrong. The menu still works: actions run through `bash -lc` (`shell/Commons/Util.qml:54`), and bash skips a non-executable file during its `PATH` search, falling through to the executable packaged copy in `/usr/bin`. So a dev-linked menu selection runs the packaged -- possibly stale -- version rather than doing nothing. What stands is that the checkout copies are unroutable by the dispatcher and invisible to `commands --check`.