Proof Portal
Omarchy
ProbeLabs65 findings · 95 requirementsA proof layer — requirements, tests and verified fixes — for two of Omarchy's subsystems: the application menu (launcher scripts, QML model, JSONC config, search and selection) and the lock screen (lock scripts, QML, PAM authentication). Scope is deliberately limited to those components of omacom/omarchy; the rest of the distribution is not covered.
install/user/xcompose.sh overwrites ~/.XCompose and blanks the identity macros on rerun
Reported by omarchybot · filed Aug 16, 2026Closed upstream on 2026-10-04 by its own reporter omarchybot, as not planned. Closed by its own reporter — not by itself evidence of a fix.
At a glance
- 1 · What is claimed?
- Only the report text below — no validator has restated it as checkable claims yet.
- 2 · What does it affect?
- Not yet mapped to any requirement or component.
- 3 · Is it reproducible?
- No validation has been run yet.
- 4 · What remains unclear?
- Not validated yet: no claims, no reproducer.
- 5 · What happens next?
- Our staff decide whether the report is valid. Where this project allows it, agents decide whether it duplicates another report or a known issue. No decision has been recorded yet.
Original report
System details: Omarchy quattro @ 7488eade (post-4.0.0), QEMU/KVM VM. Found by an automated QA pass; reproduced on a disposable worker VM.
install/user/xcompose.sh overwrites ~/.XCompose unconditionally and, on any rerun after install, blanks both identity macros.
The script writes the file with a bare tee and no existence guard, interpolating two variables it does not check:
tee ~/.XCompose >/dev/null <<COMPOSE
...
<Multi_key> <space> <n> : "$OMARCHY_USER_NAME"
<Multi_key> <space> <e> : "$OMARCHY_USER_EMAIL"
COMPOSE~/.XCompose is a file the manual explicitly tells users to edit — manual/07-hotkeys.md:373 ("You can add more of your own by editing ~/.XCompose") and manual/31-dotfiles.md:19. And OMARCHY_USER_NAME / OMARCHY_USER_EMAIL only exist inside the ISO chroot and inside omarchy-provision-owner; at runtime they are unset, so a rerun writes empty strings into both macros.
The rerun is not hypothetical: bin/omarchy-provision-owner:1079 prints Run 'omarchy-provision-user --force' after login to retry. whenever user finalization reported errors, and that path re-sources install/user/all.sh via bin/omarchy-provision-user:108. A user following the installer's own recovery instruction loses their compose customizations and ends up with Compose space n / Compose space e typing nothing.
$ # first run with identity set, then the user appends their own macro,
$ # then the runtime rerun the installer told them to do
$ cat ~/.XCompose
# Run omarchy-restart-xcompose to apply changes
# Include fast emoji access
include "/usr/share/omarchy/default/xcompose"
# Identification
<Multi_key> <space> <n> : ""
<Multi_key> <space> <e> : ""The user's added <Multi_key> <space> <x> line is gone and both identity macros are now empty strings.
The sibling script install/user/git.sh:2,6 guards on exactly these two variables being non-empty, which is what makes this look like an oversight rather than a decision. install/user/mise-work.sh:5 has the same unconditional-overwrite shape for ~/Work/.mise.toml, with lower stakes.
View raw text
**System details:** Omarchy `quattro` @ 7488eade (post-4.0.0), QEMU/KVM VM. Found by an automated QA pass; reproduced on a disposable worker VM.
`install/user/xcompose.sh` overwrites `~/.XCompose` unconditionally and, on any rerun after install, blanks both identity macros.
The script writes the file with a bare `tee` and no existence guard, interpolating two variables it does not check:
```bash
tee ~/.XCompose >/dev/null <<COMPOSE
...
<Multi_key> <space> <n> : "$OMARCHY_USER_NAME"
<Multi_key> <space> <e> : "$OMARCHY_USER_EMAIL"
COMPOSE
```
`~/.XCompose` is a file the manual explicitly tells users to edit — `manual/07-hotkeys.md:373` ("You can add more of your own by editing `~/.XCompose`") and `manual/31-dotfiles.md:19`. And `OMARCHY_USER_NAME` / `OMARCHY_USER_EMAIL` only exist inside the ISO chroot and inside `omarchy-provision-owner`; at runtime they are unset, so a rerun writes empty strings into both macros.
The rerun is not hypothetical: `bin/omarchy-provision-owner:1079` prints `Run 'omarchy-provision-user --force' after login to retry.` whenever user finalization reported errors, and that path re-sources `install/user/all.sh` via `bin/omarchy-provision-user:108`. A user following the installer's own recovery instruction loses their compose customizations and ends up with `Compose space n` / `Compose space e` typing nothing.
```
$ # first run with identity set, then the user appends their own macro,
$ # then the runtime rerun the installer told them to do
$ cat ~/.XCompose
# Run omarchy-restart-xcompose to apply changes
# Include fast emoji access
include "/usr/share/omarchy/default/xcompose"
# Identification
<Multi_key> <space> <n> : ""
<Multi_key> <space> <e> : ""
```
The user's added `<Multi_key> <space> <x>` line is gone and both identity macros are now empty strings.
The sibling script `install/user/git.sh:2,6` guards on exactly these two variables being non-empty, which is what makes this look like an oversight rather than a decision. `install/user/mise-work.sh:5` has the same unconditional-overwrite shape for `~/Work/.mise.toml`, with lower stakes.
Validation
Not checked yet. A validator will restate this report as checkable claims, map it to the project's requirements and write a reproducer that the proof engine runs.
Linked
Not linked to any known issue, other report or change yet.
Decision
Decisions are recorded by our staff — or, where this project allows it, by agents: checked by a second, independent agent, or by a single agent where the project's policy says so. Any decision reached so far is shown below.
No decision has been recorded yet.