basecamp · git:20260910.771fc91 · 2026-09-10 · sha256 c673778a8040908c
basecamp git:20260910.771fc91A
Immutable. This exact content is served forever at /api/v1/blob/c673778a8040908c.
---
name: basecamp
description: |
Interact with Basecamp via the Basecamp CLI. Full API coverage: projects, todos, cards,
messages, files, schedule, check-ins, timeline, recordings, templates, webhooks,
subscriptions, lineup, chat, pings, gauges, assignments, notifications, bookmarks,
bubble-up, drafts, notes, calendars, and accounts.
Use for ANY Basecamp question or action.
triggers:
# Direct invocations
- basecamp
- /basecamp
# Resource actions
- basecamp todos
- basecamp project
- basecamp cards
- basecamp chat
- basecamp campfire
- basecamp messages
- basecamp file
- basecamp document
- basecamp bookmarks
- basecamp bubble-up
- basecamp drafts
- basecamp notes
- basecamp calendars
- basecamp schedule
- basecamp checkin
- basecamp check-in
- basecamp timeline
- basecamp template
- basecamp webhook
- basecamp gauge
- basecamp assignment
- basecamp notification
- basecamp account
# Common actions
- link to basecamp
- track in basecamp
- post to basecamp
- comment on basecamp
- complete todo
- mark done
- create todo
- move card
- download file
# Search and discovery
- search basecamp
- find in basecamp
- look up basecamp
- check basecamp
- list basecamp
- show basecamp
- get from basecamp
- fetch from basecamp
# Questions
- can I basecamp
- how do I basecamp
- what's in basecamp
- what basecamp
- does basecamp
# My work
- my todos
- my tasks
- my schedule
- my basecamp
- assigned to me
- my assignments
- my notifications
- overdue todos
- upcoming events
- project gauge
- project progress
# URLs
- 3.basecamp.com
- basecampapi.com
- https://3.basecamp.com/
invocable: true
argument-hint: "[action] [args...]"
---
# /basecamp - Basecamp Workflow Command
Full CLI coverage: 189 tracked in-scope endpoints across todos, cards, messages, files, schedule, check-ins, timeline, recordings, templates, webhooks, subscriptions, lineup, chat, pings, gauges, assignments, notifications, and accounts.
## Agent Invariants
**MUST follow these rules:**
1. **Choose the right output mode** — `--jq` when you need to filter/extract data; `--json` for full JSON; `--md` when presenting results to a human (see Output Modes below). **Never pipe to external `jq` — use `--jq` instead.**
2. **Parse URLs first** with `basecamp url parse "<url>"` to extract IDs
3. **Comments are flat** - reply to parent recording, not to comments
4. **Check context** via `.basecamp/config.json` before assuming project
5. **Content fields accept Markdown and @mentions** — message body and comment content accept Markdown syntax; the CLI converts to HTML automatically. Use Markdown formatting (lists, bold, links, code blocks, tables) for rich content. Four mention syntaxes are available (prefer deterministic for agents):
- **`[@Name](mention:SGID)`** — zero API calls, embeds SGID directly (preferred for agents)
- **`[@Name](person:ID)`** — one API call, resolves person ID to SGID via pingable set
- **`@sgid:VALUE`** — inline SGID embed for pipeline composability
- **`@Name` / `@First.Last`** — fuzzy name resolution (may be ambiguous)
For todos, documents, and cards, content is sent as-is — use plain text or HTML directly.
**Table boundary:** GFM tables round-trip: they render in message/comment
bodies, display converts them back to pipe tables, and the TUI in-place
editors open simple grids for editing. Only **complex** tables — merged
cells (colspan/rowspan), captions, extra header rows, nested tables,
attachments/images or block content inside cells, multi-paragraph or
multi-line cells, or a table inside a blockquote or list — refuse to open,
since a GFM pipe table can't represent those shapes (edit them on Basecamp
web, or replace the
whole field via `messages update` / `comments update` / `todos update
--description`, which take fresh content and are unaffected). Complex
tables still **display** best-effort, flattened to a plain grid.
**Multiline / non-ASCII content:** do not rely on bash ANSI-C quoting (`$'...\n...'`) — it is a bash/zsh extension. Under a POSIX `/bin/sh` (dash, busybox-ash, common in sandboxes) the `$` is passed through literally and posts a stray leading `$`, and `\n` stays a literal backslash-n. Pipe the content via stdin instead, using `-` as the content argument:
```bash
printf '%s\n' '海报 mockup 方向稿：' '' '<bc-attachment ...>' | basecamp comments create <recording_id> - --in <project> --json
```
`-` means "read from stdin" on every content input: content-kind positionals
(`comments create/update`, `messages create [body]`, `cards create [body]`,
`todos create`, `docs documents create [content]`, `chat post/update`, `boost create`,
`checkins answer create/update`, `notes set`) and content flags (`--data` on
`api post/put`, `--body`, `--content`, `--description`, `--comment` on
`todos sweep`, `--file` on `notes set`). Each command's `--agent` help lists
its stdin inputs. Rules:
- A pipe is **never consumed implicitly** — without `-` it is ignored (or, where
content is required and missing, the error teaches `-`).
- Only one input can read stdin per invocation.
- A literal `-` anywhere else (a title, a name, a path) **errors when stdin is
piped**. Escape a positional after the `--` separator
(`basecamp projects create -- -`); a flag value has no in-line escape — run
the command without piped stdin. `basecamp help` and shell completion are
exempt: they write nothing to Basecamp, and completion legitimately
receives `-` as the word being completed.
- `-` with nothing piped (interactive TTY) errors immediately instead of
hanging; use a pipe, a heredoc (`basecamp comments create <id> - <<'EOF'`),
or `--edit` where offered.
- Trailing newlines are trimmed from stdin content, so `printf 'x\n' | ... -`
posts `x` (this keeps `boost create -` inside its 16-rune limit).
- Universal `-` support (and the stray-`-` guard) shipped in **v0.10.0**. Older
CLIs do not support it consistently: `comments create/update` read stdin,
while unsupported inputs may treat `-` as literal content or fail. For
example, `messages create "Title" -` posts a body of `-`, which Markdown
renders as an empty bullet list. When the CLI version is unknown, check
`basecamp --version` first, or pass the content portably as
`"$(cat file.md)"` and verify the posted `content` when it matters.
6. **Project scope is mandatory for most commands** — via `--in <project>` or `.basecamp/config.json`. Cross-project exceptions: `basecamp reports assigned` for assigned work, `basecamp assignments` for structured assignment views, `basecamp reports overdue` for overdue todos, `basecamp reports schedule` for upcoming schedule across all projects, `basecamp recordings <type>` for browsing by type, `basecamp notifications` for notifications, `basecamp gauges list` for account-wide gauges, and the seven list commands covered in item 7.
7. **Account-wide listing.** `basecamp todos list --all-projects --json` lists across every project; the same flag does the same on `cards list`, `messages list`, `comments list`, `files list`, `forwards list`, and `checkins answers`. It overrides a configured project, and with no project in scope those commands already list account-wide rather than prompting. Flags that name something inside a single project are rejected there rather than silently ignored.
Account-wide listings return **the first 100 items by default** — account-wide "all" is the whole account, not one project's worth. Use `--limit N` to raise the cap (it walks pages until N are collected) or `--all` for everything. `--page N` fetches exactly one page, but only on the paginated listings.
The two overdue variants — `basecamp todos list --all-projects --overdue` and `basecamp cards list --all-projects --overdue` — come from unpaginated endpoints. They accept `--limit` and `--all` but **reject `--page`**, so do not generate `--page` against them.
### Output Modes
**Choosing a mode:**
| Goal | Flag | Format |
|------|------|--------|
| Filter/extract JSON data | `--jq '<expr>'` | Built-in jq filter (no external jq needed). Implies `--json`; filter runs on the envelope. |
| Filter in agent mode | `--agent --jq '<expr>'` | Filter runs on data-only payload (no envelope), matching `--agent` contract. |
| Full JSON output | `--json` | JSON envelope: `{ok, data, summary, breadcrumbs, meta}`; errors: `{ok:false, error, code, retryable, hint, meta}` |
| Show results to a user | `--md` / `-m` | GFM tables, task lists, structured Markdown |
| Automation / scripting | `--agent` | Success: raw JSON data (no envelope); errors: `{ok:false,...}` object; no interactive prompts |
Always pass `--json` or `--md` explicitly — auto-detection depends on config and may not produce the format you expect. Use `--md` when composing reports, summarizing data, or displaying results inline. `--agent` is for headless integration scripts.
**Avoiding interactive prompts.** The flags `--agent`/`--json`/`--quiet`/`--ids-only`/`--count` and the environment variable `BASECAMP_NONINTERACTIVE=1` suppress interactive selection prompts. `--md` does **not** — if a required target is ambiguous (e.g. a project with multiple todosets and no `--todoset`), and the CLI is attached to a terminal, it will show a blocking picker. When you need Markdown output *and* no prompts, either pass the flag that names whatever is ambiguous (`--todoset <id>` for the todoset case above, or `--in <project>` / `--list <id>` when the project or list is ambiguous) or set `BASECAMP_NONINTERACTIVE=1` in the environment. `BASECAMP_NONINTERACTIVE` disables all prompts (they become actionable errors instead) without changing the output format — an escape hatch for agents running under a PTY.
**Other modes:** `--quiet` (success: raw JSON, no envelope; errors: `{ok:false,...}`), `--ids-only`, `--count`, `--stats` (session statistics), `--styled` (force ANSI), `-v` / `-vv` (verbose/trace), `--jq '<expr>'` (built-in jq filter — see below).
### CLI Introspection
Navigate unfamiliar commands with `--agent --help` — returns structured JSON describing any command:
```bash
basecamp todos --agent --help
```
```json
{"command":"todos","path":"basecamp todos","short":"...","long":"...","usage":"...","notes":["..."],
"subcommands":[{"name":"sweep","short":"...","path":"basecamp todos sweep"}],
"flags":[{"name":"assignee","type":"string","default":"","usage":"..."}],
"inherited_flags":[{"name":"json","shorthand":"j","type":"bool","default":"false","usage":"..."}]}
```
Walk the tree: start at `basecamp --agent --help` for top-level commands, then drill into any subcommand. Commands carry domain-specific agent hints (e.g., "`--assignee` filters the account-wide listing only; within a project, fetch all and filter client-side").
### Pagination
```bash
basecamp <cmd> --limit 50 # Cap results (default varies by resource)
basecamp <cmd> --all # Fetch all (may be slow for large datasets)
basecamp <cmd> --page 1 # First page only, no auto-pagination
```
`--all` and `--limit` are mutually exclusive. `--page` cannot combine with either.
### Smart Defaults
- `--assignee me` resolves to current user
- `--due tomorrow` / `--due +3` / `--due "next week"` — natural date parsing, **when setting a due date** (`todos create`, `todos update`, `cards create`, and so on)
- `--due` on a **listing** is a different flag and does not take dates: it accepts only `with`, `without`, or `overdue`, and only account-wide. `basecamp todos list --due tomorrow` is rejected. For date-based listing use `--overdue`, `--no-due-date`, or `basecamp assignments due <scope>`
- Project from `.basecamp/config.json` if `--in` not specified
- Multiple identities use named profiles: `basecamp profile create <name>`, then select one with global `--profile <name>` or `BASECAMP_PROFILE=<name>`.
## Quick Reference
> **Note:** Most queries require project scope (via `--in <project>` or `.basecamp/config.json`). Cross-project exceptions: `basecamp reports assigned`, `basecamp assignments`, `basecamp reports overdue`, `basecamp reports schedule`, `basecamp recordings <type>`, `basecamp notifications`, `basecamp gauges list`.
>
> Seven list commands also list account-wide: `basecamp todos list --all-projects --json`, and likewise `cards list`, `messages list`, `comments list`, `files list`, `forwards list`, and `checkins answers`.
| Task | Command |
|------|---------|
| List projects | `basecamp projects list --json` |
| My todos (in project) | `basecamp todos list --assignee me --in <project> --json` |
| My todos (cross-project) | `basecamp reports assigned --json` (defaults to "me") |
| My schedule (cross-project) | `basecamp reports schedule --json` (upcoming events across all projects) |
| All todos (cross-project) | `basecamp todos list --all-projects --json` (grouped by project) |
| Overdue todos (in project) | `basecamp todos list --overdue --in <project> --json` |
| Overdue todos (cross-project) | `basecamp todos list --all-projects --overdue --json` (flat, oldest first) or `basecamp reports overdue --json` (bucketed by lateness) |
| All cards (cross-project) | `basecamp cards list --all-projects --json` (grouped by project) |
| Someone's todos (cross-project) | `basecamp todos list --all-projects --assignee "Ann" --json` (server-side filter) |
| Two people's todos (cross-project) | `basecamp todos list --all-projects --assignee ann --assignee bob --json` (matches either) |
| Someone's cards (cross-project) | `basecamp cards list --all-projects --assignee "Ann" --json` |
| Todos with no due date set (cross-project) | `basecamp todos list --all-projects --due without --json` |
| My bookmarks | `basecamp bookmarks list --json` |
| Bookmark something | `basecamp bookmarks add <id-or-url> --json` |
| Is it bookmarked? | `basecamp bookmarks check <id-or-url> --json` (always exits 0) |
| Bubble a recording up | `basecamp bubble-up add <id-or-url> --json` |
| Schedule a bubble-up | `basecamp bubble-up add <id-or-url> --at tomorrow --json` |
| Pop a bubble-up | `basecamp bubble-up remove <id-or-url> --json` |
| My unpublished drafts | `basecamp drafts list --json` |
| Read my personal note | `basecamp notes show --json` |
| Replace my personal note | `basecamp notes set "<content>" --json` |
| Check-ins I owe answers to | `basecamp checkins reminders --json` |
| Add to Up Next | `basecamp assignments prioritize <id> --json` |
| Recolor a calendar | `basecamp calendars update <id-or-url> --color blue --json` |
| Todo outside any list | `basecamp todos create "<content>" --loose --in <project> --json` |
| Assign todo | `basecamp assign <id> [id...] --to <person> --in <project> --json` |
| Assign card | `basecamp assign <id> [id...] --card --to <person> --in <project> --json` |
| Assign card step | `basecamp assign <id> [id...] --step --to <person> --in <project> --json` |
| Create todo | `basecamp todos create "Task" --in <project> --list <list> --json` |
| Create todolist | `basecamp todolists create "Name" --in <project> --json` |
| Complete todo | `basecamp todos complete <id> --json` |
| List cards | `basecamp cards list --in <project> --json` |
| Create card | `basecamp cards create "Title" --in <project> --json` |
| Complete card | `basecamp cards done <id|url> --in <project> --json` |
| Move card | `basecamp cards move <id> --to <column> [--position N] --in <project> --json` |
| Move card to on-hold | `basecamp cards move <id> --on-hold --in <project> --json` |
| Move card to another project | `basecamp cards move <id> --to-wormhole <wormhole_id> --in <project> --json` (async teleport) |
| Post message | `basecamp messages create "Title" "Body" --in <project> --json` |
| Post with @mention | `basecamp messages create "Title" "Hey @First.Last, ..." --in <project> --json` |
| Post silently | `basecamp messages create "Title" "Body" --no-subscribe --in <project> --json` |
| Post to chat | `basecamp chat post "Message" --in <project> --json` |
| List pings | `basecamp notifications --json --jq '.data.reads[]? | select(.section == "pings")'` |
| Read ping thread | `basecamp api get "/buckets/<circle_id>/chats/<chat_id>/lines.json" --agent` |
| Post to ping thread | `basecamp api post "/buckets/<circle_id>/chats/<chat_id>/lines.json" --data '{"content":"<p>message</p>"}' --json` |
| Add comment | `basecamp comments create <recording_id> "Text" --in <project> --json` |
| Inspect comment / reply atoms | `basecamp comments show <url> --json` → `reply_target` + `mention` in `.data` |
| List attachments | `basecamp attachments list <id\|url> --json` |
| Download attachments | `basecamp attachments download <id> --out /tmp/` |
| Show + download | `basecamp todos show <id> --download-attachments --json` |
| Stream attachment to stdout | `basecamp attachments download <id> --file <name> --out -` |
| Change history for an item | `basecamp events <id\|url> --json` (when a card moved columns, when a todo was completed) |
| Search | `basecamp search "query" --json` |
| Parse URL | `basecamp url parse "<url>" --json` |
| Upload file | `basecamp files uploads create <file> [--vault <folder_id>] --in <project> --json` |
| Download file | `basecamp files download <id> --in <project>` |
| Stream file to stdout | `basecamp files download <id> --out - --in <project>` |
| Download storage URL | `basecamp files download "https://storage.3.basecamp.com/.../download/report.pdf"` |
| My assignments | `basecamp assignments --json` (priorities + non-priorities) |
| Overdue assignments | `basecamp assignments due overdue --json` |
| Completed assignments | `basecamp assignments completed --json` |
| Notifications | `basecamp notifications --json` |
| Mark notification read | `basecamp notifications read <id> --json` |
| All bubble-ups (BC5) | `basecamp notifications bubbleups --json` |
| Gauges (account-wide) | `basecamp gauges list --json` |
| Gauge needles | `basecamp gauges needles --in <project> --json` |
| Create needle | `basecamp gauges create --position 75 --color green --in <project> --json` |
| Account details | `basecamp accounts show --json` |
## URL Parsing
**Parse URLs before acting on them — unless you're handing the URL to a command
that accepts a URL directly** (`show`, `comments show`, `comments thread`,
`attachments list`/`attachments download`), which extract the IDs for you. Only `comments show` and
`comments thread` verify the URL's host and account before any fetch. For other
URL-accepting commands, only pass URLs from a trusted Basecamp host:
`basecamp url parse` extracts IDs but does **not** validate the URL's origin, so
parsing an attacker-controlled path yields trusted-looking IDs.
```bash
basecamp url parse "https://3.basecamp.com/2914079/buckets/41746046/messages/9478142982#__recording_9488783598" --json
```
Returns: `account_id`, `project_id`, `type`, `recording_id`, `comment_id` (from fragment).
**URL patterns:**
- `/buckets/27/messages/123` - Message 123 in project 27
- `/buckets/27/messages/123#__recording_456` - Comment 456 on message 123
- `/buckets/27/card_tables/cards/789` - Card 789
- `/buckets/27/card_tables/columns/456` - Column 456 (for creating cards)
- `/buckets/27/todos/101` - Todo 101
- `/buckets/27/uploads/202` - Upload/file 202
- `/buckets/27/documents/303` - Document 303
- `/buckets/27/schedule_entries/404` - Schedule entry 404
**Replying to comments:**
```bash
# Comments are flat - reply to the parent recording_id, not the comment_id
basecamp url parse "https://...messages/123#__recording_456" --json
# Returns recording_id: 123 (parent), comment_id: 456 (fragment) - comment on 123, not 456
basecamp comments create 123 "Reply" --in <project>
# Or get the whole reply-ready context deterministically in one call:
basecamp comments thread "https://...messages/123#__recording_456" --json
# .data.reply_target.recording_id → where to post the reply
# .data.reply_target.account_id → the account that reply belongs to (build a fully-qualified command)
# .data.focus.author.mention.syntax → paste-ready [@Name](mention:SGID)
# .data.comments → surrounding discussion (default window of 41)
# --all returns every fetched comment; --window N sets the window size
# When the account came from the URL (none configured), the reply breadcrumb carries --account
```
## Decision Trees
### Finding Content
```
Need to find something?
├── Know the type + project? → basecamp <type> list --in <project> --json
│ (some groups have default list behavior; use --agent --help if unsure)
├── My assigned work? → basecamp assignments --json (priorities + non-priorities)
│ Or: basecamp reports assigned --json (traditional view, defaults to "me")
├── My overdue assignments? → basecamp assignments due overdue --json
├── My notifications? → basecamp notifications --json
├── Upcoming schedule? → basecamp reports schedule --json (cross-project)
├── Overdue across projects? → basecamp reports overdue --json
├── Browse by type cross-project? → basecamp recordings <type> --json
│ (types: todos, messages, documents, comments, cards, uploads)
│ Note: Defaults to active status; use --status archived for archived items
│ ⚠ No assignee data — cannot filter by person; use reports assigned instead
├── Full-text search? → basecamp search "query" --json
├── Have a comment URL, or a notification link targeting a comment? → basecamp comments thread <url> --json
└── Have a URL? → basecamp url parse "<url>" --json
```
### Modifying Content
```
Want to change something?
├── Have URL? → basecamp url parse "<url>" → use extracted IDs
├── Have ID? → basecamp <resource> update <id> --field value
├── Change status? → basecamp recordings trash|archive|restore <id>
├── Complete todo? → basecamp todos complete <id>
├── Complete card? → basecamp cards done <id|url> --in <project>
└── Reply to a comment? → basecamp comments show <url> --jq '.data | {reply_target, mention}'
(one call, cheap atoms — the mention is machine-only, so use --jq/--json, not plain show)
or basecamp comments thread <url> when you need the surrounding discussion;
then basecamp comments create <reply_target.recording_id> <text>
```
## Common Workflows
### Link Code to Basecamp Todo
```bash
# Get commit info and comment on todo (use printf %q for safe quoting)
COMMIT=$(git rev-parse --short HEAD)
MSG=$(git log -1 --format=%s)
basecamp comments create <todo_id> "Commit $COMMIT: $(printf '%s' "$MSG")" --in <project>
# Complete when done
basecamp todos complete <todo_id>
```
### Track PR in Basecamp
```bash
# Create todo for PR work
basecamp todos create "Review PR #42" --in <project> --assignee me --due tomorrow
# When merged
basecamp todos complete <todo_id>
basecamp chat post "Merged PR #42" --in <project>
```
### Bulk Process Overdue Todos
```bash
# Preview overdue todos
basecamp todos sweep --overdue --dry-run --in <project>
# Complete all with comment
basecamp todos sweep --overdue --complete --comment "Cleaning up" --in <project>
```
### Mentioning people (preferred — deterministic)
```bash
# 1. Look up the person
basecamp people pingable --jq '.data[] | select(.name == "Jane Smith")'
# => {"id": 42000, "attachable_sgid": "BAh7CEkiCG...", "name": "Jane Smith"}
# 2. Use SGID in Markdown mention syntax (zero API calls during post)
basecamp comments create 123 "Hey [@Jane Smith](mention:BAh7CEkiCG...), check this" --in <project>
# Or use person ID (one lookup during post)
basecamp comments create 123 "Hey [@Jane Smith](person:42000), check this" --in <project>
```
### Mentioning people (interactive — may be ambiguous)
```bash
# Fuzzy matching: use @First.Last to reduce ambiguity
basecamp comments create <id> "@Jane.Smith, please review this" --in <project>
basecamp messages create "Update" "cc @Jane, @Alex" --in <project>
basecamp chat post "@Jane, done!" --in <project>
# Ambiguous names return an error with suggestions
# Use @First.Last for disambiguation
```
### Move Card Through Workflow
```bash
# List columns to get IDs
basecamp cards columns --in <project> --json
# Complete a card (moves it to the Done column automatically)
basecamp cards done <card_id> --in <project>
# Move card to column
basecamp cards move <card_id> --to <column_id> --in <project>
# Move card to specific position in column (1-indexed)
basecamp cards move <card_id> --to <column_id> --position 1 --in <project>
# Move card to on-hold section of its current column
basecamp cards move <card_id> --on-hold --in <project>
# Move card to on-hold section of a specific column (numeric ID)
basecamp cards move <card_id> --to <column_id> --on-hold --in <project>
# Move card to on-hold section of a named column (requires --card-table)
basecamp cards move <card_id> --to "Column Name" --on-hold --card-table <table_id> --in <project>
```
### Download File from Basecamp
```bash
basecamp files download <upload_id> --in <project> --out ./downloads
# Download attachment from a storage URL (no --in needed)
basecamp files download "https://storage.3.basecamp.com/123/blobs/abc/download/report.pdf"
# Stream to stdout (for piping)
basecamp files download <upload_id> --out - --in <project>
```
### Working with Attachments (Multimodal Agent Workflow)
Messages, todos, cards, and documents may contain images and file attachments
(mockups, screenshots, annotated designs). Show commands surface these as
field-scoped collections — `content_attachments` and/or `description_attachments`
— keyed by which rich-text attribute contained them. The notice field hints at
the download command.
**Step 1: Fetch the recording and check for attachments**
```bash
basecamp todos show <id> --json
# Response includes description_attachments when attachments are present
# Messages/documents use content_attachments; cards may have both
# The notice field hints: "3 attachment(s) — download: basecamp attachments download <id>"
```
**Step 2 (one-shot): Download attachments with the show command**
```bash
# --download-attachments fetches + downloads in one shot
basecamp todos show <id> --download-attachments --json
# content_attachments/description_attachments entries now include "path" pointing to local files
# Downloads to OS temp dir by default, or specify: --download-attachments /tmp/att
```
**Step 2 (two-step alternative): Download separately**
```bash
# Download all at once (shows progress on stderr)
basecamp attachments download <id> --out /tmp/attachments
```
**Step 3: View images with your native file-read tool**
For multimodal LLMs (Claude, Gemini), use your file-read tool on the `path`
from the response to view downloaded images directly — no browser needed.
This surfaces visual context (mockups, screenshots, annotated designs) that
is often the most important part of a Basecamp todo or message.
```bash
# Stream a single image to stdout for piping
basecamp attachments download <id> --file mockup.png --out -
# Select by index when names collide
basecamp attachments download <id> --index 2 --out -
```
**Key pattern:** When a show command response contains `content_attachments`
or `description_attachments`, always download and view them — visual context is
often more important than the text content. Use `--download-attachments` for
one-shot fetch+download, or follow the breadcrumb hint for two-step control.
## Resource Reference
### Projects
```bash
basecamp projects list --json # List all
basecamp projects show <id> --json # Show details
basecamp projects create "Name" --json # Create
basecamp projects update <id> --name "New" # Update
basecamp projects trash <id> # Move to trash (recoverable)
```
**Archiving a project:** the CLI does not have a dedicated archive command, but the
underlying status endpoint can be hit via raw API. Same path works for restoring
to active or moving to trashed.
```bash
basecamp api put "projects/<id>/status/archived" -d '{}' --json # Archive
basecamp api put "projects/<id>/status/active" -d '{}' --json # Unarchive
basecamp api put "projects/<id>/status/trashed" -d '{}' --json # Trash (same as `projects trash`)
```
Verify with `basecamp projects show <id> --jq '.data.status'`.
### Todos
```bash
basecamp todos list --in <project> --json # List in project
basecamp todos list --assignee me --in <project> # My todos
basecamp todos list --overdue --in <project> # Overdue only
basecamp todos list --status completed --in <project> # Completed
basecamp todos list --list <todolist_id> --in <project> # In specific list
basecamp todos create "Task" --in <project> --list <list> --assignee me --due tomorrow
basecamp todos complete <id> [id...] # Complete (multiple OK)
basecamp todos uncomplete <id> # Reopen
basecamp assign <id> [id...] --to <person> --in <project> # Assign to-do (multiple OK)
basecamp unassign <id> [id...] --from <person> --in <project> # Remove to-do assignee (multiple OK)
basecamp assign <id> [id...] --card --to <person> --in <project> # Assign card
basecamp unassign <id> [id...] --card --from <person> --in <project> # Remove card assignee
basecamp assign <id> [id...] --step --to <person> --in <project> # Assign card step
basecamp unassign <id> [id...] --step --from <person> --in <project> # Remove step assignee
basecamp todos position <id> --to 1 # Move to top
basecamp todos position <id> --to 1 --list <id|name|url> # Move to different list
basecamp todos sweep --overdue --complete --comment "Done" --in <project>
basecamp todos create "Task" --in <project> --list <list> --notify-on-completion "Jane,Bob" # Notify when done
basecamp todos update <id> --notify-on-completion "Jane" # Set who's notified on completion
basecamp todos update <id> --no-notify-on-completion # Clear completion notifications
```
**Flags:** `--assignee` (repeatable; server-side account-wide, client-side within a project; also on `cards list` account-wide, but not on messages), `--status` (completed/incomplete/archived/trashed), `--overdue`, `--list`, `--due` (**listing filter: `with`/`without`/`overdue` only, account-wide only** — not a date; see Smart Defaults), `--limit`, `--all`
**Completion subscribers** ("When done, notify…"): set with
`--notify-on-completion <names or IDs, comma-separated>` on `todos create` and
`todos update`; clear with `--no-notify-on-completion` on `todos update`.
Plain updates (title, due date, etc.) preserve existing completion subscribers.
**Todo Subtasks (checklist steps):** Basecamp to-do subtasks are stored as
`Kanban::Step` records, even when their parent is a normal `Todo`. The regular
`basecamp todos show` response may not include them; use
`basecamp recordings list --in <project> --type Kanban::Step` and filter by
`parent.id` to list/check subtasks for a todo.
```bash
# Create a subtask under a todo.
# Use the numeric project ID and todo ID in this card-style path.
basecamp api post /buckets/<project_id>/card_tables/cards/<parent_todo_id>/steps.json \
--data '{"title":"Subtask title"}' \
--json
# Read or edit a subtask
basecamp api get /buckets/<project_id>/card_tables/steps/<step_id>.json --json
basecamp api put /buckets/<project_id>/card_tables/steps/<step_id>.json \
--data '{"title":"Updated subtask title"}' \
--json
# List subtasks for a todo
PARENT_TODO_ID=<parent_todo_id> \
basecamp recordings list --in <project> --type Kanban::Step --all \
--jq '.data[] | select(.parent.id==(env.PARENT_TODO_ID | tonumber)) | {id,title,status,parent:.parent.id,url}'
# Assign or set a due date. Send only what you're changing — omitted fields are
# left alone. `assignee_ids` replaces the whole list, so name everyone who stays.
basecamp api put /buckets/<project_id>/card_tables/steps/<step_id>.json \
--data '{"assignee_ids":[<person_id>,<existing_person_id>],"due_on":"<YYYY-MM-DD>"}' \
--json
# Complete or reopen a subtask
basecamp api put /buckets/<project_id>/card_tables/steps/<step_id>/completions.json \
--data '{"completion":"on"}' \
--json
basecamp api put /buckets/<project_id>/card_tables/steps/<step_id>/completions.json \
--data '{"completion":"off"}' \
--json
# Trash a subtask from the todo UI by trashing the step record (Kanban::Step)
basecamp recordings trash <step_id> --in <project> --json
```
Key points: replace numeric placeholders such as `<project_id>`,
`<parent_todo_id>`, and `<person_id>` before running the examples. Bucket-scoped
API paths require a numeric project/bucket ID; `--in <project>` can still accept
a project name where CLI commands support name resolution. For creating todo
subtasks, Basecamp accepts the parent todo ID in the
`/buckets/<project_id>/card_tables/cards/<parent_todo_id>/steps.json` path. To
list subtasks under a todo, use
`basecamp recordings list --in <project> --type Kanban::Step` with the
`parent.id` filter shown above.
Completed subtasks have `completed: true` and a `completion` object with
`created_at` and `creator`. Open subtasks have `completed: false` and no
`completion` object. Trashed subtasks may still be readable directly with
`status: "trashed"` and `inherits_status: false`, but they no longer appear in
the todo UI.
In testing with todo-backed steps, these bucket-scoped direct `GET` requests
returned `not_found`:
`/buckets/<project_id>/card_tables/cards/<parent_todo_id>/steps.json`,
`/buckets/<project_id>/card_tables/cards/<parent_todo_id>.json`, and
`/buckets/<project_id>/todos/<parent_todo_id>/steps.json`. To inspect trashed
subtasks, add `--status trashed`; archived parents may require
`--status archived`.
**Raw step updates are partial.** `PUT .../card_tables/steps/<id>.json` leaves
every parameter you omit unchanged, so send only the fields you are changing.
Echoing back a `title` you did not mean to change is not merely redundant — it
reverts anyone who edited the title between your read and your write. To clear a
value, say so explicitly: `"due_on": null` clears the due date, `"assignee_ids":
[]` removes everyone. `assignee_ids` always replaces the whole list rather than
adding to it, so name every person who should remain assigned.
(This is bc3#12521. Before it, an omitted field *was* cleared and a title-less
update was rejected, which is why older guidance said to resend the title. Todo
subtasks and card steps share one endpoint and one contract — `PUT
card_tables/steps/:id` routes to the same controller for both.)
The generic
`basecamp assign <step_id> --step ...` command is intended for card steps and
may fail with `Bad Request` for todo-backed steps, so prefer `assignee_ids` on
the raw step update endpoint for todo subtasks.
### Todolists
Todolists are containers for todos. Create a todolist before adding todos.
```bash
basecamp todolists list --in <project> --json # List todolists
basecamp todolists show <id> --in <project> # Show details
basecamp todolists create "Name" --in <project> --json # Create
basecamp todolists create "Name" --description "Desc" --in <project>
basecamp todolists create "Name" --visible-to-clients --in <project> # Visible to clients
basecamp todolists update <id> --name "New" --in <project> # Update
basecamp todolists position <id> --to 1 # Reorder one list (1 = top)
basecamp todolists position <id> <id> <id> # Order incomplete lists, top→bottom
```
Bulk `position` sets the visible order in one command: pass incomplete lists from
the same todoset, top to bottom. It always places them at the top.
### Cards (Kanban)
**Note:** `--assignee` on `cards list` is **account-wide only** — pass `--all-projects` (or have no project in scope) and it becomes a real server-side filter. Within a single project cards have no assignee filter: fetch all and filter client-side. `--due with|without|overdue` is account-wide only on cards too. If a project has multiple card tables, you must specify `--card-table <id>`. When you get an "Ambiguous card table" error, the hint shows available table IDs and names.
```bash
basecamp cards list --in <project> --json # All cards
basecamp cards list --card-table <id> --in <project> # Specific table (required if multiple)
basecamp cards list --column <id> --in <project> # Cards in column
basecamp cards columns --in <project> --json # List columns (needs --card-table if multiple)
basecamp cards show <id> --in <project> # Card details
basecamp cards create "Title" "<p>Body</p>" --in <project> --column <id>
basecamp cards update <id> --title "New" --due tomorrow --assignee me
basecamp cards done <id|url> --in <project> # Move to the Done column automatically
basecamp cards move <id> --to <column_id> # Move to column (numeric ID)
basecamp cards move <id> --to "Done" --card-table <table_id> # Move by name (needs table)
basecamp cards move <id> --to "Done" --position 1 --card-table <table_id> # Move to position
basecamp cards move <id> --on-hold # Move to on-hold of current column
basecamp cards move <id> --to <column_id> --on-hold # Move to on-hold of target column
```
**Cross-project card move (wormholes):** the only way to move a card to another
project is to teleport it through a *wormhole* — a portal on the card table that
sends cards to a preconfigured column on another project's card table (max 4 per
table). The teleport is **asynchronous and mints a new card id**: after the move
is accepted, the server copies the card into the destination and deletes the
original, so the **original id 404s** — do not reuse it.
```bash
basecamp cards wormholes list --in <project> # Discover wormholes (id, destination, linked)
basecamp cards wormholes create --to-column <id|url> --in <project> # Link to a column on another table (≤4)
basecamp cards wormholes update <id> --to-column <id|url> --in <project>
basecamp cards wormholes delete <id> --in <project>
basecamp cards move <card_id> --to-wormhole <wormhole_id> --in <project> # Teleport (async)
basecamp cards move <card_id> --to-wormhole <destination_column_url> --in <project> # Match by destination column
```
`--to-wormhole` is mutually exclusive with `--to`/`--on-hold`/`--position`. Pass
a numeric wormhole id to route directly, or a destination-column URL to match it
against the source table's wormholes.
**Archived/trashed cards:** `cards list` only returns active cards. For archived or trashed cards, use `basecamp recordings cards --status archived --in <project>` or `--status trashed`.
**Identifying completed cards:** Cards in Done columns have `parent.type: "Kanban::DoneColumn"` and `completed: true`. Use this to identify completed cards that haven't been archived.
**When a card moved columns:** don't read `updated_at` — it changes on any
modification. Use the event history instead: `basecamp events <card_id> --json`
records an `adopted` event for every column move, and a card crossing into or
out of a Done column pairs that with `completed`/`uncompleted`. See
[Events](#events-change-history).
**Card Steps (checklists):**
```bash
basecamp cards steps <card_id> --in <project> # List steps
basecamp cards step create "Step" --card <id> --in <project>
basecamp cards step complete <step_id> --in <project>
basecamp cards step uncomplete <step_id>
```
**Column management:**
```bash
basecamp cards column show <id> --in <project>
basecamp cards column create "Name" --in <project>
basecamp cards column update <id> --title "New"
basecamp cards column move <id> --position 2
basecamp cards column color <id> --color blue
basecamp cards column on-hold <id> # Enable on-hold section
basecamp cards column watch <id> # Subscribe to column
```
### Messages
```bash
basecamp messages list --in <project> --json # List messages
basecamp messages show <id> --in <project> # Show message
basecamp messages create "Title" "Body" --in <project>
basecamp messages create "Draft" "WIP" --draft --in <project> # Create draft
basecamp messages publish <id> # Publish a draft
basecamp messages update <id> --title "New" --body "Updated"
basecamp messages pin <id> --in <project> # Pin to top
basecamp messages unpin <id> # Unpin
```
**Archived/trashed messages:** `messages list` only returns active messages. For archived or trashed messages, use `basecamp recordings messages --status archived --in <project>` or `--status trashed`.
**Flags:** `--draft` (create as draft), `--no-subscribe` (silent, no notifications), `--subscribe "people"` (comma-separated names, emails, IDs, or "me"; mutually exclusive with `--no-subscribe`), `--message-board <id>` (if multiple boards), `--visible-to-clients` (make visible to clients on the project; omit for the server default)
```bash
basecamp messages create "Bot update" "Done" --no-subscribe --in <project>
basecamp messages create "FYI" "Note" --subscribe "Alice,bob@x.com" --in <project>
basecamp messages create "For the client" "..." --visible-to-clients --in <project>
```
**Client visibility at create time:** `messages create`, `todolists create`,
`schedule create`, `checkins question create`, and `tools create` accept
`--visible-to-clients` to post a client-visible recording in one call (for
`tools create`, only chat and kanban_board tool types honor it — other types
inherit the project default). Omitting the flag uses the
server default, which is context-dependent: **team-only when you post as a team
member**, but a **client-authenticated caller always creates client-visible
records** (an explicit `--visible-to-clients=false` is overridden server-side for
client callers). Passing `--visible-to-clients` posts client-visible in every
case. To change visibility on an already-created recording, use
`recordings visibility <id> --visible`.
### Comments
```bash
basecamp comments list <recording_id> --in <project> --json
basecamp comments show <comment-id|comment-url> --json # Now returns reply_target + paste-ready mention (JSON)
basecamp comments thread <comment-id|comment-url> --json # Reply-ready: parent + focus + discussion + @mention
basecamp comments thread <comment-id> --all --json # Every fetched comment instead of a window
basecamp comments thread <comment-id> --window 11 --json # Focus-centered window of 11
basecamp comments create <recording_id> "Text" --in <project>
basecamp comments create <recording_id> "@Jane.Smith, looks good!" --in <project> # With @mention
basecamp comments update <id> "Updated" --in <project>
```
**Cheap atoms vs. deep context (choose by need):**
- `comments show <url> --jq '.data | {reply_target, mention}'` — one API call. Returns
`reply_target` (`recording_id` — where a reply is posted, comments are flat — plus
`account_id`) and a paste-ready author `mention` (JSON only; human output shows a reply
breadcrumb). Use this for the exact-comment reply atoms.
- `comments thread <url>` — two extra calls. Adds the full parent recording, the
surrounding discussion (windowed, truncation-honest), and focus attachments. Use this
when the surrounding discussion matters.
### Files & Documents
```bash
basecamp files list --in <project> --json # List all (folders, files, docs)
basecamp files list --vault <folder_id> --in <project> # List folder contents
basecamp files list --all-projects --json # Across every project (first 100)
basecamp files list --all-projects --limit 500 # Walk pages until 500 collected
basecamp files list --all-projects --page 2 # Exactly page 2
basecamp files list --all-projects --all # Every page (slow on big accounts)
basecamp files show <id> --in <project> # Show item (auto-detects type)
basecamp files versions <upload_id> --json # Every version of an uploaded file
basecamp files versions <upload_id> --limit 5 --json # Cap results (default: all)
basecamp files replace <upload_id> <file> # Replace the file, keep the ID/URL/comments
basecamp files replace <upload_id> <file> --description "v2 notes" # Also set a new description
basecamp files download <id> --in <project> # Download file
basecamp files download <id> --out ./dir # Download to specific dir
basecamp files download "https://storage.../download/f" # Download from storage URL
basecamp files uploads create <file> --in <project> # Upload file to root
basecamp files uploads create <file> --vault <folder_id> --in <project> # Upload to folder
basecamp files uploads create <file> --visible-to-clients --in <project> # Client-visible (root folder only)
basecamp files folder create "Folder" --in <project>
basecamp files doc create "Doc" "Body" --in <project>
basecamp files doc create "Draft" --draft --in <project>
basecamp files doc create "Notes" "..." --no-subscribe --in <project>
basecamp files doc create "For client" "..." --visible-to-clients --in <project> # Client-visible (root folder only)
basecamp files update <document_id> --title "New" --content "Updated"
basecamp files update <document_id> --title "New" --in <project> # Preserves existing document content
basecamp files update <document_id> --content "Updated" --in <project> # Preserves existing document title
```
**Document update semantics:** `basecamp files update <document_id>` is safe for partial updates in the CLI: when you pass only `--title` or only `--content`, the CLI first fetches the current document and preserves the untouched field.
**Client visibility at create time:** `doc create` and `uploads create` accept
`--visible-to-clients`, but the server only honors it in the project's **root
Docs & Files folder**. Targeting a nested folder (`--vault`/`--folder`) with the
flag is a hard error raised before anything is uploaded — a nested item inherits
its folder's visibility, and that can't be changed per-item afterward (the
visibility endpoint rejects nested docs/uploads). To make a nested item
client-visible, create it in the root folder, or change the eligible top-level
ancestor that controls the folder's visibility first. Omitting the flag uses the
server default; as with Messages, a **client-authenticated caller always creates
client-visible records** regardless. `recordings visibility` is **not** a
remediation for nested docs/uploads.
**Upload versions:** replacing a file keeps the earlier copies under the same
upload ID, so `basecamp files versions <upload_id>` is how you see the history of
one file. A file that was never replaced returns its single current version, not
an error. Only `--page 1` is accepted; use `--all` to walk every page.
`basecamp files replace <upload_id> <file>` publishes a new version in place —
the upload keeps its ID, URL and comments, nobody is notified, and the
description carries forward unless `--description` is given. Use it instead of
`uploads create` when shipping a new build of the same file.
**Subcommands:** `folders`, `uploads`, `documents` (each with pagination flags)
### Schedule
For upcoming events across all projects, use `basecamp reports schedule --json`.
```bash
basecamp schedule info --in <project> --json # Schedule info
basecamp schedule entries --in <project> --json # List entries
basecamp schedule show <id> --in <project> # Entry details
basecamp schedule show <id> --date 20240315 # Specific occurrence (recurring)
basecamp schedule create "Event" --starts-at "2024-03-15T09:00:00Z" --ends-at "2024-03-15T10:00:00Z" --in <project>
basecamp schedule create "Meeting" --all-day --notify --participants 1,2,3 --in <project>
basecamp schedule create "Sync" --starts-at "..." --ends-at "..." --no-subscribe --in <project>
basecamp schedule update <id> --summary "New title" --starts-at "..."
basecamp schedule settings --include-due --in <project> # Include todos/cards due dates
```
**Flags:** `--all-day`, `--notify`, `--participants <ids>`, `--no-subscribe`, `--subscribe "people"` (mutually exclusive), `--status` (active/archived/trashed), `--visible-to-clients` (make visible to clients; omit for the server default)
### Check-ins
```bash
basecamp checkins --in <project> --json # Questionnaire info
basecamp checkins questions --in <project> # List questions
basecamp checkins question <id> --in <project> # Question details
basecamp checkins answers <question_id> --in <project> # List answers
basecamp checkins answers <question_id> --by me --in <project> # My answers only
basecamp checkins answers <question_id> --by "Alice Smith" --in <project> # Filter by person (name, email, or ID)
basecamp checkins answer <id> --in <project> # Answer details
basecamp checkins question create "What did you work on?" --in <project>
basecamp checkins question update <id> "New question" --frequency every_week
basecamp checkins answer create <question-id> "My answer" --in <project> # Defaults to today
basecamp checkins answer update <id> "Updated" --in <project>
```
**Schedule options:** `--frequency` (every_day, every_week, every_other_week, every_month, on_certain_days), `--days 1,2,3,4,5` (0=Sun), `--time "5:00pm"`
**Client visibility:** `checkins question create` accepts `--visible-to-clients` to make the question visible to clients (omit for the server default; see the note under Messages for the context-dependent rule).
**Managing a question:**
```bash
basecamp checkins question pause <id> --json # Stop asking it
basecamp checkins question resume <id> --json # Start asking it again
basecamp checkins question answerers <id> --json # Who answers it
basecamp checkins question notify <id> --on-answer --json
basecamp checkins question notify <id> --no-on-answer --json
basecamp checkins question notify <id> --digest-include-unanswered --json
```
`notify` changes **your own** settings, and each one is left alone unless you
name it — so `--on-answer` does not silently reset the digest setting. The
`--no-...` spellings send an explicit false; passing neither setting is refused
rather than sent as an empty update.
**Your pending reminders** (account-wide, no `--in`):
```bash
basecamp checkins reminders --json
basecamp checkins reminders --limit 10 --json
```
`reminders` and `answerers` take `--limit` but deliberately **no `--page`**: the
API does not honor a page number on these, so the flag would accept a value it
could not act on.
### Timeline
```bash
basecamp timeline --json # Account-wide activity
basecamp timeline --in <project> --json # Project activity
basecamp timeline me --json # Your activity
basecamp timeline --person <id> --json # Person's activity
```
Use `--limit N` to cap results or `--all` to fetch everything (default: 100 events).
### Events (change history)
`basecamp timeline` reports activity across a project or account. For the audit
trail of one specific item — todo, card, message, document — use `basecamp
events`:
```bash
basecamp events <id|url> --json # Change history for one item
basecamp events <id> --limit 25 --json # Cap results (default 100)
basecamp events <id> --all --json # Fetch everything
```
Common `action` values: `created`, `completed`/`uncompleted`,
`assignment_changed`, `content_changed`, `archived`/`unarchived`,
`commented_on`, and — for cards — `adopted`, which is recorded every time a card
moves to another column. That makes `events` the way to answer "when did this
card move?" or "when was this actually finished?", neither of which `updated_at`
can tell you.
`--page` accepts only `1`; use `--all` to walk every page.
### Recordings (Cross-project)
Use `basecamp recordings <type>` for cross-project type browsing. **For assigned todos, prefer `basecamp reports assigned`** — recordings do not include assignee data and cannot be filtered by person.
```bash
basecamp recordings todos --json # All todos across projects
basecamp recordings todos --all --json # All todos (paginate through all)
basecamp recordings messages --in <project> # Messages in project
basecamp recordings documents --status archived # Archived docs
basecamp recordings cards --sort created_at --direction asc
basecamp recordings cards --status archived --all --json # Include archived cards
```
**Types:** `todos`, `messages`, `documents`, `comments`, `cards`, `uploads`
**Status filtering:** By default, only `active` recordings are returned. Use `--status archived` or `--status trashed` to query other statuses. You may need separate queries to get complete data (e.g., active + archived).
**Status management:**
```bash
basecamp recordings trash <id> --in <project> # Move to trash
basecamp recordings archive <id> --in <project> # Archive
basecamp recordings restore <id> --in <project> # Restore to active
basecamp recordings visibility <id> --visible --in <project> # Show to clients
basecamp recordings visibility <id> --hidden # Hide from clients
```
### Templates
```bash
basecamp templates list --json # List project templates
basecamp templates show <id> --json # Project template details
basecamp templates create "Template Name" # Create empty project template
basecamp templates update <id> --name "New Name"
basecamp templates delete <id> # Trash project template
basecamp templates construct <id> --name "New Project" # Create project (async)
basecamp templates construct <id> --name "New Project" --start-date 2026-09-01 # Anchor template dates to that week
basecamp templates construction <template_id> <construction_id> # Check project status
basecamp templates library --json # List active to-do list templates
basecamp templates copy <template_id> --in <project> # Start copying into To-dos
basecamp templates copy-status <copy_id> # Check copy status
```
**Asynchronous results:** `construct` returns a construction ID; poll `construction`
until `status="completed"` to get the project. A template's dates are relative to its
first week, and template weeks start on Sunday: `--start-date` (YYYY-MM-DD or natural,
e.g. `next monday`) anchors them to the Sunday on or before that date; without it they
anchor to the week of construction. `copy` returns a copy ID; poll
`copy-status` through `pending` and `processing` until it is `completed` or `failed`.
A copy can report the people who need access to the destination project. Show those
people to the user and rerun with `--confirm-adding-people` only after the user
explicitly approves granting that access. Never add this flag automatically.
### Webhooks
```bash
basecamp webhooks list --in <project> --json # List webhooks
basecamp webhooks show <id> --in <project> # Webhook details
basecamp webhooks create "https://..." --in <project>
basecamp webhooks create "https://..." --types "Todo,Comment" --in <project>
basecamp webhooks update <id> --active --in <project>
basecamp webhooks update <id> --inactive # Disable
basecamp webhooks delete <id> --in <project>
```
**Event types:** Todo, Todolist, Message, Comment, Document, Upload, Vault, Schedule::Entry, Kanban::Card, Question, Question::Answer
### Subscriptions
```bash
basecamp subscriptions <recording_id> # Who's subscribed
basecamp subscriptions subscribe <id> # Subscribe yourself
basecamp subscriptions unsubscribe <id> # Unsubscribe
basecamp subscriptions add <id> --people 1,2,3 # Add people
basecamp subscriptions remove <id> --people 1,2,3 # Remove people
```
### Lineup (Account-wide Markers)
```bash
basecamp lineup list # List all markers
basecamp lineup create "Milestone" "2024-03-15" # Create marker
basecamp lineup create "Launch" tomorrow # Natural date parsing
basecamp lineup update <id> "New Name" "+7"
basecamp lineup delete <id>
```
**Note:** Lineup markers are account-wide, not project-scoped.
### Gauges
Gauges track project progress with colored needles on a 0-100 scale.
```bash
basecamp gauges list --json # All gauges (account-wide)
basecamp gauges needles --in <project> --json # Needles for a project
basecamp gauges needle <id> --json # Needle details
basecamp gauges create --position 75 --color green --in <project>
basecamp gauges create --position 50 --color yellow --description "Halfway" --in <project>
basecamp gauges create --position 25 --notify custom --subscriptions 1,2 --in <project>
basecamp gauges update <id> --description "Updated"
basecamp gauges delete <id>
basecamp gauges enable --in <project> # Enable gauge on project
basecamp gauges disable --in <project> # Disable gauge
```
**Colors:** green, yellow, red. **Notify:** everyone, working_on, custom (with `--subscriptions`).
### Assignments
View your assignments across all projects. Separate from `reports assigned` — provides structured priority grouping and due-date scoping.
```bash
basecamp assignments --json # All (priorities + non-priorities)
basecamp assignments list --json # Same as bare
basecamp assignments completed --json # Completed assignments
basecamp assignments due overdue --json # Overdue
basecamp assignments due due_today --json # Due today
basecamp assignments due due_tomorrow --json # Due tomorrow
basecamp assignments due due_later_this_week --json # Due later this week
```
**Scopes:** overdue, due_today, due_tomorrow, due_later_this_week, due_next_week, due_later.
**Cross-project assignee filtering:** `basecamp todos list --all-projects
--assignee <person>` and `basecamp cards list --all-projects --assignee <person>`
filter server-side across every project. Both are repeatable and match a task
assigned to **any** of the named people. Assignees on nested steps are not
considered, so a card whose step is assigned to someone does not match on that
basis.
**Always pass `--all-projects` when you mean every project.** Without it these
listings are account-wide *only* when no project is in scope — and a configured
default project counts as in scope. With one configured, `--assignee` silently
degrades to a client-side filter over that single project, and `--due` is
rejected outright as account-wide-only. `--all-projects` is what overrides a
configured default, so a recipe that omits it returns different results
depending on the reader's config.
Within a project `--assignee` still works on todos, but there is no server-side
filter, so it fetches everything and narrows client-side. Cards have no
project-scoped `--assignee` at all. `--due with|without|overdue` is account-wide
only on both, and conflicts with `--overdue` and `--no-due-date`, which select
their own listings on the same axis. `--assignee` with `--unassigned` is refused
— the server makes that combination necessarily empty.
**Up Next** — reorder the priority list:
```bash
basecamp assignments prioritize <id> --json # Add to Up Next
basecamp assignments deprioritize <id> --json # Remove from Up Next
basecamp assignments reorder <id> --position 1 --json
```
**Which id to pass — three cases, not two.** A to-do or a card is addressed by
the entry's own `id`. A step that is *not yet* prioritized is addressed by the
step's own `id`, found in the parent card's `children`. But once a step *is*
prioritized, the listing shows it under its parent card, so the entry's top-level
`id` belongs to the **card**, and only `priority_recording_id` addresses the
step.
`basecamp assignments list` is the only place `priority_recording_id` appears —
it is in no URL. Read it from there rather than guessing: `deprioritize` targets
one exact recording and the server answers 204 either way, so a wrong id reports
success while changing nothing. If two steps on one card are prioritized, the
listing shows the card once with a single `priority_recording_id` and the
siblings are not separately addressable.
### Personal (bookmarks, bubble-up, drafts, notes)
Private to you, spanning every project — no `--in <project>`.
```bash
basecamp bookmarks list --json
basecamp bookmarks add <id-or-url> --json
basecamp bookmarks remove <id-or-url> --json
basecamp bookmarks check <id-or-url> --json
basecamp bubble-up add <id-or-url> --json
basecamp bubble-up add <id-or-url> --at tomorrow --json
basecamp bubble-up remove <id-or-url> --json
basecamp drafts list --json
basecamp notes show --json
basecamp notes set "<content>" --json
```
`bubble-up add`/`remove` resurface a recording in your readings (the BC5
successor to "save"), addressed by id or pasted URL. `add` bubbles up now by
default; `--at` schedules it — a keyword (`today`, `tomorrow`, `weekend`,
`next_week`) or a calendar date (`YYYY-MM-DD`). Both verbs are idempotent. There is no
per-recording status read (that GET is an unrenderable API gap); the full list
is `basecamp notifications bubbleups`.
`bookmarks add` and `remove` are idempotent — re-adding returns the existing
bookmark, removing an absent one still succeeds. `check` reports
`{"bookmarked": true|false}` and **always exits 0**: both answers are successes,
so a nonzero exit here means the request failed, not that the answer was false.
`bookmarks list` and `drafts list` are bounded like the account-wide listings:
default 100, `--limit N`, `--page N`, `--all` for every page. Drafts are capped
at 250 server-side.
`notes` is a single private scratchpad — one per person, no id, nothing to list.
Before your first write it renders empty rather than 404ing. `set` **replaces**
the whole note (it does not append) and takes content from an argument or
`--file` — either accepts `-` to read stdin (`cat notes.md | basecamp notes set -`);
a pipe without `-` is not consumed. Markdown is converted to HTML.
### Calendars
```bash
basecamp calendars show <id-or-url> --json
basecamp calendars update <id-or-url> --color blue --json
```
**There is no `calendars list`** — the API has no index endpoint, so address a
calendar by id or by pasting its URL. Colors: white, red, orange, yellow, green,
blue, aqua, purple, gray, pink, brown.
### Notifications
```bash
basecamp notifications --json # List (page 1)
basecamp notifications list --page 2 --json # Page 2
basecamp notifications read <id> --json # Mark as read
basecamp notifications read <id> <id> --page 2 --json # Mark from page 2
basecamp notifications bubbleups --json # All bubble-ups (BC5)
basecamp notifications list --limit-bubble-ups --json # Cap inline bubble-ups at 2
```
**Note:** `read` resolves notification IDs from the specified page. Use `--page` to match the page you listed.
**Bubble Ups (BC5):** `bubbleups` lists all current and scheduled bubble-ups
(paginated; `--page` fetches a single page). `list --limit-bubble-ups` keeps the
notification feed compact: at most 2 inline bubble-ups, scheduled ones omitted,
with the uncapped counts still reported.
### Accounts
```bash
basecamp accounts list --json # List authorized accounts
basecamp accounts use <id> # Set default account
basecamp accounts show --json # Account details, limits, subscription
basecamp accounts update --name "New Name" --json # Rename account
basecamp accounts logo upload <file> --json # Upload logo (PNG/JPEG/GIF/WebP/AVIF/HEIC, 5MB max)
basecamp accounts logo remove --json # Remove logo
```
### Chat
```bash
basecamp chat --in <project> --json # List chats
basecamp chat messages --in <project> --json # List messages
basecamp chat post "Hello!" --in <project>
basecamp chat post "@Jane.Smith, check this" --in <project> # With @mention (auto text/html)
basecamp chat line <line_id> --in <project> # Show line
basecamp chat update <line_id> "edited content" --in <project> # Edit existing message in place
basecamp chat delete <line_id> --in <project> --force # Delete line (permanent, not trashable; --force required)
```
### Pings (Direct Messages)
Pings are Basecamp's 1-on-1 and small-group direct messages. They are stored as chat transcripts in `Circle` buckets and use the same line API shape as Campfires.
Use `notifications` to discover active ping threads, then use the generic `api` command to read or post lines.
```bash
# Find ping threads visible in notifications.
# circle_id is the Circle bucket ID from the UI URL; chat_id identifies the Chat::Transcript.
basecamp notifications --json \
--jq '.data.reads[]? | select(.section == "pings") | {bucket_name, app_url, circle_id: (.subscription_url | capture("/buckets/(?<id>[0-9]+)/").id), chat_id: (.subscription_url | capture("/recordings/(?<id>[0-9]+)/").id)}'
# Read a ping thread. Lines are returned newest first.
basecamp api get "/buckets/<circle_id>/chats/<chat_id>/lines.json" --agent
# Post a ping line.
basecamp api post "/buckets/<circle_id>/chats/<chat_id>/lines.json" \
--data '{"content":"<p>Hey, quick question.</p>"}' --json
```
Ping line records include `creator.name`, `created_at`, `content` HTML, `type`, `bucket.type: "Circle"`, and attachment fields when files or voice notes are present.
Ping URLs use `/circles/<circle_id>` and may include a line anchor after `@`:
```bash
echo "https://app.basecamp.com/<account_id>/circles/44024535@9927050443" \
| sed -E 's|.*/circles/([0-9]+)(@([0-9]+))?.*|circle:\1 line:\3|'
# circle:44024535 line:9927050443
```
Pings are not returned by `basecamp recordings <type>`. Use `notifications` for discovery and the chat lines API for the conversation.
### People
```bash
basecamp people list --json # All people in account
basecamp people list --project <project> --json # People on project
basecamp me --json # Current user
basecamp people show <id> --json # Person details
basecamp people show me --json # Your own profile
basecamp people update me --bio "..." --title "..." --json # Edit your own profile
basecamp people out-of-office me --json # Your out-of-office status
basecamp people out-of-office me --start 2026-09-14 --end 2026-09-18 --json # Set out-of-office
basecamp people out-of-office me --clear --json # Clear out-of-office
basecamp people add <id> --project <project> # Add a team member to a project
basecamp people remove <id> --project <project> # Remove a team member from a project
```
`people update me` edits your own profile (bio, title, name, email, location,
time zone); pass a flag with an empty value to clear that field. `people
out-of-office me` shows your away status, sets it with `--start`/`--end`
(natural language or YYYY-MM-DD, end not before start), or clears it with
`--clear`.
`people list` reports each person's `client` flag. `people add`/`remove` manage
team members only — a client's id passed to them is dropped server-side, never
cross-graded — so clients have their own verbs:
```bash
basecamp people clients enable --in <project> # Turn client access on (do this first)
basecamp people clients list --in <project> # Clients on the project
basecamp people clients add <id|email|name> --in <project> # Grant an existing client user
basecamp people clients invite annie@example.com --in <project> # Invite a new client by email
basecamp people clients invite "Annie Bryan <annie@example.com>" --in <project> # ... with a name
basecamp people clients invite - --in <project> # One invitee per line on stdin
basecamp people clients remove <id|email|name> --in <project> # Revoke a client's access
basecamp people clients disable --in <project> # Turn client access off (after removing every client)
```
Enabling clients is a deliberate, separate step: it applies the project's
default client visibility (timeline and most tools shared; card table,
Campfire, and Doors private), so `add`/`invite` never enable implicitly and
answer `forbidden` with an `enable` hint while clients are off. `invite` takes
`--company` (applies to every invitee) and `--title` (one invitee only), and is
all-or-nothing: a token that is not an address is refused locally as `usage`
(2) naming each one, an address the server rejects exits `validation` (9)
naming each rejected row, and a seat shortfall exits `limit_exceeded` (10) — in
every case nobody was invited. `add`/`remove` report the ids the server did not grant or revoke
(already on the project, or not a client user) in the notice.
### Search
```bash
basecamp search "query" --json # Full-text search (capped at 20; --all for every match)
basecamp search "query" --sort recency --limit 20
basecamp search "query" --project Marketing # Scope to one project (--in also works)
basecamp search "query" --type todo # Filter by type: todo, message, document, comment,
# card, file, ping, chat, check-in, event, folder,
# forward, client
basecamp search "query" --creator me # Filter by creator (name, email, ID, or 'me')
basecamp search "query" --since last_30_days # last_7_days|last_30_days|last_90_days|last_12_months|forever
basecamp search "query" --file-type pdf # Filter attachments: image, audio, video, pdf
basecamp search "query" --exclude-chat # Drop chat/campfire results
basecamp search metadata --json # Recording and file types the API accepts as filters
```
### Generic Show
```bash
basecamp show <type> <id> --in <project> --json # Show any recording type (includes up to 100 comments by default)
basecamp show <type> <id> --all-comments --in <project> --json # Fetch the full discussion when you need every comment
basecamp show <type> <id> --no-comments --in <project> --json # Skip the extra comments fetch
# Types: todo, todolist, message, comment, card, card-table, document (or omit <type> for generic lookup)
# Typed show commands also support --comments / --all-comments / --no-comments:
basecamp todos show <id> --comments --json # Opt in to comments on typed show
basecamp cards show <id> --all-comments --json # Fetch all comments on card
basecamp messages show <id> --no-comments --json # Suppress comments
# All commentable show commands: todos, messages, cards, files, todolists, schedule, checkins, forwards, chat
```
## Configuration
The CLI uses two directory namespaces: `basecamp` for your Basecamp identity and project relationships, `basecamp` for tool-specific operational data.
```
~/.config/basecamp/ # Basecamp identity (DO NOT read credentials)
├── credentials.json # OAuth tokens — NEVER read or log
├── client.json # Obsolete (former dev-only client registration; safe to delete)
└── config.json # Global preferences (account_id, base_url, format)
~/.cache/basecamp/ # Tool cache (ephemeral, auto-managed)
├── completion.json # Tab completion cache
└── resilience/ # Circuit breaker state
.basecamp/ # Per-repo config (committed to git)
└── config.json # Project defaults (project_id, account_id, todolist_id)
```
**Per-repo config:** `.basecamp/config.json`
```json
{
"project_id": "12345",
"todolist_id": "67890"
}
```
**Initialize:**
```bash
basecamp config init
basecamp config set project_id <id>
basecamp config set todolist_id <id>
```
**Config Trust:**
Authority keys (`base_url`, `default_profile`, `profiles`) in local/repo configs are blocked until explicitly trusted. This prevents a cloned repo's config from redirecting OAuth tokens.
```bash
basecamp config trust # Trust nearest .basecamp/config.json
basecamp config trust /path/to/.basecamp/config.json # Trust specific config file
basecamp config trust --list # Show all trusted configs
basecamp config untrust # Revoke trust for nearest config
basecamp config untrust /path/to/.basecamp/config.json # Revoke trust for specific path
```
**Check context:**
```bash
cat .basecamp/config.json 2>/dev/null || echo "No project configured"
```
**Global config:** `~/.config/basecamp/config.json` (account_id, base_url, format preferences)
## Error Handling
**General diagnostics:**
```bash
basecamp doctor --json # Check CLI health, auth, connectivity
```
**Coding agent setup (non-interactive):**
```bash
basecamp setup agents # Install skill + connect detected agent(s)
basecamp setup agents --json # Structured result envelope
```
`setup agents` installs the baseline skill and connects coding agents without
prompting. Selection is driven by `BASECAMP_SETUP_AGENT` (`claude`, `codex`,
`all`, or `none`); unset auto-detects — one detected agent is connected, several
leave the skill only and surface the per-agent `basecamp setup <id>` commands.
**Rate limiting (429):** The CLI handles backoff automatically. If you see 429 errors, reduce request frequency.
**Authentication errors:**
```bash
basecamp auth status # Check auth
basecamp auth login # Re-authenticate
basecamp auth login --scope full # Full access (the default; ignored by Launchpad)
basecamp auth login --scope read # Read-only access (ignored by Launchpad)
basecamp auth login --device-code # Headless authentication with manual browser instructions
basecamp auth login --with-token -P bot --account <id> # Import a personal access token from stdin (pipe it in)
basecamp auth login --expect-identity <id> # Discard the login unless it authenticated as this identity
basecamp profile create <name> --account <id> --expect-identity <id> # Same assertion for a new profile
```
**Network errors / localhost URLs:**
```bash
# Check for dev config
cat ~/.config/basecamp/config.json
# Should only contain: {"account_id": "<id>"}
# Remove base_url/api_url if pointing to localhost
```
**Not found errors:**
```bash
basecamp auth status # Verify auth working
cat ~/.config/basecamp/accounts.json # Check available accounts
```
**Required arguments are positional (not flags):**
- `basecamp todos create "Buy milk"` (not `--content`)
- `basecamp cards create "New feature"` (not `--title`)
- `basecamp messages create "Subject" "Body"` (not `--subject`)
- `basecamp chat post "Hello"` (not `--content`)
- `basecamp comments create <id> "Text"` (not a flag)
- `basecamp webhooks create "https://..." --in <project>` (not `--url`)
- `basecamp checkins answer create <question-id> "content"` (not `--question`)
- `--date YYYY-MM-DD` is optional for `checkins answer create`; if omitted, it defaults to today
**Missing argument errors (code: "usage"):**
When a required positional argument is missing, the CLI returns a structured error naming
the specific argument. Use this for elicitation:
```bash
$ basecamp todos create --json
{"ok": false, "error": "<content> required", "code": "usage", "retryable": false,
"hint": "Usage: basecamp todos create <content>"}
$ basecamp comments create 123 --json
{"ok": false, "error": "<content> required", "code": "usage", "retryable": false, ...}
```
The `error` field names the missing `<arg>` — use it to prompt the user for the specific value.
**Retryable errors (`retryable`):** every error envelope carries a boolean `retryable` —
`true` when the CLI classified the failure transient (network, timeout, rate limit,
circuit open, most 5xx/gateway responses — not all: 507 and some 500s are verdicts) and
a retry can change the outcome, `false` for a verdict (usage, not found, auth, forbidden,
validation, account limit) and for any error nothing classified. Key on it rather than
on `code` or `error` when deciding whether to retry — `false` means no known reason a
retry would help, not a guarantee of permanence; it is never present on a success
envelope.
**URL malformed (curl exit 3):** Special characters in content. Use plain text or properly escaped HTML.
## Built-in jq Filtering
The CLI has a built-in `--jq` flag powered by gojq — no external `jq` binary required. **Always prefer `--jq` over piping to external `jq`.**
```bash
# Extract fields from data array
basecamp todos list --in <project> --jq '.data[] | select(.completed == false) | .title'
basecamp todos list --in <project> --jq '.data | length'
basecamp todos list --in <project> --jq '[.data[] | {id, title, status}]'
# Access envelope metadata
basecamp todos list --in <project> --jq '.breadcrumbs[0].cmd'
basecamp todos list --in <project> --jq '.meta.stats.requests'
# Filter and transform
basecamp cards list --in <project> --jq '[.data[] | select(.completed == true) | .title]'
basecamp people list --jq '[.data[] | {name: .name, email: .email_address}]'
```
`--jq` implies `--json` — no need to pass both. String results print as plain text; objects and arrays print as formatted JSON.
## Exit Codes
| Exit | Meaning | Fix |
|------|---------|-----|
| 0 | OK | — |
| 1 | Usage error | Check `basecamp <cmd> --help` |
| 2 | Not found | Verify ID/URL exists |
| 3 | Auth error | `basecamp auth login` |
| 4 | Forbidden | Check account/project permissions |
| 5 | Rate limit | Wait and retry (resilience layer handles Retry-After automatically) |
| 6 | Network error | Check connectivity, `basecamp doctor` |
| 7 | API error | Retry; if persistent, check `basecamp doctor` |
| 8 | Ambiguous | Be more specific (use ID instead of name) |
## Learn More
- API concepts: https://github.com/basecamp/bc3-api#key-concepts
- CLI repo: https://github.com/basecamp/basecamp-cli
- API coverage: See API-COVERAGE.md in the CLI repo