## Affected component

`shell/Ui/TextField.qml` (shared wrapper around `QtQuick.Controls.TextField`) and every first-party panel that embeds a non-`readOnly` instance of it. Found while reviewing a marketplace plugin update at omacom/omarchy-plugin-marketplace#10868; on inspection it is not specific to that plugin.

Omarchy version: `4.0.4-1` (installed). Checked against the `quattro` branch source on GitHub, which has the identical code.

## What happens

Every editable `TextField` connects, unconditionally and for its whole lifetime, to the **process-global** `QClipboard::dataChanged()` signal (`QQuickTextInput::init()`, `qquicktextinput.cpp:2894` at Qt 6.11.2, the version installed here). The handler, `q_canPasteChanged()`, calls `mimeData->text()` on every firing of that signal — i.e. whenever *any* application in the session writes to the clipboard, regardless of which field has focus or whether the user ever pastes (`qquicktextinput.cpp:3001-3011`, same version). This is skipped only when the field is `readOnly`.

`mimeData->text()` on Wayland reads through `QWaylandMimeData::readData()` (`qwaylanddataoffer.cpp`), which loops `poll()` + `read()` with only a **1-second timeout between chunks** and **no total byte cap and no overall deadline**. A clipboard source that keeps producing data (or stalls just under the per-chunk timeout) can hold that read open indefinitely inside the shared Quickshell process, since all panels run in one process.

Because `readOnly` is the only gate in Qt, and it also disables keyboard editing entirely, there is no way to keep a field both typeable and exempt from this from inside the field itself.

## Where it's instantiated

All of these are plain, non-`readOnly` `TextField`s, created once their panel loads and only toggled via `visible:` (not gated behind a `Loader { active: ... }`), so each is connected to the global clipboard signal for the panel's full lifetime:

- `shell/plugins/panels/weather/Panel.qml:615` — location search
- `shell/plugins/panels/clock/Panel.qml:384` and `:407` — birth year / life expectancy
- `shell/plugins/panels/network/Panel.qml:2020` and `:2044` — WiFi identity + **passphrase**
- `shell/plugins/panels/tailscale/Panel.qml:602` — Mullvad region search

The WiFi passphrase field is the most sensitive instance, since it's where users type a secret into a field that's reading the system clipboard on every unrelated clipboard write elsewhere in the session.

## Impact

Any application in the same session with ordinary clipboard write access — no elevated privilege, nothing beyond what any GUI app already has — can keep this native read open against the shared shell process whenever it broadcasts clipboard changes. This is a shared-process reliability/memory concern (the shell can stall or grow memory while one of these fields exists), not a privilege-boundary crossing, so per `.github/SECURITY.md` this is filed as a regular issue rather than a private report.

## Suggested directions (not prescriptive)

- Gate each field behind `Loader { active: <actively editing> }`, matching the pattern already used in the plugin that surfaced this (omacom/omarchy-plugin-marketplace#10868, `Panel.qml` + `LocationPicker.qml`), so the clipboard connection only exists while the field is genuinely in use rather than for the panel's whole lifetime. This narrows the window but doesn't eliminate it while editing.
- If a full fix needs to happen upstream in Qt/Qt Wayland (bounding `QWaylandMimeData::readData()`, or making `canPaste` computation lazy instead of eager on every clipboard change), it may be worth tracking there and treating this issue as the Omarchy-side mitigation tracker.

Happy to share the exact source citations/commit SHAs I checked them against if useful.