Editing a space

Editing a space

Where to edit

$EDITOR ~/.config/omarchy-spaces/spaces.json

Middle click the bar widget cycles to the next space. There is no in-shell editor yet, so the JSON file is the way.

Save and the running shell reloads on its own. The bar widget, the policy, and the CLI all read the same file, so they never disagree.

Always validate after an edit

omarchy-spaces validate

It reports four kinds of problem.

Duplicate space ids.

An allowFrom entry naming a space that does not exist. This is the common one, usually a typo or a leftover after a rename.

Schedule windows that leave part of the day uncovered. Those minutes fall back to the baseline allowFrom, which is legal but rarely what you meant.

Overlapping windows. The first match wins, so the later window silently never applies.

Renaming a space

The id is referenced in three other places. Change all of them together:

1. Other spaces' notifications.allowFrom arrays.
2. Your hotkeys in ~/.config/hypr/bindings.lua.
3. The menu block, refreshed with omarchy-spaces install-menu.

The active state file may still hold the old id. It falls back to the config's activeSpace if the stored id no longer resolves, so nothing breaks, but set it explicitly:

omarchy-spaces switch <new-id>

Deleting a space

Remove the object from spaces, then remove every allowFrom reference to it. validate will point at any you missed. Refresh the menu afterwards.

Changing the default space

activeSpace at the top level of the config decides which space is active when no state file exists yet. It does not override a running session.

Editing safely

The file is read on every change, so a half saved file can produce a parse error. Nothing is lost when that happens. The service keeps the last good config and logs the error:

journalctl --user --since '-5min' | grep omarchy-spaces

Fix the JSON and it reloads.