Calendar: no way to create or update an event with NO reminders (useDefault:false + empty overrides)

[jamespublishlab]

Problem

There is no way to create or update a calendar event with no reminders.

The Calendar API distinguishes three states:

reminders payload	Meaning
absent	use the calendar's defaultReminders
{"useDefault": false, "overrides": [{...}]}	these specific reminders
{"useDefault": false, "overrides": []}	no reminders at all

gog can express the first two. The third is unreachable, because an empty
--reminder is treated as "unspecified" rather than as "none".

Why it matters

Google applies a calendar's single defaultReminders list to all-day events
created via the API, ignoring the separate "All-day event notifications" setting
shown in the web UI. So an all-day event created by gog on a calendar whose
timed default is popup 10m inherits that popup — and a 10-minute popup on an
all-day event fires at 23:50 the evening before.

There is no way to avoid this from gog: clearing the all-day setting in the UI
has no effect (the API path uses defaultReminders), and the timed default has
to stay for real meetings.

Reproduction

# a calendar whose defaultReminders is [{popup, 10}]
gog calendar create primary --summary "all-day marker" --all-day \
    --from 2030-05-01 --to 2030-05-02 --json -n

The request body contains no reminders key, so the default is inherited:

"event": {
  "end":     {"date": "2030-05-02"},
  "start":   {"date": "2030-05-01"},
  "summary": "all-day marker"
}

Attempting to suppress it:

gog calendar create primary ... --reminder ""    # -> no reminders field at all
gog calendar update primary <id> --reminder ""   # -> {"useDefault": true}

The update case is the surprising one: --reminder "" documents as "Set empty to
clear", but it sets useDefault: true, which restores the calendar default
rather than clearing reminders.

Cause

buildReminders in internal/cmd/calendar_build.go returns nil for an empty
input, and nil means "use calendar defaults":

//nolint:nilnil // nil return is intentional: nil means "use calendar defaults"
func buildReminders(reminders []string) (*calendar.EventReminders, error) {
	if len(reminders) == 0 {
		return nil, nil
	}
	var filtered []string
	for _, r := range reminders {
		if strings.TrimSpace(r) != "" {
			filtered = append(filtered, r)
		}
	}
	if len(filtered) == 0 {
		return nil, nil
	}
	...

EventReminders{UseDefault: false, Overrides: overrides} is only ever
constructed with at least one override, so overrides: [] is unreachable. In
calendar_update_patch_plan.go a nil becomes {UseDefault: true}.

Confirmed identical on 0.12.0 and 0.37.0.

Suggested fix

A --no-reminder / --reminders-none flag (or a reserved --reminder none)
that produces:

"reminders": {"useDefault": false, "overrides": []}

with UseDefault in ForceSendFields, exactly as the existing override path
already does.

Workaround

Calling the API directly with that body works — Google accepts an empty
overrides list without complaint, so the limitation is purely in how the flag is
interpreted:

PATCH https://www.googleapis.com/calendar/v3/calendars/{calendarId}/events/{eventId}
{"reminders": {"useDefault": false, "overrides": []}}

Version

gog v0.37.0 (Homebrew), macOS arm64

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed August 17, 2026, 6:54 PM ET / 22:54 UTC.

Summary
Current main still cannot express an explicit no-reminder state. This is a small, useful Calendar addition, but its public CLI syntax needs a maintainer decision because empty --reminder currently has established reset-to-default behavior.

Reproducibility: yes. for the CLI payload path: an empty reminder list returns nil and update converts it to UseDefault: true; a live Calendar account is still needed to verify provider behavior end to end.

Maintainer decision needed

Question	Recommendation
Should gog add an explicit Calendar CLI mode for an event with no reminders, and should it be a dedicated boolean flag rather than redefining an empty --reminder value?	Add a dedicated no-reminder flag: Introduce a clear create/update boolean mode that sends an explicit empty override list while retaining the existing empty-value reset behavior.

Why: Current code and tests define an empty update value as reset-to-default, while the requested third state needs a new user-visible API surface.

Next step
Maintainers need to select the permanent public CLI syntax before a narrow implementation can be prepared.

Review details

Best possible solution:

Choose an explicit, non-ambiguous no-reminder syntax, preserve empty update values as the existing reset-to-default behavior, and add payload plus live Calendar API proof for create and update.

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

Yes for the CLI payload path: an empty reminder list returns nil and update converts it to UseDefault: true; a live Calendar account is still needed to verify provider behavior end to end.

Is this the best way to solve the issue?

Unclear until maintainers select the CLI contract; a dedicated flag is safer than changing the established meaning of an empty value.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• Redefining an empty --reminder value would conflict with the current documented and tested update behavior that resets to calendar defaults.
• The chosen syntax needs live Google Calendar API proof for both create and update payloads.

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

Label changes

Label changes:

• add P2: This is a bounded Calendar workflow limitation that can create unwanted reminders but has limited blast radius.
• add impact:other: The issue concerns Calendar event notification behavior, which is meaningful user impact outside the owned impact taxonomy.
• add issue-rating: 🦞 diamond lobster: Current issue advisory state selects this label.
• add clawsweeper:source-repro: 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:

• P2: This is a bounded Calendar workflow limitation that can create unwanted reminders but has limited blast radius.
• impact:other: The issue concerns Calendar event notification behavior, which is meaningful user impact outside the owned impact taxonomy.

Evidence reviewed

What I checked:

• Current reminder builder: buildReminders returns nil when all supplied values are empty, so create has no representation for an explicit empty override list. (internal/cmd/calendar_build.go:221, eb85a99366eb)
• Update resets to defaults: When --reminder was supplied but the builder returns nil, update emits UseDefault: true, restoring calendar defaults rather than an explicit no-reminder state. (internal/cmd/calendar_update_patch_plan.go:258, eb85a99366eb)
• Existing contract coverage: The current test expects an empty --reminder to produce UseDefault=true, and the update documentation says an empty value clears reminders without defining a no-reminder mode. (internal/cmd/calendar_edit_test.go:63, eb85a99366eb)
• Release confirmation: The v0.37.0 tag contains the same relevant implementation as current main, so the reported limitation is present in the cited release as well. (internal/cmd/calendar_build.go:221, 45b5d766e137)
• Product scope: VISION.md supports small useful Calendar primitives but asks for discussion of new command/API surfaces, which applies to a new explicit reminder-state flag or sentinel. (VISION.md:7, eb85a99366eb)
• Available history: Available blame assigns the current shipped lines to the v0.37.0 release snapshot; the accessible file history also identifies a prior Calendar planning refactor, but incomplete local history prevents stronger attribution. (internal/cmd/calendar_build.go:221, 45b5d766e137)

Likely related people:

• Peter Steinberger: The available history shows the current reminder implementation in the v0.37.0 release snapshot and a prior Calendar planning refactor under this author; deeper provenance is unavailable in the partial local history. (role: recent Calendar-path contributor; confidence: low; commits: 45b5d766e137, 77c904ee3b9c; files: internal/cmd/calendar_build.go, internal/cmd/calendar_update_patch_plan.go)

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.