Proof Portal

Sign in
Project overview

Omarchy

ProbeLabs65 findings · 95 requirements

A 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.

Inbox
ReportR-292GitHub issuePublicReceived

omarchy-windows-vm: launch/install fail silently after the VM has run once (~/Windows left setgid/777)

Reported by dawestheperson · filed Sep 20, 2026Closed upstream on 2026-10-04 by the bot omarchybot; the closing comment says it was fixed by PR #12323. GitHub close reason: completed.

Open at source
Received and recorded verbatim. Nothing has been checked yet.

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

omarchy-windows-vm: launch/install fail silently after the VM has run once (~/Windows left setgid/777)revision 1 · captured 2026-09-28 21:23 UTC via poll

Version: omarchy 4.0.4-1 (Arch, Hyprland)

What happens
After the Windows VM has run and been stopped, ~/Windows (the shared folder) ends up with mode 2777 (setgid, world-writable). From then on:

  • omarchy-windows-vm launch prints only ❌ Failed to start Windows VM! (or the app just says "failed to open VM").
  • omarchy-windows-vm install fails with ❌ Failed to write the Windows VM configuration.
  • omarchy-windows-vm remove fails with Windows VM removal stopped before user-side cleanup.

None of these print the real reason. Running pkexec /usr/bin/omarchy-windows-vm __priv write_compose directly exits 2 with no message.

Cause (as far as I can tell)
prepare_caller_mounts chmods the pinned sources to 0700 and then requires the mode to be exactly 700. On a directory chmod 0700 keeps the setgid bit, so the check sees 2700 and returns 1 without any message. The container also resets the folder to 2777 every time it runs, so this recurs after every stop.

Workaround

chmod g-s ~/Windows && chmod 700 ~/Windows

before each launch.

Suggested fix
- In prepare_caller_mounts, clear setgid explicitly (chmod 0700 followed by chmod g-s, or chmod u=rwx,go=,g-s), or compare only the permission bits you care about.
- Print an error on that return 1 path so failures aren't silent.

Repro
1. omarchy-windows-vm install, let Windows finish, then omarchy-windows-vm stop.
2. stat -c %a ~/Windows shows 2777.
3. omarchy-windows-vm launch fails with no explanation.

View raw text
**Version:** omarchy 4.0.4-1 (Arch, Hyprland)

**What happens**
After the Windows VM has run and been stopped, `~/Windows` (the shared folder) ends up with mode `2777` (setgid, world-writable). From then on:

- `omarchy-windows-vm launch` prints only `❌ Failed to start Windows VM!` (or the app just says "failed to open VM").
- `omarchy-windows-vm install` fails with `❌ Failed to write the Windows VM configuration.`
- `omarchy-windows-vm remove` fails with `Windows VM removal stopped before user-side cleanup`.

None of these print the real reason. Running `pkexec /usr/bin/omarchy-windows-vm __priv write_compose` directly exits 2 with no message.

**Cause (as far as I can tell)**
`prepare_caller_mounts` chmods the pinned sources to 0700 and then requires the mode to be exactly `700`. On a directory `chmod 0700` keeps the setgid bit, so the check sees `2700` and returns 1 without any message. The container also resets the folder to `2777` every time it runs, so this recurs after every stop.

**Workaround**
```
chmod g-s ~/Windows && chmod 700 ~/Windows
```
before each launch.

**Suggested fix**
- In `prepare_caller_mounts`, clear setgid explicitly (`chmod 0700` followed by `chmod g-s`, or `chmod u=rwx,go=,g-s`), or compare only the permission bits you care about.
- Print an error on that `return 1` path so failures aren't silent.

**Repro**
1. `omarchy-windows-vm install`, let Windows finish, then `omarchy-windows-vm stop`.
2. `stat -c %a ~/Windows` shows `2777`.
3. `omarchy-windows-vm launch` fails with no explanation.

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.