Feature request: support Apple's native Urgent toggle

[Amitdvl]

Problem

remindctl can set public EventKit alarms with --alarm, but that is not the same as the native Urgent toggle in Reminders.app.

Reproduction

1. Create or edit a timed reminder with remindctl.
2. Set --alarm to the due time.
3. Inspect the reminder in Reminders.app.

The reminder has an alarm notification, but the native Urgent switch remains off.

Requested capability

Please add a supported CLI option/API for the native Urgent state (for example --urgent and --no-urgent) if Apple exposes a viable supported path. The README currently says the private Urgent toggle is not exposed by EventKit; if this cannot be implemented through public APIs, please document the limitation and any supported alternative clearly in the CLI output/docs.

Tested with remindctl 0.3.4 on macOS, using remindctl edit <id> --alarm "YYYY-MM-DD HH:mm".

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed September 6, 2026, 3:14 AM ET / 07:14 UTC.

Summary
Keep open: native Urgent support is absent, and CLI help does not explain the distinction already documented in the README. The repository’s conservative closure policy does not permit treating that partial coverage as completion.

Reproducibility: not applicable. as a bug reproduction: the reported distinction matches the documented alarm contract. Source inspection confirms the missing native control; no macOS runtime reproduction was executed.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.

Maintainer decision needed

Question	Recommendation
Should this request be scoped to clearer CLI guidance now, with native Urgent controls deferred until a supported Apple API is demonstrated?	Clarify help now: Complete the requested fallback through add/edit help and command documentation while preserving the public API boundary.

Why: Documentation establishes a public-EventKit-only boundary, while the request spans both a small help improvement and a capability whose supported implementation is unknown.

Next step
Choose whether to narrow this to the requested help clarification before implementation; native-toggle work is not a bounded existing-behavior repair.

Review details

Best possible solution:

Explain in add/edit help that --alarm schedules a notification without enabling native Urgent, and add native controls only when a supported Apple API is demonstrated.

Do we have a high-confidence way to reproduce the issue?

Not applicable as a bug reproduction: the reported distinction matches the documented alarm contract. Source inspection confirms the missing native control; no macOS runtime reproduction was executed.

Is this the best way to solve the issue?

Unclear for native controls because no supported API was established; extending the existing alarm help is the narrowest solution to the explicitly requested documentation fallback.

AGENTS.md: not found in the target repository.

Remaining risk / open question:

• No supported Apple API for changing native Urgent was established; adding a flag before resolving that boundary could promise behavior the backend cannot provide.

Codex review notes: model internal, reasoning medium; reviewed against e7fad8c848a3.

Label changes

Label changes:

• add P3: This requests an optional capability and clearer help; the existing notification-alarm contract is not shown to be broken.
• add issue-rating: 🌊 off-meta tidepool: Current issue advisory state selects this label.
• add clawsweeper:no-new-fix-pr: Current issue advisory state selects this label.
• add clawsweeper:needs-maintainer-review: Current issue advisory state selects this label.
• add clawsweeper:needs-product-decision: Current issue advisory state selects this label.

Label justifications:

• P3: This requests an optional capability and clearer help; the existing notification-alarm contract is not shown to be broken.

Evidence reviewed

What I checked:

• Current implementation and repository identity: The origin remote identifies openclaw/remindctl; HEAD and the checked-out main branch match the supplied target SHA. The working tree was clean. (e7fad8c848a3)
• Documented public-API boundary: README.md explains notification alarms, explicitly distinguishes native Urgent, and states that unsupported Reminders features require new public APIs or a separate backend. The reporter acknowledges this existing documentation. (README.md:176, e7fad8c848a3)
• Alarm write path: Creation constructs EKAlarm with an absolute date; editing delegates to replacement of absolute alarms. The focused regression tests preserve relative and geofence alarms. These paths implement notification alarms without a native Urgent property. (Sources/RemindCore/EventKitStore.swift:127, e7fad8c848a3)
• Remaining CLI explanation gap: Add help calls --alarm “Alarm date”; edit help calls it “Set alarm date.” Neither command’s discussion explains native Urgent, and HelpPrinter renders those command definitions directly. (Sources/remindctl/Commands/EditCommand.swift:23, e7fad8c848a3)
• Apple API reference: Apple’s EKReminder reference lists priority, dates, and completion properties without an Urgent property. Its alarm guide describes notification delivery. This supports the documented distinction but does not prove that every alternative Apple API is unavailable.
• Release context: Current changelog records alarm support in 0.2.0 and alarm-preservation changes in 0.3.3; neither those entries nor the 0.3.4 and 0.3.5 entries announce native Urgent support. The supplied latest release is v0.3.4; local main also contains a v0.3.5 release entry and tag, without independent publication verification. (CHANGELOG.md:1, e7fad8c848a3)

Likely related people:

• Peter Steinberger: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)
• Sebastien Tardif: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

[steipete]

Implemented the requested documentation fallback in #80. remindctl add --help, edit --help, and the command docs now explain that --alarm schedules a notification without enabling native Urgent, and direct users to Reminders.app to enable it. Verified both commands using the built release binary. The public EventKit SDK does not expose a native Urgent control, so no unsupported toggle flag was added. Thanks for reporting the missing guidance.