`todos show --json` omits several fields present in the raw API (completion_subscribers, due_on, starts_on, description_attachments, …)

[vmpn]

Summary

basecamp todos show <id> --json returns a data object with fewer fields than the underlying Basecamp 3 API endpoint (GET /buckets/{bucket}/todos/{id}.json), making the CLI output an incomplete view of a to-do.

CLI version

basecamp 0.7.2

Reproduction

ID=<some-todo-id>
PROJECT=<project-id>
BUCKET=<bucket-id>

# Fields surfaced by the CLI:
basecamp todos show "$ID" --in "$PROJECT" --json --jq '.data | keys'

# Fields the API actually returns:
basecamp api get "/buckets/$BUCKET/todos/$ID.json" --agent | jq 'keys'

Observed difference

Data-carrying fields present in the raw API but absent from todos show:

• completion_subscribers — the "When done, notify…" recipients shown in the web UI
• due_on — due date
• starts_on — start date
• description_attachments — file attachments embedded in the description
• comments_count — comment count on the to-do
• boosts_count — boost (reaction) count

A few hypermedia fields (completion_url, comments_url, boosts_url, subscription_url) are also absent — likely intentional, mentioning for completeness.

Impact

The missing fields aren't obviously absent — the call returns ok: true and a data object that looks complete. Automated callers (scripts, AI agents, downstream tooling) querying those fields via --jq get back null or [] with no way to distinguish "field omitted by the CLI" from "field genuinely empty on the server". For interactive use this is usually fine because the user can cross-check in the web UI, but for non-interactive callers it can lead to acting on incomplete information.

Workaround

Use basecamp api get "/buckets/<bucket>/todos/<id>.json" --agent and parse with jq directly.

---

Created with assistance of AI agent with human review.

[robzolkos]

Validated. todos show --json marshals the SDK's basecamp.Todo struct verbatim (the CLI does no field filtering of its own), so the surface is exactly what that struct decodes. Breaking the reported fields down:

Genuinely missing from the SDK Todo struct (never appear, regardless of server value):

• completion_subscribers
• description_attachments
• comments_count

Present but tagged omitempty (they do appear when set — so these three are not truly missing):

• due_on, starts_on, boosts_count — omitted only when the todo has no due/start date or zero boosts, which is likely why they were absent from your sample's .data | keys.

The fix belongs in the SDK model, not CLI code (the CLI marshals the struct directly, per our SDK-first / "andon cord" policy). Opened basecamp/basecamp-sdk#355 to add the three genuinely-missing fields, with a secondary note about reconsidering omitempty on due_on/starts_on/boosts_count for non-interactive callers.

Tagging this sdk-update-required — once the SDK lands the fields, a make bump-sdk will surface them here automatically. Thanks for the detailed report.

[jeremy]

Handoff: SDK side landed — CLI now just needs an SDK bump

The last missing field, description_attachments, is now modeled in the SDK: basecamp-sdk#400 (merged fac35dfa, 2026-07-23). The Go SDK exposes it on basecamp.Todo:

DescriptionAttachments []RichTextAttachment `json:"description_attachments"`
// RichTextAttachment: ID, SGID, Filename, ContentType, ByteSize, DownloadURL,
//                     Width *int32, Height *int32, Previewable, PreviewURL, ThumbnailURL

It has no omitempty, so it marshals as [] (empty) or a populated array, and Width/Height are *int32 that round-trip null faithfully.

Remaining CLI work

1. Bump the basecamp-sdk dependency to a release/commit that includes Send combined CLI and SDK versions in API user agent #400 (fac35dfa).
2. Confirm todos show --json now emits description_attachments (if the command marshals the SDK Todo struct directly, the bump alone surfaces it — verify no CLI-side field allowlist/projection drops it).
3. Add/refresh a snapshot or test asserting the field is present.

That closes this issue — the other five fields (completion_subscribers, due_on, starts_on, …) were wired earlier in CLI #552; description_attachments was the only one still gated on the SDK.

Tracked SDK follow-up (unrelated to this issue): the same *_attachments arrays on ten other rich-text resources — basecamp-sdk#405.

[jeremy]

Fixed on main (unreleased — the latest published CLI is v0.7.2, which predates the fix). todos show emits the SDK Todo object directly, so once the SDK model carried these fields they began surfacing in --json output.

Provenance chain:

• SDK Fix update detection for pseudo-version builds #375 added completion_subscribers and comments_count.
• SDK Send combined CLI and SDK versions in API user agent #400 added description_attachments.
• CLI Bump SDK to 81660dc1 and surface BC5 forward-compat fields #552 absorbed the earlier field set; CLI Expose client visibility at create time (Fixes #457) #554's SDK bump absorbed Send combined CLI and SDK versions in API user agent #400 (main now rides pin a98f52fd3ddd).
• due_on, starts_on, and boosts_count already existed with omitempty and surface when non-empty.

Regression coverage added in #564 (TestTodosShowJSONSurfacesSDKFields), which serves a fully-populated todo and asserts the presence and values of all six reported fields, so a future SDK bump can't silently drop them.

Closing as fixed on main; ships in the next release.