Add option for the notification interval

[kecsap]

---

Summary by cubic

Adds a configurable toast duration for Magic Context notifications across the TUI. The TUI loads it via RPC and uses a single showToast helper; all flows (including dream and status) now honor the configured duration.

• New Features

  • Added toast_duration_ms to config/schema (1000–60000, default 5000ms); documented in CONFIGURATION.md and exposed in the Dashboard Config Editor.
  • New toast-duration RPC; TUI loads and caches the value on startup and uses a unified showToast with per-toast overrides (10s for setup/restart).
  • NotificationParams now carries toastDurationMs; create-session-hooks and the command handler thread it through so dream/status toasts use the configured duration; added regression test.
  • StatusDetail exposes toastDurationMs; server toasts are sent via RPC notifications and respect the duration.

• Migration

  • Optional: set toast_duration_ms in your config to adjust TUI toast lifetime. Defaults to 5000ms.

^{Written for commit ff07f02. Summary will update on new commits.}

Greptile Summary

This PR introduces a configurable toast_duration_ms setting (schema, Zod validation, documentation, dashboard editor) and wires it end-to-end: a new toast-duration RPC endpoint lets the TUI fetch the value on startup, a unified showToast helper centralises per-toast override logic, and NotificationParams now carries the duration so dream/status notifications respect it.

• toast_duration_ms is validated by Zod (min 1000 / max 60000 / default 5000) and documented in CONFIGURATION.md; the dashboard Config Editor exposes it in the General section.
• A new toast-duration RPC handler returns the resolved value; the TUI caches it in a module variable and retries until a successful load, using explicit durationOverrideMs for latency-sensitive toasts (restarts, cancel, skip).
• sendIgnoredMessage is refactored to use the synchronous pushNotification queue instead of the direct showToast SDK call, threading toastDurationMs from NotificationParams into the queued payload.

Confidence Score: 5/5

Safe to merge; all toast-duration wiring is isolated to notification delivery with correct schema validation and safe fallbacks throughout.

The change is well-scoped: Zod enforces bounds on load, the retry loop degrades gracefully on RPC failure, and explicit durationOverrideMs values are preserved for latency-sensitive toasts. The two findings are minor and do not affect correctness or user-visible behavior.

packages/plugin/src/tui/index.tsx (retry guard) and packages/plugin/src/shared/rpc-types.ts (unused StatusDetail field)

Important Files Changed

Filename	Overview
packages/plugin/src/tui/index.tsx	Adds module-level toast duration state, showToast helper, and refreshToastDurationMs startup/retry logic; retry guard uses value-equality rather than a loaded flag, causing extra RPC calls when the configured value equals the default.
packages/plugin/src/shared/rpc-types.ts	Adds toastDurationMs to StatusDetail interface; the field is populated server-side but never read by any TUI or dashboard consumer.
packages/plugin/src/plugin/rpc-handlers.ts	Adds toast-duration RPC handler and populates toastDurationMs in buildStatusDetail; handler logic is correct.
packages/plugin/src/hooks/magic-context/send-session-notification.ts	Replaces direct showToast SDK call with pushNotification and threads toastDurationMs from params; refactor is clean.
packages/plugin/src/tui/data/context-db.ts	Adds loadToastDurationMs via the new toast-duration RPC; toastDurationMs fallback added to emptyDetail to satisfy the updated StatusDetail type.

Sequence Diagram

sequenceDiagram
    participant Config as Plugin Config
    participant RPC as RPC Server
    participant TUI as TUI (index.tsx)
    participant Toast as api.ui.toast

    TUI->>RPC: toast-duration (on startup)
    RPC-->>TUI: "{ toastDurationMs }"
    TUI->>TUI: "unifiedToastDurationMs = resolved"

    Note over TUI: Poll loop (every ~500ms)
    TUI->>RPC: pending-notifications (sessionId)
    RPC-->>TUI: messages with toast payloads
    TUI->>Toast: showToast(durationOverrideMs ?? unifiedToastDurationMs)

    Note over Config,RPC: Server-side notification path
    Config->>RPC: toast_duration_ms via NotificationParams
    RPC->>RPC: pushNotification with duration

Loading

_{Reviews (7): Last reviewed commit: "fix: thread toast duration through sessi..." | Re-trigger Greptile}

[cubic-dev-ai]

1 issue found across 10 files

<sub>Reply with feedback, questions, or to request a fix.

Fix all with cubic | Re-trigger cubic</sub>

[cubic-dev-ai]

No issues found across 10 files

<sub>Tip: cubic could auto-approve low-risk PRs like this, if it thinks it's safe to merge. Learn more

Re-trigger cubic</sub>

[alfonso-magic-context]

Thanks for this @kecsap — the implementation is clean and the feature is reasonable. Could you rebase onto current master? Two things have changed since you opened it that will conflict with our CI:

1. Removed config keys. nudge_interval_tokens, auto_drop_tool_age, and drop_tool_structure were removed in the nudge redesign (v0.22.x). Your CONFIGURATION.md hunks add toast_duration_ms next to those now-deleted rows, and there's a removed-config-keys.test.ts guard that scans docs + schema and will fail on any reference to them. Please drop those neighboring lines when you rebase.

2. Schema is now generated. assets/magic-context.schema.json is no longer hand-edited — it's generated from the Zod schema via bun packages/plugin/scripts/build-schema.ts. Your Zod change in magic-context.ts is the right source edit; just run the generator so the committed JSON stays in sync (there's a drift-guard test for this too).

Once rebased + schema regenerated and green, happy to merge. Appreciate the contribution.

[kecsap]

There were still problems with the dreamer notifications. It did not honor the new setting. Now, everything is addressed and fixed after rebasing.