--url flag is ignored when creating reminders

[alex-ross]

Summary

The --url flag does not appear to attach a URL to the created reminder.

Environment

• remindctl 0.3.1
• macOS 26.4.1 (25E253)

Steps to reproduce

1. Create reminder

remindctl add "Example task" --url "https://example.com"

2. Inspect the created reminder in the app

References

Relates to Add --url support to set the reminder URL field (#56)

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed June 25, 2026, 5:20 PM ET / 21:20 UTC.

Summary
Keep open: current main still has the same released URL write path that users report as not populating the Reminders.app-visible URL field, and there is no newer source fix or canonical open PR for the remaining behavior.

Reproducibility: yes. for triage, but not self-reproduced here: this issue gives exact v0.3.1/macOS steps with screenshots, and a separate post-merge report describes the same failure. A high-confidence current-main result still needs live macOS/EventKit verification.

Next step
Manual macOS/EventKit review is needed because automation cannot determine whether to repair source behavior or change the app-visible URL contract without a live Reminders.app comparison.

Review details

Best possible solution:

Run a live macOS comparison of add --json, info --json, and the same reminder in Reminders.app, then either fix the write target or revise the documented --url contract to match the app-visible behavior maintainers want.

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

Yes for triage, but not self-reproduced here: this issue gives exact v0.3.1/macOS steps with screenshots, and a separate post-merge report describes the same failure. A high-confidence current-main result still needs live macOS/EventKit verification.

Is this the best way to solve the issue?

No: closing as implemented would rely on the same v0.3.1 URL write path that users report as failing in Reminders.app. The narrow next step is a live Reminders.app versus CLI JSON comparison before choosing a code fix or contract change.

AGENTS.md: not found in the target repository.

Remaining risk / open question:

• This review environment cannot run the macOS EventKit and Reminders.app comparison needed to separate a source write bug from an app UI field mismatch.
• The current implementation may write EKReminder.url correctly while still not satisfying the documented app-visible URL-field behavior users expect.

Codex review notes: model internal, reasoning high; reviewed against 4e8643ff0ed9.

Label changes

Label changes:

• add issue-rating: 🐚 platinum hermit: Current issue advisory state selects this label.
• add clawsweeper:needs-live-repro: Current issue advisory state selects this label.
• add clawsweeper:fix-shape-clear: Current issue advisory state selects this label.
• remove issue-rating: 🦐 gold shrimp: Current issue advisory state no longer selects this label.
• remove clawsweeper:needs-info: Current issue advisory state no longer selects this label.

Label justifications:

• P2: A documented released CLI option appears to accept user-provided reminder metadata while not producing the expected app-visible result.
• impact:data-loss: The issue is about a user-supplied URL being absent from the created reminder after the command succeeds.

Evidence reviewed

Acceptance criteria:

• On macOS with Reminders access, run remindctl add "Example task" --url "https://example.com" --json.
• Run remindctl info <created-id> --json and confirm whether the CLI reads the URL back.
• Inspect the same reminder in Reminders.app and confirm whether the visible URL/link field is populated.
• If code changes are made, run the repository check command appropriate for Swift changes, such as make check, on a macOS-capable environment.

What I checked:

• Issue reproduction evidence: The issue body gives exact v0.3.1 steps for remindctl add "Example task" --url "https://example.com" and screenshots showing the created reminder without the expected app-visible URL.
• Add command forwards URL: Current main defines --url, parses it with CommandHelpers.parseURL, and passes it into ReminderDraft, so the command-layer flag is wired but this does not prove the Reminders.app field is populated. (Sources/remindctl/Commands/AddCommand.swift:91, 4e8643ff0ed9)
• EventKit create path writes url property: The create path assigns reminder.url = draft.url before saving, matching the implementation added for URL support but not explaining the app-visible mismatch. (Sources/RemindCore/EventKitStore.swift:128, 4e8643ff0ed9)
• Readback uses the same EventKit property: The fetch and item conversion paths read reminder.url, so existing CLI JSON proof can confirm EventKit readback while still missing the Reminders.app UI comparison reported here. (Sources/RemindCore/EventKitStore.swift:371, 4e8643ff0ed9)
• Release already advertised this feature: v0.3.1 documents support for setting the reminder URL field via --url on add/edit and --clear-url on edit, which is the released version named in the report. (CHANGELOG.md:5, 04fbfd02e76f)
• No post-report source fix on main: The diff from v0.3.1 to current main only opens the unreleased 0.3.2 changelog section, so current main has no URL-path code change after the reported released behavior. (CHANGELOG.md:3, 4e8643ff0ed9)

Likely related people:

• jeremylahners: Authored the merged commit that added add --url, edit --url, URL model fields, and the reminder.url create/update assignments. (role: introduced URL write path; confidence: high; commits: 35ca6647e73a, 71c1e1739738; files: Sources/remindctl/Commands/AddCommand.swift, Sources/remindctl/Commands/EditCommand.swift, Sources/RemindCore/EventKitStore.swift)
• steipete: Pushed the URL validation/test follow-up, documented the live CLI/EventKit proof, prepared v0.3.1, and earlier added URL metadata read support. (role: recent area contributor and release follow-up; confidence: high; commits: 8162390e1f4e, 57a73aaae14a, 04fbfd02e76f; files: Sources/remindctl/CommandHelpers.swift, Tests/remindctlTests/URLCommandTests.swift, Sources/RemindCore/EventKitStore.swift)

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.