Lock, screensaver and stay awake: control the right kind of inactivity

During a presentation, you want the screen to remain available. During a long build, you want the computation to continue but would still like the desk to lock when you leave. These are different goals. An “awake” indicator does not prove the computer will never suspend, and a dark screen does not prove the session is locked.

This guide follows the pinned 4.0.0.alpha source. Here Omarchy Shell owns idle screensaver and lock timers; older hypridle.conf recipes do not automatically apply. Confirm your installed version and command help. Sleep and lid behaviour also depend on the hardware and system policy.

1. Separate appearance, access and power

no input → Shell idle monitor → screensaver and/or lock deadlines
manual lock → Shell session lock → authentication required
sleep request → logind PrepareForSleep → Omarchy sleep-lock service
lid event → logind policy + Omarchy clamshell/display reconciliation

State/action	What it means	What it does not guarantee
Screensaver	Decorative windows covering the desktop	Authentication before dismissal
Session lock	Access gated by the lock screen	The computer is asleep
Display off / DPMS	Output is blank or powered down	The desktop is securely locked
Suspend	Computation is paused while sleeping	A particular dock/device will resume correctly
Stay awake toggle	Suppress Shell idle lock/screensaver	Block every sleep or lid action
Hide Suspend in menu	Remove that menu choice	Disable kernel sleep or logind policy

The pinned omarchy-toggle-suspend only changes menu availability. Do not use it as a long-job sleep inhibitor. Suspend menu switch

2. Inspect intent and the live service separately

Before a temporary change:

omarchy-toggle-idle status
omarchy-shell idle status
systemctl --user status omarchy-sleep-lock.service --no-pager

The first command reads the saved stay-awake flag: enabled: true means stay awake is selected, not “idle locking enabled.” The second reports the running idle service: its enabled describes idle handling and its stayAwake describes the opposite mode. The names refer to different things.

saved toggle: enabled=true
running idle service: stayAwake=true, enabled=false

That is a consistent example, not a contradiction. If saved and running states disagree, inspect whether the Shell service loaded the file; do not keep pressing a toggle and lose track of intent. The flag persists, so a setting intended for a presentation can still be active later. Toggle source · Idle service

3. Case: keep a presentation available temporarily

Record the original state, keep the lid open and use the explicit operation:

omarchy-toggle-idle stay-awake

The printed disabled means idle behaviour is disabled. Check the coffee-cup indicator and the running status instead of interpreting that word as a failed request. The default Super + Ctrl + I toggles the same mode, but explicit commands are easier to reason about when writing a routine.

Test while present: leave the presentation without typing for longer than the configured idle deadlines and confirm it remains available. Applications can also supply idle inhibitors, so a successful video test alone does not verify the saved toggle; inspect status too.

Afterwards restore the recorded state. If normal idle handling was originally allowed:

omarchy-toggle-idle allow-idle

Move the mouse or type once to start a fresh activity cycle before testing. Do not leave an unlocked desk merely because the slide deck is finished. A manual lock remains a separate action:

omarchy-system-lock

Know your authentication method before this test. In this snapshot the lock routine also returns keyboard input to the first configured layout and attempts to lock a running 1Password app. A password typed under a different keyboard layout can therefore behave differently than expected. Lock routine

4. Case: preserve a long task while allowing the desk to lock

Idle locking usually does not stop a local build. Suspend does. First determine whether the problem is a screen transition, an actual sleep, or a task attached to a terminal that was closed.

If you need a temporary sleep inhibitor for a foreground task, systemd-inhibit can hold one for the lifetime of that command. Test its lifecycle with a harmless one-minute process:

systemd-inhibit --what=sleep --mode=block \
  --who='Task demo' --why='Keep this foreground task running' \
  sleep 60

In another terminal, inspect systemd-inhibit --list. Find the demo’s sleep/block entry; after the minute it should disappear. It is scoped to the running command, rather than a permanent global change. Then, if appropriate, replace sleep 60 with the exact verified foreground task and its arguments. If a wrapper immediately backgrounds the real job and exits, its inhibitor ends too. systemd inhibitor reference

This sleep-only inhibitor does not request disabling Omarchy’s idle lock. Leave normal idle allowed if you want the desktop to lock while the job runs. Test policy and permissions on your machine; privileged operations can override inhibitors, and a physical lid policy is not universally covered by the same sleep block. Do not claim this command guarantees an unattended closed-lid laptop stays awake.

Do not add handle-lid-switch or shutdown inhibition just because more options exist. Keep the laptop open in a ventilated working position for the supervised test. For task survival after closing the terminal or logging out, use an appropriate task/session manager; awake state alone does not preserve the shell process. See startup ownership for lifetime differences.

