feat(clients): save your own snooze presets, like "In 3 days" or "Friday 9 AM"

[mmmattG]

Problem

The Snooze menu has five fixed choices. If you often snooze for the same span, like three days or until Friday morning, you have to go through Custom… every time.

Change

You can now save your own snooze presets. They appear in every Snooze menu after the built-in choices. A preset is one of two kinds:

• A delay, such as In 3 days. Choose minutes, hours, or days.
• A weekday at a time, such as Friday at 9:00 AM.

Add presets in Settings → General → Snooze presets on web or desktop. They're saved on the environment, so the mobile app offers them in its menus too. If you never add one, the menu is exactly what it was. Custom… stays for one-off times.

---

Where to start: read resolveSnoozePresets in packages/client-runtime/src/state/threadSettled.ts and its tests in snoozePresets.test.ts next to it. The rest of the diff stores the list, wires that one function into each surface, and adds the settings row.

Semantics

• Delay presets count elapsed time from when you snooze. A day is 24 hours, even across a DST change. That matches Custom… durations, and both use one unit table.
• Weekday presets resolve to the next such day after today, never today itself. Friday on a Friday means next week. That is how the built-in Next week already treated Mondays, and the built-in is now literally { weekday: 1, time: "09:00" }.
• All times are local to the device you snooze from. The environment stores the rule, and each client resolves it in its own time zone.
  • A wall-clock time skipped by spring-forward rolls forward to the next valid time (02:30 → 03:30).
  • A time repeated by fall-back resolves to its first occurrence.
  • Both are pinned by tests under America/Los_Angeles.
• Order: built-ins first, unchanged, then saved presets soonest first. The time column on saved presets carries the day: 3:45 PM today, Fri 9:00 AM this week, Oct 16, 9:00 AM when a weekday preset lands a full week out.

Duplicates

• In the menu, any choice that lands on the same instant as an earlier one collapses into it. This general rule replaces the old Sunday-only Tomorrow/Next week special case from fix(web,mobile): snooze menu no longer offers the same wake time twice #8741. A saved Tuesday 9:00 AM simply reads as Tomorrow on Mondays.
• In settings, parseSnoozePresetDraft refuses rules that always duplicate a built-in or saved choice (In 60 minutes, Monday 9:00 AM, In 72 hours when In 3 days is saved). It also caps the list at 8 to keep menus scannable.

Storage: a shared server setting

Presets live in the environment's settings.json, next to Snooze limited threads, and are in SHARED_SERVER_SETTING_KEYS. I chose this over a device-local client setting for three reasons:

• Configure once, use everywhere. A preset added on desktop shows up on your phone. This is where the remote workflow needs it most.
• Mobile gets them without its own editor. Mobile mirrors only a handful of web client settings, but it reads shared server settings from the connection. It treats presets like other shared preferences such as the writing style: it uses them and doesn't edit them.
• Time zones still work. A rule like "Friday at 9:00" is wall-clock, so each client still resolves it locally.

How it plays out:

• Web settings row: server-scoped, so the scope picker, mixed-value indicator, Restore defaults, and project-scope "environment-wide" handling all behave as they do for sibling rows.
• Older servers: they drop the key. A new snoozePresets capability makes the row read-only there and keeps shared writes and mismatch checks away from them.
• Which presets a menu uses: each menu uses the presets of the thread's environment. Bulk Snooze (N) merges the selected environments' lists, and identical presets collapse.
• Unreadable entries are dropped, not fatal. The setting decodes with ForwardCompatibleArray, so a preset kind added later never breaks an older build's settings.
• Agents: the t3_environment_preferences_update MCP tool is unchanged. It covers a curated set that excludes sibling thread settings like Snooze limited threads, and agents already snooze to absolute times.

Surfaces

Surface	Entry points
Web and desktop	sidebar hover menu, row context menu, bulk Snooze (N), chat header menu
iOS and Android	row and swipe menus on the Home list and the iPad sidebar

On mobile, the thread-list environment projection carries each environment's list. The array keeps its identity until the presets change, so memoized rows don't re-render on unrelated settings broadcasts.

Scope and approval

This is focused configuration of an established capability:

• What exists: the shared Snooze preset menu on every client.
• What the option controls: extra entries in that menu.
• Why its effects stay within that capability: the default is unchanged, and nothing about snoozing itself changes.

A tracking proposal is drafted and awaiting Matt's review before it's published. I'll link it here once it is.

Verification

• Focused tests, all passing (518 across 12 files):
  • contracts settings covers server decoding, round trips, and dropping unreadable entries.
  • client-runtime snoozePresets, threadSnoozed, customSnooze, and sharedSettings cover ordering, the time column, collapsing, DST, validation, and the capability filter.
  • server serverSettings covers persisting and broadcasting, and a removal replacing the list rather than merging by index.
  • web Sidebar.snooze, threadActionMenu.logic, SettingsPanels.restore, and settingsSearch.
  • mobile threadListV2 covers re-resolving a saved preset at tap time.
  • mobile thread-list-environments covers per-environment lists that stay stable across unrelated broadcasts.
• The client-runtime preset tests also pass under TZ=Asia/Kolkata, Australia/Sydney, and UTC. The host is AWST, which has no DST, so the Los Angeles DST cases really exercise the stub.
• tsc --noEmit passes for packages/contracts, packages/client-runtime, apps/server, apps/web, and apps/mobile.
• Lint on the changed files adds no new warnings. I compared each touched file against its previous version.

In the apps

Codex GPT-6.1-Sol (xhigh) ran these checks against an isolated dev server with neutral fixture data. One real branch name is blurred in the images.

iOS and Android:

• Row menus and swipe menus list the saved presets after the built-ins, with day/time subtitles.
• "In 3 days" snoozes the thread, and Wake brings it back.
• Thread behavior settings have no preset editor, by design.
• With the app open, removing a preset from the server's settings.json removes it from the menu without a restart. Restoring it brings it back.

Android row menu	iOS row menu

Friday removed on the server	Friday restored

Web:

• The sidebar hover menu, row right-click menu, and chat header menu all list saved presets.
• Snoozing with a preset works.
• Duplicate presets are refused with the right messages.

That pass found one bug: the amount field silently corrected 0 to 1, so Enter validated a different preset than the one on screen. It's fixed in 2cae485.

Web screenshots are still pending. The in-app browser host dropped after the first pass, and that pass's captures show personal data, so they aren't posted. The bulk menu, reload persistence, and 24-hour format checks are still to do.

Observed, but not caused by this PR:

• Mobile wake labels read one unit high for up to a minute after snoozing. "In 3 days" shows 4d, and the built-in "In 1 hour" shows 2h. The mobile label clock is rounded down to the minute while the label rounds up. That's unchanged by this PR; I'll handle it separately.
• The iOS simulator brought up the software keyboard when a row menu opened. That's why the iOS shot shows it. This PR doesn't touch menu focus, but I haven't confirmed whether main does the same.

---

Made with Claude Opus 5.5 in the Claude Code harness (xhigh reasoning effort), acting on Matt's behalf. Verification is delegated to Codex GPT-6.1-Sol (xhigh).

🤖 Generated with Claude Code