`time create` and `time update` panic on `--start`

[leo-cheron]

time create and time update panic on --start

Summary

clickup-cli time create and clickup-cli time update panic during argument parsing whenever --start is passed, making it impossible to log a time entry for a past interval. clickup-cli time list --start is unaffected.

The panic comes from clap, not from the API layer — it happens before any network call.

Version / environment

• clickup-cli 0.14.0
• macOS, Darwin arm64
• Installed via npm i -g @nick.bester/clickup-cli

Reproduction

clickup-cli time create --start 1753800000000 --duration 3600000

thread 'main' (8147786) panicked at
/Users/runner/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/clap_builder-4.6.0/src/parser/error.rs:32:9:
Mismatch between definition and access of `start`.
Could not downcast to TypeId(0xae6c4318bb07632e00428affbea41961),
need to downcast to TypeId(0x54661232f4503ad5453a68e57906db78)

Exit code 101. Same panic for:

clickup-cli time update <entry_id> --start 1753800000000

Blast radius

Command	--start	Result
time create	1753800000000	panic, exit 101
time update <id>	1753800000000	panic, exit 101
time list	1753800000000	works, exit 0
comment list --task <id>	—	works, exit 0

Likely cause

clickup-cli time create --help shows two semantically different --start-family options on the same command:

      --start <START>              Start time (Unix ms)
      --start-id <START_ID>        Boundary comment id (v2 start-id-based comment endpoints). Pair with --start

The global/shared option block appears to register --start as the comment-pagination boundary (a string), while time create / time update register their own --start as a numeric Unix-ms timestamp. clap stores the value under one type and the subcommand reads it back as the other, so ArgMatches::get_one::<T>("start") fails the downcast and panics.

time list presumably survives because its --start is declared as a string (--start ISO|ms), matching what the shared block registered.

Two things worth noting:

• The shared pagination flags (--start-id, --cursor, --page, --limit, --all) are surfaced on time create, where none of them apply. Scoping the pagination block to the commands that actually paginate would remove the collision at the source.
• A type mismatch like this is detectable at startup — Command::debug_assert() in a test would have caught it before release.

Expected

time create --start <ms> --duration <ms> creates the entry and prints it, matching the documented usage in time create --help.

[isaacrowntree]

Thanks for the detailed report — but I think this landed on the wrong repo.

This project (triptechtravel/clickup-cli) is a Go binary named clickup, distributed via GitHub releases and scripts/install.sh. It isn't published to npm, has no version 0.14.0, and uses cobra rather than clap — so a clap ArgMatches downcast panic can't occur here. The commands in the report don't exist either: our surface is clickup task time log|list|delete (plus timer subcommands), with no time create/time update, no --start, and no shared --start-id/--cursor pagination block.

@nick.bester/clickup-cli is a different project — https://github.com/nicholasbester/clickup-cli. That's where this belongs.

Closing here as not-applicable, but the write-up is a good one; sorry for the redirect.

[leo-cheron]

Oh boy, sorry for this.