5. Change the everyday idle timing without replacing the Shell config

The personal ~/.config/omarchy/shell.json contains other settings too. Back up the existing file under a fresh name, then edit its existing top-level idle object through the config menu. The following is a fragment to merge, not a replacement file:

"idle": {
  "screensaver": 120,
  "lock": 300
}

Keep one idle object, valid JSON and the surrounding commas. Both values are seconds since activity stopped:

last input       screensaver                  lock
0 s ------------ 120 s ---------------------- 300 s
                 not another 300-second countdown

At this source, 0 disables the corresponding timed action; it does not fire immediately. To skip the decorative stage but retain a five-minute lock, use screensaver: 0 with lock: 300, or use the screensaver availability switch. Disabling screensaver does not itself disable lock. The manual screensaver launch can still intentionally run it even when the idle screensaver is disabled. Timer model

After saving, check JSON syntax if jq is available:

jq empty ~/.config/omarchy/shell.json
omarchy-shell idle status

Syntax success does not validate every setting. Confirm the running screensaver and lock values. The Shell reads timing changes, but an already-running idle cycle keeps its own deadlines; provide input and test a fresh cycle rather than expecting a mid-countdown edit to restart it. Dismissing the screensaver before lock counts as activity and cancels that pending cycle. Idle deadline implementation

Do not use a tiny lock timeout for the first experiment. Normal authentication, a saved original file and adequate test time are more useful than accidentally locking every few seconds.

6. Lid close is another policy path

The pinned lid-close helper requests a lock for a closed laptop without external monitors, then reconciles clamshell display state. With an external monitor, clamshell use can intentionally avoid that lid-triggered lock. logind still owns the system lid policy, and Omarchy has additional inhibition for some external connector types logind does not recognize as docked. Lid helper · Docked lid inhibitor

Therefore test these separately, after saving work:

Test	Observe
Lid open, no external display, idle	Timed screensaver/lock behaviour
Lid closed, no external display	Lock and actual suspend/resume
Lid closed with usable external display	External desktop and clamshell policy
External display removed after clamshell use	Accessible output and resulting lid/power action

The stay-awake flag does not disable those lid helpers. Do not edit global logind configuration to solve a Shell timer preference. If a hardware suspend test fails, use sleep troubleshooting and record the connection state; hibernation is a different path, not a necessary setting for a presentation.

7. Confirm secure locking before diagnosing sleep

Omarchy’s sleep-lock service monitors PrepareForSleep with a delay inhibitor and requests the Shell lock. Its wait is bounded by logind’s budget; the system can still sleep if securing the lock failed. “It suspended” is not sufficient proof that it locked safely. Sleep monitor · Bounded lock check

For read-only evidence:

omarchy-shell lock status
omarchy-debug-idle 100
journalctl --user -u omarchy-sleep-lock.service -n 50 --no-pager
journalctl -t omarchy-shell -n 50 --no-pager

When interpreting lock status, distinguish requested from secure; accepting a request is not the same as completing the session lock. Do not disable this service to fix a decorative screensaver. Also do not restart the Shell while locked as a routine timer tweak; diagnose from an authenticated session.

Symptom	Narrow the investigation
No idle lock after the expected delay	Stay-awake state, live timers, app idle inhibitors
Screen blanks but no authentication on return	Display power versus actual lock
Still suspends during a task	Sleep inhibitor lifetime, permissions and lid path
Lock comes at an unexpected time after editing	Fresh cycle versus old pending deadline
Wake returns to an unlocked desktop	Sleep-lock service status and secure-lock evidence
Password seems wrong after locking	First keyboard layout and authentication configuration

8. Restore and finish with a normal cycle

Restore only edited timing values or compare the backup before restoring the whole file. Return the screensaver switch and stay-awake flag to their recorded states. Let the demo inhibitor finish; stop only your own demo if abandoning it, and confirm its entry is gone. Do not remove another application’s inhibitor.

Check the live values, provide input, wait through one normal idle cycle while present, and authenticate successfully. Test manual lock separately. If you changed any long-task routine, verify that the task remains running while the desk locks and that its inhibitor ends when the foreground job finishes.

Keep a record of the goal: “prevent idle interruption during slides” or “block sleep while this task runs, retain desk locking.” This distinction prevents permanent security and power changes from accumulating as temporary fixes. Continue with multi-monitor planning and Shell configuration. This article is source-reviewed; actual lock, sleep and resume behaviour needs a real-system test.