# Notification content is exposed in process command lines (`/proc/*/cmdline`)

## Summary

The notifications plugin persists every notification by spawning
`bash -c … -- <paths> <json> …`, where `<json>` is the **serialized
notification** (summary + body) passed as a positional argument. The content
is therefore visible in the process's `argv`, i.e. in `/proc/<pid>/cmdline`,
to any local process for the lifetime of the (short) job.

This is **not an injection bug** — the code is careful and correct on that
front: the JSON travels as `$3`/`$json` and is never re-parsed by the shell
(the in-code comment at `persistPopupFile` says exactly this). Bodies with
quotes/backticks/`$()` cannot break the command. The issue is purely that
arbitrary notification text ends up in a process command line.

## Impact

1. **Privacy / info-leak.** Notification bodies can contain sensitive data
   (2FA codes, private DMs, email previews). Any unprivileged local process
   can read them from `/proc/*/cmdline` while the persist/history job runs.

2. **Host-based EDR false positives.** Endpoint agents (CrowdStrike Falcon,
   etc.) match IOC patterns against process command lines. When a notification
   body happens to contain attack-looking text — e.g. someone pastes a
   command-injection PoC into a chat app that raises a desktop notification —
   the persist job's `argv` contains that string and the EDR fires a
   detection on an otherwise-benign local action. In a corp-managed
   environment this generates SOC alerts and triage work. It also creates a
   self-sustaining loop: the alert gets discussed in the same chat thread →
   new notification → new persist job carrying the discussion text → new
   alert.

## Reproduction

1. On an Omarchy shell, send a desktop notification whose body contains any
   shell-metacharacter text (a command-injection-looking snippet — the kind of
   thing that naturally appears when someone pastes a PoC into Slack/Discord).
2. While the notification is being persisted, observe the spawned process via
   `pgrep -af 'bash -c'`, or inspect
   `~/.local/state/omarchy/notifications/history/*.json` — the same body text
   is what was passed on the command line.
3. The body string is present in the process `argv` (`/proc/<pid>/cmdline`).

Note: **Do Not Disturb does not mitigate this.** DND-silenced notifications
still go through `writeHistoryFile`, which uses the same
`bash -c … <json> …` argv-passing. DND only suppresses the visible toast.

## Affected code

`shell/plugins/notifications/Service.qml`

- `persistPopupFile` — `command = ["bash","-c", …, "--", popupStateDir,
  imagesDir, serializePopup(...), …]` (JSON as an arg)
- `writeHistoryFile` — same pattern (also on the DND-silenced path)

Image copy from/to paths are less of a concern (they're internal file paths),
but the serialized JSON is arbitrary sender-controlled content.

## Suggested fix

Keep passing **paths** as positional args (they're safe and needed), but feed
the **serialized JSON payload via stdin** instead of `argv`, then read it in
the script. Sketch:

```sh
# script reads the payload from stdin, not from "$json"
mkdir -p "$1" "$2" || exit 0
dir="$1" name="$4"
shift 4
# … copyImagesScript over the remaining from/to pairs …
cat > "$dir/$name"          # payload arrives on stdin
```

with the QML side writing `serializePopup(...)` to the process's stdin
(Quickshell `Process` `stdinEnabled` + `write`, or an equivalent
`Util.execDetached` variant that accepts stdin). This removes notification
content from `/proc/*/cmdline` entirely, fixing both the privacy leak and the
EDR false positives, while preserving the existing injection-safe behaviour.

## Environment

- Omarchy 4 "Quattro", Quickshell-based shell
- `shell/plugins/notifications/Service.qml`