Limits on DataSpell Notification Suppression: When Alerts Become Unavoidable

Limits on DataSpell Notification Suppression

DataSpell relies on the IntelliJ Platform’s notification system, exposed through Settings/Preferences | Appearance & Behavior | Notifications. Each alert source—such as Jupyter server connection changes, Python/conda interpreter updates, package installation progress, or inspection results—belongs to a named notification group. The platform offers three display options per group: Balloon, Log only, or Suppress.

While most groups can be muted without losing critical information, some alerts still surface as blocking dialogs that bypass the notification settings. For example, kernel startup failures or missing interpreter dependencies may trigger modal windows that cannot be silenced via the group configuration. Additionally, the notification infrastructure does not provide a DataSpell‑specific per‑cell or per‑notebook suppression mechanism; all alerts are governed by the global group rules.

Because of this, users face a trade‑off: aggressive suppression can hide vital failure notifications, whereas keeping all alerts visible can overwhelm the workspace with non‑actionable messages.

Unresolved questions:

• Can the Python interpreter notification group be configured to hide all interpreter‑related alerts while still reporting critical failures such as a missing interpreter?
• Which notification groups, if any, are immune to suppression because they trigger blocking dialogs, and what are those groups?
• Is there a programmatic or project‑specific way to adjust notification settings—e.g., via a settings file or API—so that different notebooks can have tailored alert behavior?