Summary
The CLI doesn't expose Basecamp's visible_to_clients flag on messages create, cards create, or other commands that produce "recordings." Posts default to visible_to_clients: false, so any client invited to the project can't see them — even if they're @-mentioned and subscribed.
This makes the CLI difficult to use for agent-driven, client-facing communication in client projects, which seems like a target use case for the tool given the "agent first, agent native" framing.
Why it matters
Use case: an AI agent (Claude Code, in our case) drafts and posts a series of discovery questions to a client's Basecamp project on the user's behalf. The client is invited as a Client. The agent uses --subscribe "Client Name" to wire up notifications and [@Name](mention:SGID) for in-body mentions.
Everything looks right to the team-side user — messages are posted, mentions render with avatar pills, subscriptions are set. But the client can't see any of it because every post is silently team-only by default.
Current behavior
basecamp messages create "Question for client" "Body..." \
--message-board <id> --account <id> --project <id> \
--subscribe "Client Name"
Posts the message with visible_to_clients: false. The client never sees it. There's no flag, prompt, or warning that this is the default.
Workaround
The BC3 API has a dedicated client_visibility endpoint that the CLI doesn't surface:
PUT https://3.basecampapi.com/{account_id}/buckets/{project_id}/recordings/{recording_id}/client_visibility.json
Body: {"visible_to_clients": true}We're calling this directly via the OAuth token from basecamp auth token for each post we want a client to see. It works, but it's a separate round-trip per recording and bypasses the CLI's nice envelope/breadcrumbs/JSON conventions.
Suggested UX
Two options, in order of preference:
1. Add a --visible-to-clients (or --visible) flag to create/update commands that produce recordings. Applies to at least: messages create, messages update, cards create, cards update, comment (creating comments), todos create. Defaults to false to match API default; flip with --visible-to-clients for client-facing posts.
basecamp messages create "Title" "Body" --message-board <id> --visible-to-clients
basecamp cards create "Title" --column <id> --visible-to-clients
2. Surface a top-level basecamp visibility command (or under recordings) that mirrors the API endpoint, for batch toggling on already-created recordings:
basecamp visibility set <recording-id> --to clients
basecamp visibility set <recording-id> --to team
Either would be useful. Option 1 catches the issue at create time, which is where it usually matters. Option 2 is helpful for existing-recording cleanup and would have helped us recover from the team-only default after the fact.
Environment
- CLI:
basecamp version 0.7.2
- OS: Windows 11 (also tested on macOS — same behavior)
- Auth: OAuth 2.1 standard flow, no custom client credentials
- Project: client-enabled (
clients_enabled: true); client invited and confirmed pingable: true
Related
- API reference for the field on
Recording: documented behavior matches.
- The
cards columns response shows visible_to_clients per column, suggesting this concept is wired throughout the app and just needs surfacing.
Happy to test a PR or beta build if it'd help.
Summary
The CLI doesn't expose Basecamp's
visible_to_clientsflag onmessages create,cards create, or other commands that produce "recordings." Posts default tovisible_to_clients: false, so any client invited to the project can't see them — even if they're @-mentioned and subscribed.This makes the CLI difficult to use for agent-driven, client-facing communication in client projects, which seems like a target use case for the tool given the "agent first, agent native" framing.
Why it matters
Use case: an AI agent (Claude Code, in our case) drafts and posts a series of discovery questions to a client's Basecamp project on the user's behalf. The client is invited as a Client. The agent uses
--subscribe "Client Name"to wire up notifications and[@Name](mention:SGID)for in-body mentions.Everything looks right to the team-side user — messages are posted, mentions render with avatar pills, subscriptions are set. But the client can't see any of it because every post is silently team-only by default.
Current behavior
Posts the message with
visible_to_clients: false. The client never sees it. There's no flag, prompt, or warning that this is the default.Workaround
The BC3 API has a dedicated
client_visibilityendpoint that the CLI doesn't surface:PUT https://3.basecampapi.com/{account_id}/buckets/{project_id}/recordings/{recording_id}/client_visibility.json Body: {"visible_to_clients": true}We're calling this directly via the OAuth token from
basecamp auth tokenfor each post we want a client to see. It works, but it's a separate round-trip per recording and bypasses the CLI's nice envelope/breadcrumbs/JSON conventions.Suggested UX
Two options, in order of preference:
1. Add a
--visible-to-clients(or--visible) flag to create/update commands that produce recordings. Applies to at least:messages create,messages update,cards create,cards update,comment(creating comments),todos create. Defaults tofalseto match API default; flip with--visible-to-clientsfor client-facing posts.2. Surface a top-level
basecamp visibilitycommand (or underrecordings) that mirrors the API endpoint, for batch toggling on already-created recordings:Either would be useful. Option 1 catches the issue at create time, which is where it usually matters. Option 2 is helpful for existing-recording cleanup and would have helped us recover from the team-only default after the fact.
Environment
basecamp version 0.7.2clients_enabled: true); client invited and confirmedpingable: trueRelated
Recording: documented behavior matches.cards columnsresponse showsvisible_to_clientsper column, suggesting this concept is wired throughout the app and just needs surfacing.Happy to test a PR or beta build if it'd help.