Add automatic startup with settings accessible inside Omarchy

[drdator]

Every launch currently requires clicking Launch Omarchy, even when the saved settings need no changes. This adds opt-in automatic startup and a way to reopen settings from inside Omarchy, so skipping the launcher doesn't hide configuration behind a keyboard shortcut.

• Open Setup → Try Omarchy Settings, search for Try Omarchy Settings, or run omarchy-native-settings. The guest channel only requests that the native settings window open.
• Edit CPU, memory, sharing, port forwarding, and immersive mode while running. Restart Try Omarchy… asks Linux to shut down cleanly, then starts a new QEMU process with the saved settings. Disposable VMs retain their disk across this restart.
• Shut down to manage… keeps the native window open for VM location and reset, even with automatic startup enabled. Reset retains its confirmation. Done returns to the running VM.
• Existing VMs receive the entry points through an idempotent installer on a separate read-only boot share. Existing user menu files are preserved; no manual installation or reset is needed.

Option remains a fallback for opening the launcher. Startup recovery and error dialogs still appear. The implementation includes upstream's current launcher styling and resource controls; settings and Touch ID use separate serial ports.

Validation:

• make test passed: 253 Swift tests, 109 guest tests, launcher/resource contracts, disk storage and resize checks, and the staged-QEMU crash-lock check.

• Refreshed only the three package-lock entries that the current repositories had moved: the ARM kernel, matching headers, and orc. Package signature and transaction-lock validation remain enabled.

• Clean ARM guest image, patched QEMU runtime, and signed macOS app builds passed, including filesystem and macOS 15 compatibility checks.

• An isolated AppKit integration harness with the fresh guest and real QEMU verified a normal guest user can open settings, save CPU/memory/sharing/ports/immersive changes, restart onto the same disk with those changes, and shut down to the management window with automatic startup enabled.

• The same fresh-VM check passed in disposable mode: disk state survived restart and the temporary workspace was removed on final shutdown.

The upstream CI run is waiting for a maintainer to approve the fork workflow; it has not run yet.

[themartiano]

Hey, thanks for the PR.

I think it's good to make it easier to launch the VM, but it should be easy for anyone to change the settings if they wish, and hiding the menu makes it a bit difficult IMO.
Maybe if we had a way to change the settings inside Omarchy? This way we can hide the menu and still change settings easily

[drdator]

Hey, thanks for the PR.

I think it's good to make it easier to launch the VM, but it should be easy for anyone to change the settings if they wish, and hiding the menu makes it a bit difficult IMO. Maybe if we had a way to change the settings inside Omarchy? This way we can hide the menu and still change settings easily

Thanks for taking a look! My main use case is launching straight into Omarchy once everything is configured. It’s opt-in and the checkbox explains that holding Option brings the menu back. Though I do agree that’s easy to forget. Accessing settings from inside Omarchy sounds useful. Would you want that in place before adding automatic startup, or would you be open to this as an opt-in feature in the meantime?

[drdator]

I've added settings access from inside Omarchy: Setup → Try Omarchy Settings, launcher search, or omarchy-native-settings. Existing VMs get this automatically on their next launch with the updated app, without a reset or manual installation.

You can change CPU, memory, sharing, ports, and immersive mode while running, then restart to apply them. Shut down to manage… keeps the settings window open for VM location/reset, even with automatic startup enabled. Option remains a fallback.

Also resolved the conflicts with current main. Local tests and clean guest/runtime/app builds passed, along with real-VM settings and restart checks in persistent and disposable modes.

The CI run still needs maintainer approval before GitHub will run it.