calendar events list rejects single calendar selector — --cal / --calendars / --all / positional all error out

Version

v0.14.0 (469f4b4 2026-04-28T09:39:03Z)

Reproduced on a Linux x86_64 host (Debian 13), installed via brew upgrade gogcli. Same behavior was present in v0.13.0.

Summary

gog calendar events list rejects every documented form of single-calendar selection. Selecting via the positional [<calendarId>], the --cal=<id>, the --calendars=<id> flag, OR the --all flag all error out — even when only one of those is passed.

The conflict-check error message ("calendarId not allowed with --cal/--calendars") makes it look as if multiple selectors were used, but they were not. As a result, the only call that succeeds is the unqualified one (gog cal events list --today), which falls back to the account's primary calendar — useless for users whose schedule lives on a non-primary calendar (a forwarded/owned secondary, a delegated work calendar, etc.).

Help text — both forms documented as supported

$ gog cal events list --help
Usage: gog calendar (cal) events (list,ls) [<calendarId>] [flags]
...
Arguments:
  [<calendarId>]    Calendar ID (default: primary)
...
      --cal=CAL,...            Calendar ID or name (can be repeated)
      --calendars=STRING       Comma-separated calendar IDs, names, or indices
                               from 'calendar calendars'
      --all                    Fetch events from all calendars

Reproduction

bobby.cude@gmail.com is subscribed and visible to gog cal calendars:

$ gog cal calendars --plain
ID                                              NAME                       ROLE
bcopenclaw@gmail.com                            bcopenclaw@gmail.com       owner
en.usa#holiday@group.v.calendar.google.com      Holidays in United States  reader
bobby.cude@gmail.com                            bobby.cude@gmail.com       reader

All four call forms fail:

$ GOG_ACCOUNT=bcopenclaw@gmail.com gog cal events list --calendars bobby.cude@gmail.com --today --plain
calendarId not allowed with --cal/--calendars
(exit 2)

$ GOG_ACCOUNT=bcopenclaw@gmail.com gog cal events list --cal bobby.cude@gmail.com --today --plain
calendarId not allowed with --cal/--calendars
(exit 2)

$ GOG_ACCOUNT=bcopenclaw@gmail.com gog cal events list --calendars 2 --today --plain
calendarId not allowed with --cal/--calendars
(exit 2)

$ GOG_ACCOUNT=bcopenclaw@gmail.com gog cal events list bobby.cude@gmail.com --today --plain
unexpected argument bobby.cude@gmail.com
(exit 2)

$ GOG_ACCOUNT=bcopenclaw@gmail.com gog cal events list --all --today --plain
calendarId or --cal/--calendars not allowed with --all flag
(exit 2)

I tried the -- separator before the positional and a single-token --calendars=<id> form. Same errors.

Expected

--calendars, --cal, the positional [<calendarId>], and --all should each succeed when used alone. The conflict-check should only fire when two or more of these selectors are passed together.

Actual

The conflict-check fires whenever any of those selectors is present, before the API call is attempted. The only call that succeeds is the unqualified form, which falls back to the account's primary calendar.

Impact

Any user whose real schedule lives on a non-primary calendar (delegated work calendars, secondary owned calendars, shared calendars they read from another account) cannot retrieve events at all via events list in 0.14.0. The events list subcommand is effectively limited to the OAuth account's primary calendar.

Workaround

None inside gogcli. I am building a Python fallback that calls the Calendar v3 API directly (using the OAuth client and refresh token gogcli already has stored) until this is fixed upstream.

Related code

The error string calendarId not allowed with --cal/--calendars and calendarId or --cal/--calendars not allowed with --all flag should be findable in the events-list command parser in the gogcli source. The check appears to fire on presence of any single selector instead of presence of two-or-more.

Thanks for the great tool.