# ControlSession.notifications

- **Module:** ControlSession
- **Package:** libtmux-swift
- **Language:** Swift
- **Kind:** property
- **Source:** https://github.com/libtmux/libtmux-swift/blob/f02a4668570e1cc5198c941413750e021f42c214/Sources/LibTmux/ControlSession.swift#L131
- **Page:** https://libtmux.org/reference/swift/controlsession-notifications/

Everything the server volunteered: `%output`, `%window-add`, and the rest.

Each access is an observer of its own, and every observer sees every
notification. Two iterators of one `AsyncStream` would divide them
instead — which is the shape a waiter and a watcher on the same
connection have, so it cannot be left to the caller to avoid.

Anything that arrived before the first observer is replayed to it, so
acting and then observing is not a race. That replay covers the first
observer alone, and every later one starts where it subscribed — so two
observers of one event are both taken before the command that causes it.
An `async let` is late enough to miss it: its initializer is evaluated
in the child task, not where it is written.
A slow observer fails with ``TmuxError/notificationBufferOverflow(limit:)``
rather than retaining connection output without bound.