todos list --status completed não devolve to-dos completos

[Tiagoasf12]

There's a bug in the completed to-dos filter. Tested on 0.4.0 and upgraded to 0.7.2 — same behaviour.

When I run basecamp todos list -p -l --status completed --all, the command returns zero to-dos even on lists where every task is completed. The --completed shorthand behaves the same way. On mixed lists, it returns the pending ones instead of the completed ones.

I dug into it with the raw API and the cause is clear: api get ".../todos.json?completed=true" returns the completed to-dos correctly, but api get ".../todos.json?status=completed" returns empty. It looks like the SDK is sending ?status=completed while the Basecamp 3 API only recognises ?completed=true, so the param is ignored and the API falls back to the default (active) view.

Environment: basecamp 0.7.2 (installed via scoop), Windows 11, Git Bash.

Two bonus observations I ran into along the way:

1. messages list and messages show don't include the comments_count field, even though the raw API returns it. Anyone who wants to know which messages have comments has to run comments list one by one.

2. In Git Bash on Windows, basecamp api get "/buckets/..." without a query string gets its path rewritten by MSYS to C:/Program Files/Git/buckets/... and the call fails. Adding any query string avoids it.

The api get ?completed=true workaround works, but any automation that relies on the typed CLI to audit completed work is silently reporting zero.

Thanks.

[robzolkos]

Thanks for the thorough report — your diagnosis is spot on. 🙏

Primary bug (--status completed filter): confirmed, and already fixed on main by #456. In 0.7.2 the CLI sent ?status=completed, which the BC3 API ignores (it only recognises ?completed=true for completion; status= is for archived/trashed lifecycle only), so the API fell back to the default active view and the client-side filter discarded everything — yielding zero to-dos. #456 now maps --status completed / --completed to completed=true, with regression tests covering both single-list and cross-list paths.

The fix hasn't landed in a release yet (0.7.2 predates it). It'll be in the next published version; until then your api get "...?completed=true" workaround is the way to go.

Bonus observation 1 (comments_count missing from messages): correct — the SDK's Message model doesn't decode that field. I've opened an issue on the SDK repo to track it: basecamp/basecamp-sdk#353.

Bonus observation 2 (Git Bash rewriting /buckets/...): that's MSYS2/Git Bash POSIX path conversion, not a CLI bug — the argument is rewritten before the CLI ever sees it. Workarounds: MSYS_NO_PATHCONV=1 basecamp api get "/buckets/..." or a leading double-slash: //buckets/....

Closing this out since the primary bug is resolved on main and the comments_count observation is being tracked in the SDK. Thanks again!