Repository navigation
edit --list / --list-id fails with ReminderKit error -3002 when a shared list is on either end of the move #104
Description
Bug
Moving a reminder between lists fails with com.apple.reminderkit error -3002 when the source or the target list is a shared/collaborative list, and succeeds when neither is. remindctl 0.3.8, macOS 27.0.1 build 26A434, Apple Silicon, one iCloud account with no On My Mac or work account, remindctl status reporting full-access.
Repro
# Shopping is a shared iCloud list; Apps is a plain iCloud list.
remindctl add "rem-3002-repro" --list Shopping --json --no-input
# id 1A827CE7-6B73-4764-810E-A36DCEB4114D
remindctl edit 1A827CE7 --list Apps --json --no-input
# exit code 1
# stderr: The operation couldn't be completed. (com.apple.reminderkit error -3002.)
# stdout: emptyThe reminder stays in Shopping, and retries give the same error rather than a transient failure. --list and --list-id both fail, and passing the full UUID rather than a prefix makes no difference. Non-list edits on the same reminder work, so the save path itself is fine:
remindctl edit 1A827CE7 --priority high --json --no-input # ok
remindctl edit 1A827CE7 --notes "ok" --json --no-input # okMove direction is not the variable, sharing is:
| Move | Result |
|---|---|
| non-shared → non-shared | works |
| shared → non-shared | -3002 |
| non-shared → shared | -3002 |
Likely cause
Public EventKit has no move API. EKEventStore exposes saveReminder:, removeReminder:, saveCalendar: and removeCalendar: only, so the only way to move is to set the settable EKCalendarItem.calendar and save, which appears to be what edit --list does through CommandHelpers.listTarget and the update path. The upstream analysis in BRO3886/go-eventkit#13 is that EventKit rejects that save when a shared list is on either end, because it treats a shared/collaborative list as effectively its own source, and EventKit's own error constants document the neighbouring restrictions (EKErrorCalendarSourceCannotBeModified, EKErrorSourceDoesNotAllowCalendarAddDelete, and EKCalendar.h's note that you cannot move to another source).
Two things point at the sharing boundary rather than a general save problem. AppleScript's native move command succeeds on the same machine, account and lists, including between two shared lists, which suggests a sanctioned reparent exists below EventKit. The same matrix is reported in BRO3886/rem#50, with the root cause written up in BRO3886/go-eventkit#13; see also viticci/remctl#13 and FradSer/mcp-server-apple-events#81. Nothing here is documented by Apple.
Expected
Either the move works, or the failure names the actual constraint.
- Preferred, and within the project's public-EventKit stance: detect the boundary before attempting the save and fall back to copy and delete, printing a warning that the new reminder gets a new ID. BRO3886/go-eventkit@6a7610a implements this as
moveViaCopyand is a workable reference. - At minimum, replace the bare
-3002with a message that names the shared-list boundary, since the current error gives no hint where to look. - If the limitation is accepted as-is, two smaller gaps are worth closing with it.
remindctl list --jsonreturns onlyid,overdueCount,reminderCountandtitle, so a caller cannot see which lists are shared; anisSharedfield would let scripts detect the case. Anddocs/commands.mddocumentsremindctl edit 4A83 --list Officewith no caveat, while the README's "EventKit Limits" list would be the natural home for it.
Activity
clawsweeper commentedon Oct 17, 2026
Codex review: this still needs some work.
Summary
This issue establishes a specific v0.3.8 move failure, and current main retains the same save path without contextual handling.
Reproducibility: The reporter supplies a controlled affected-release reproduction, corroborated by external investigation; current source proves the reassignment and raw-error path, but cannot establish when EventKit rejects the save.
Maintainer decision needed
Next step
Choose diagnostic-first handling or an explicit identity-changing fallback, then establish a failing shared-list move regression on macOS.
Review details
Best possible solution:
Provide an actionable move-failure diagnostic and documented limitation first, with any identity-changing fallback separately approved.
Do we have a high-confidence way to reproduce the issue?
The reporter supplies a controlled affected-release reproduction, corroborated by external investigation; current source proves the reassignment and raw-error path, but cannot establish when EventKit rejects the save.
Is this the best way to solve the issue?
Contextual diagnostics are the safest initial repair; automatically copying and deleting cannot be treated as a transparent move, and -3002 must not be described as uniquely identifying sharing.
AGENTS.md: not found in the target repository.
Remaining risk / open question:
Codex review notes: model internal, reasoning medium; reviewed against 61fb13efbc25.
Label changes
Label changes:
No label changes.
Label justifications:
P2: Shared-list moves fail in a documented CLI operation while ordinary moves and other edits remain usable.impact:ux-friction: The raw platform error provides no useful explanation or recovery guidance.Evidence reviewed
Acceptance criteria:
What I checked:
Sources/RemindCore/EventKitStore.swift:168, 61fb13efbc25)Sources/remindctl/CommandRouter.swift:78, 61fb13efbc25)README.md:295, 61fb13efbc25)internal/service/reminders.go:323, 6a7610a377c7)How this review workflow works
@clawsweeper re-reviewcomments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.@clawsweeper re-reviewor@clawsweeper re-runon an open PR or issue to request a fresh review only.@clawsweeper reviewto request a fresh review only.@clawsweeper explainto ask for more context, or@clawsweeper stopto stop active automation.Reviewed October 18, 2026, 1:58 PM ET / 17:58 UTC.
2 remaining items