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 a unified duration from config via RPC and uses a single showToast helper with per-toast overrides.

• New Features

  • Added toast_duration_ms to config/schema (1000–60000, default 5000ms); documented in CONFIGURATION.md.
  • New toast-duration RPC; TUI loads and caches the unified duration on startup.
  • Replaced direct api.ui.toast() calls with a showToast helper; removed hardcoded durations.
  • NotificationParams now includes toastDurationMs; duration is forwarded via pushNotification toasts, send-session-notification, and the show-status-dialog action payload (toast_duration_ms).
  • StatusDetail includes toastDurationMs for visibility.

• Migration

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

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

Greptile Summary

This PR introduces a configurable toast_duration_ms setting (1000–60000 ms, default 5000) that flows from the Zod schema through a new toast-duration RPC into a module-level unifiedToastDurationMs variable in the TUI, applied via a new showToast helper. The server-side notification path is also updated to carry toastDurationMs through NotificationParams so server-pushed toasts honour the same configured duration.

• Schema & RPC plumbing: toast_duration_ms is added to MagicContextConfigSchema with correct min/max/default constraints, exposed via a dedicated toast-duration RPC handler and surfaced in StatusDetail.
• TUI unification: All direct api.ui.toast() calls are replaced with showToast(api, {...}), which reads unifiedToastDurationMs (loaded on startup) unless a durationOverrideMs is supplied per-call.
• Notification params threading: toastDurationMs is added to NotificationParams and propagated through getLiveNotificationParams, hook wiring, and executeDreaming so server-side notifications carry the configured duration to the TUI poller."

Confidence Score: 5/5

Safe to merge; all toast paths default to 5000 ms and the schema enforces the 1000–60000 ms bounds.

The config plumbing is consistent end-to-end and the fallback to 5000 ms at every layer means the feature degrades gracefully if the RPC call fails at startup. The two flagged observations are style and minor logic concerns that do not affect runtime correctness.

packages/plugin/src/hooks/magic-context/send-session-notification.ts — the catch block reachability assumption changed silently with the refactor.

Important Files Changed

Filename	Overview
packages/plugin/src/tui/index.tsx	Introduces module-level unifiedToastDurationMs loaded at startup, showToast helper that respects per-call durationOverrideMs, and migrates all direct api.ui.toast() calls to use the helper.
packages/plugin/src/hooks/magic-context/send-session-notification.ts	Replaces direct tui.showToast() SDK call with pushNotification() queue; uses params.toastDurationMs for duration. The catch block now only guards against a dynamic import failure that is practically impossible after the same module was already imported and used two lines above.
packages/plugin/src/hooks/magic-context/command-handler.ts	Adds toastDurationMs to deps for executeDreaming and createMagicContextCommandHandler; threads the value into notification params. JSDoc on the new field inaccurately describes it as "forwarded into diagnostics logs" when its primary use is populating NotificationParams.
packages/plugin/src/hooks/magic-context/hook.ts	Threads deps.config.toast_duration_ms into four getLiveNotificationParams call-sites and the command handler; additions are symmetric and correct.
packages/plugin/src/plugin/rpc-handlers.ts	Adds toast-duration RPC handler returning resolved config value, exposes toastDurationMs in StatusDetail via buildStatusDetail, and threads config value into getLiveNotificationParams.
packages/plugin/src/config/schema/magic-context.ts	Adds toast_duration_ms (1000–60000 ms, default 5000) to config interface and Zod schema with correct min/max/default constraints.
packages/plugin/src/shared/rpc-types.ts	Adds toastDurationMs: number field to StatusDetail interface; straightforward type addition.
packages/plugin/src/tui/data/context-db.ts	Adds loadToastDurationMs() helper that calls the toast-duration RPC and returns the resolved value or falls back to 5000; also seeds the empty StatusDetail default with toastDurationMs: 5000.
packages/plugin/src/hooks/magic-context/hook-handlers.ts	Adds toastDurationMs to getLiveNotificationParams signature and spreads it into the result object only when defined; clean conditional spread.
packages/plugin/src/hooks/magic-context/command-handler.test.ts	Updates three test assertions to expect { toastDurationMs: 5000 } in notification params, matching the new default-fallback behavior.
CONFIGURATION.md	Documents the new toast_duration_ms field with its range and default, and adds an example value to the sample config block.

_{Reviews (3): Last reviewed commit: "Add option for the notification interval" | 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>

[greptile-apps]

"Restart required" toasts silently dropped their 10-second override

Both the "Restart OpenCode to enable Magic Context" (line 125) and "Restart OpenCode to see the sidebar" (line 174) toasts previously used duration: 10000. This PR replaces them with showToast calls that carry no durationOverrideMs, so they now use whatever the user configured. At the minimum allowed value of 1000 ms the toast will vanish before most users finish reading the restart instruction, effectively making the post-fix/post-setup call-to-action invisible. Other latency-sensitive toasts in this file were correctly preserved with explicit durationOverrideMs (e.g. "Recomp cancelled" → 3000, "Upgrade skipped" → 4000); these two should be treated similarly with durationOverrideMs: 10000.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

[greptile-apps]

The toast_duration_ms field added to the show-status-dialog action payload is never read by the TUI message handler. When the TUI receives an action message it only reads msg.payload?.action, msg.payload?.resume, etc. — there is no code path that extracts toast_duration_ms from an action payload. The TUI already loads the authoritative duration via loadToastDurationMs() on startup, so the payload field is dead and the log line creates a false impression that the duration propagates per-action.

Suggested change

	pushNotification(
	"action",
	{
	action: "show-status-dialog",
	toast_duration_ms: deps.toastDurationMs ?? 5000,
	},
	sessionId,
	);
	sessionLog(
	sessionId,
	`command ctx-status: pushed show-status-dialog to TUI (toast_duration_ms=${String(
	deps.toastDurationMs ?? 5000,
	)})`,
	);
	pushNotification(
	"action",
	{
	action: "show-status-dialog",
	},
	sessionId,
	);
	sessionLog(
	sessionId,
	"command ctx-status: pushed show-status-dialog to TUI",
	);