# Feature request: Plugin guardrails and crash isolation for Omarchy

## Summary

Omarchy needs OS-level guardrails to prevent misbehaving plugins from degrading or destroying the user session. Currently, a crashing plugin can flood the screen with notifications, exhaust runtime resources, or wedge the entire shell - with no built-in recovery short of a hard reboot.

## Problem statement

On macOS, a frozen app can be Force Quit without affecting the OS. On Omarchy, a single plugin crash can make the entire system unusable. We have documented three crash patterns with this exact failure mode:

### Pattern 1: Notification storm (Omargram)

A plugin crashes and enters a restart loop, generating unlimited notifications that accumulate until the session is unusable. No rate limit exists. No "Force Quit" equivalent exists for Wayland plugins. Recovery requires hard reboot or `kill -9` from TTY.

### Pattern 2: Resource exhaustion (omarchy#7506)

A timer overflow in the idle service generates ~800 log lines per second, filling `/run/user/$UID` in ~2.3 hours. When tmpfs hits 100%, uwsm's app daemon crash-loops with ENOSPC, and **no application can be launched**. Recovery requires log truncation + shell restart + daemon restart.

### Pattern 3: Shell wedge (omarchy#10108)

After S3 resume, quickshell survives but becomes IPC-dead (spinning at ~1.7% CPU). `omarchy restart shell` cannot recover it because the old PID doesn't exit. Only `kill -9` + manual restart works.

### Pattern 4: Crash popup flood (quickshell#573)

Quickshell crashes 50+ times when idle >15 minutes, generating 50+ crash notification popups. User must dismiss each one manually.

## Why this happens

1. **No restart rate limiting**: Plugins can restart infinitely, generating unlimited notifications or log entries
2. **No resource limits**: Plugins run as siblings of the shell with no CPU/memory isolation
3. **No crash containment**: A plugin crash can propagate to the shell supervision tree
4. **No notification rate limiting**: The notification system (`omarchy.notifications` owning `org.freedesktop.Notifications`) has no per-source rate limit
5. **No watchdog**: No mechanism detects unresponsive plugins independently of the shell

## Proposed guardrails

### P0: Plugin restart rate limit

Cap the number of plugin restart attempts within a time window. After the cap is reached, auto-disable the plugin and notify the user.

```
Example: Max 5 restarts per 60 seconds → plugin auto-disabled, notification: "omargram disabled after repeated crashes"
```

Implementation: In quickshell plugin supervisor, add restart counter with time window per plugin.

### P0: Notification rate limit

Limit the total notification rate across all sources. Excess notifications are coalesced into a summary.

```
Example: Max 3 notifications per 10 seconds from any source → excess notifications queued or dropped
```

Implementation: In `omarchy.notifications`, add per-source token bucket or similar rate limiter.

### P1: Resource isolation via systemd slices

Run each plugin (or plugin group) in a scoped systemd slice with CPU/memory limits.

```
Example: Default slice: CPUQuota=20%, MemoryMax=200M
```

Implementation: Wrap plugin processes in `systemd-run --scope` with resource limits.

### P1: Unresponsive plugin detection

Watchdog that detects plugins not responding to IPC pings and auto-kills them.

```
Example: Ping every 5s → 3 missed pings → kill -9 + restart → if repeated, auto-disable
```

Implementation: Add a background watchdog in omarchy-shell or quickshell.

### P2: Plugin manifest guard config

Allow plugins to declare guard preferences in their `manifest.json`:

```json
{
  "name": "omargram",
  "guards": {
    "maxRestarts": 5,
    "restartWindowSeconds": 60,
    "maxCpuPercent": 20,
    "maxMemoryMB": 200
  }
}
```

Implementation: Extend manifest schema; read guards in plugin supervisor.

### P2: "Force Quit" equivalent

A Hyprland kill mode or keyboard shortcut to kill any visible window by clicking on it:

```
bind = SUPER SHIFT, Q, kill, killactive
```

This already exists in Hyprland (`hyprctl dispatch kill`) but should be documented as a recommended keybind and prominently mentioned in the user guide.

## Implementation priority

| Priority | Feature | Effort | Impact |
|---|---|---|---|
| P0 | Plugin restart rate limit | Low (supervisor change) | Prevents notification storms |
| P0 | Notification rate limit | Medium (daemon change) | Prevents notification flood |
| P1 | Resource isolation | Medium (systemd integration) | Prevents resource exhaustion |
| P1 | Unresponsive plugin detection | Medium (watchdog) | Prevents shell wedges |
| P2 | Plugin manifest guard config | Low (schema extension) | Plugin-specific policies |
| P2 | Force Quit keybind | Trivial (config) | User recovery option |

## Community support

- **omarchy#12182** (Sep 16, 2026): Explicit request for notification rate limiting - open with 0 comments
- **quickshell#573**: 50+ crash popups confirm the problem is real and widespread
- **omarchy#7506**: Resource exhaustion from notification/timer storms confirms no rate limit
- **omarchy#10108**: Shell wedge with no self-recovery confirms no watchdog

## Should be blocked by

- None - this is a new feature, not a fix

## Should be tested with

1. Install Omargram, trigger crash → verify restart limit kicks in
2. Set idle.lock to extreme value → verify notification rate limit prevents storm
3. Run CPU-intensive plugin → verify resource limits enforced
4. Kill quickshell manually → verify watchdog restarts within 15s

## See also

- `omargram-crash-loop.md` - specific incident documentation
- `logout-issue.md` - SDDM/T2 controller death documentation
- `investigation-report.md` - DPMS wake race investigation
- omarchy#12182 - "Let a bar plugin take over notification presentation"
- quickshell#573 - "Too many crashes when PC is idle"
- omarchy#7506 - Timer storm fills runtime dir
- omarchy#10108 - Quickshell wedge, no self-recovery