# Basecamp in ChatGPT for agency client status

> Basecamp in ChatGPT for an agency: approvals and card tables stay readable, account staff get reads only, and the writes a client can see go to leads.

**TL;DR** An agency putting Basecamp in ChatGPT has one real risk: a write a client can see. In Basecamp, comments, to-dos and cards inherit client visibility from what they sit under, and update_a_basecamp_client_visibility_by_id can expose internal work. In Elaichi, give the account staff role an allow rule that names only the Basecamp read tools, add allow rules for the apps staff also use, and leave every Basecamp write to the account leads' role.

## The Monday question an agency account lead asks

An agency account lead runs eight client projects in Basecamp. On Monday they want three answers. Which deliverables are waiting on client approval? What did each client say in correspondence last week? Where does each card on the status board sit? Basecamp in ChatGPT answers all three from reads. The risk is a different kind of call: a write that a client can see.

[Elaichi's `basecamp` connector](/connectors/basecamp/) carries 104 tools: 58 read, 18 create, 19 update and 9 delete. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. Elaichi serves 600+ connectors through one organization endpoint, so Basecamp sits beside the agency's other apps.

For most teams the dangerous Basecamp tools are the ones that trash work. For an agency, the dangerous ones are the ones that talk to clients. A message posted to the wrong board, or one internal thread switched to client-visible, is a client conversation the agency did not mean to have. This playbook keeps every read open and leaves the writes that can reach a client to the people who should make them.

## How client visibility works in a Basecamp project

In Basecamp, everything in a client project starts private to the team, and the team chooses what to share item by item ([Basecamp help, What clients can see and do](https://3.basecamp-help.com/article/693-changing-what-clients-can-see-and-do), checked October 2026). Basecamp's API reference describes clients as external collaborators who log in to see only what a team chooses to share ([Basecamp API, people](https://github.com/basecamp/bc-api/blob/master/sections/people.md), checked October 2026).

Visibility is set on some items and inherited by others. The same help page lists both:

| Item | How its client visibility is set |
|---|---|
| Messages on the Message Board | Individually |
| To-do lists | Individually |
| Card tables | Individually |
| Schedule events and check-in questions | Individually |
| Comments | Inherited from the item they are on |
| To-dos | Inherited from their to-do list |
| Cards | Inherited from their card table |

Two consequences matter for an AI client. Once an item is visible to a client, the client also sees all its existing comments. Clients are also notified of future comments, chat lines and check-in answers on anything they can see. A comment is therefore never private on its own. It is exactly as visible as the thing it sits under.

## Which Basecamp writes can reach a client

Any write into a project with clients can land where a client reads it, and one tool changes what clients can see at all. These are the writes that touch the items in the table above.

| Tool | How it reaches a client |
|---|---|
| `update_a_basecamp_client_visibility_by_id` | Sets `visible_to_clients` on a recording, which shows it to the project's clients or hides it |
| `create_a_basecamp_message`, `update_a_basecamp_message_by_id` | A message takes a `visible_to_clients` argument; a published one notifies everyone on the project when no subscriber list is given |
| `create_a_basecamp_comment`, `update_a_basecamp_comment_by_id` | Posts or edits under any recording; on a client-visible item, the client sees it and is notified |
| `create_a_basecamp_todo_list`, `create_a_basecamp_todo`, `update_a_basecamp_todo_by_id` | A to-do inherits its list's visibility, so a to-do added to a client-visible list is visible |
| `create_a_basecamp_card_table_card`, `update_a_basecamp_card_table_card_by_id` | A card inherits its card table's visibility |
| `create_a_basecamp_schedule_entry`, `update_a_basecamp_schedule_entry_by_id` | Schedule events carry their own visibility setting |
| `create_a_basecamp_campfire_line` | Clients are notified of chat lines on anything they can see |

Documents, uploads and vaults add content to a project too. Basecamp's help pages cited here do not say how those inherit visibility, so treat `create_a_basecamp_document`, `update_a_basecamp_document_by_id`, `create_a_basecamp_upload`, `update_a_basecamp_upload_by_id` and `create_a_basecamp_vault` the same way.

The visibility tool is the sharpest. One call can turn an internal thread, with its whole comment history, into something the client reads. Basecamp's API returns 403 Forbidden when a recording inherits its visibility from a parent ([Basecamp API, client visibility](https://github.com/basecamp/bc-api/blob/master/sections/client_visibility.md), checked October 2026).

`create_a_basecamp_message` defaults `visible_to_clients` to false for team callers. That default holds only while nobody sets the argument. A model asked to "post the update for the client" can set it to true.

A to-do or a card write looks internal, but it takes the visibility of the list or table it lands in, and a restriction names tools, not projects. A to-do written into a client-visible list is visible to the client. So the staff role does not get "to-do and card writes" as a safe middle ground.

## Holding account staff to the Basecamp reads

Give the account staff role an allow rule that names only the basecamp connector's read tools, and leave every write off it. A restriction in Elaichi is a rule naming which connectors and which individual tools a target may reach. In Elaichi, restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything. So the agency needs two roles: one for account staff and one for account leads, who do post to clients.

Three details of an allow rule shape the setup:

- **It is the role's whole allowlist.** An allow rule naming one tool of a connector admits that connector for that tool only. Once a role carries any allow rule, every connector and tool that none of its allow rules names is restricted, across all connectors.
- **Other apps need their own rules.** If staff also use Salesforce or Slack, add a whole-connector allow rule for each. Separate allow rules in one layer merge into one allowlist, so one rule per app works.
- **A block rule is the wrong shape.** A layer with only block rules has no allowlist, so every Basecamp write the rule does not name stays reachable. Naming all 46 non-read tools by hand is easy to get wrong.

The account leads' role carries no allow rule, so it keeps everything. Staff keep all 58 reads, including the client approvals, correspondence and card table reads below. They do not keep follow-up to-dos or card moves through ChatGPT, which stay with leads or in Basecamp itself. A restriction change takes effect within about two minutes.

When an account staff member does need to reply to a client, they file an access request. An admin approves it in the console, under Governance, Access requests. The grant lifts exactly the one tool for that one person, and every other rule on their role keeps applying. No access request can be approved from inside ChatGPT, so no AI session can widen its own reach.

## Why not lock visible_to_clients to false with a freeze?

A freeze is the wrong control here, for two reasons. A frozen parameter in Elaichi locks an argument on a toolbox entry, so the model cannot change it. In Elaichi, a freeze binds only calls made through its toolbox entry, so share the toolbox with the people it governs, not the connection itself. An agency on per-person Basecamp connections reaches each person's own connection directly, where the tool runs unfrozen.

The second reason is in Basecamp's model. Comments have no visibility argument at all, because they inherit visibility from the item they are on. No frozen value on `create_a_basecamp_comment` can keep a comment private on a client-visible card. Leaving the tool off the allowlist is the control that holds.

## Reading client approvals, correspondence and status cards

The reads an account lead needs are all reachable, and none of them changes what a client sees. Basecamp's Clientside has its own read tools. `list_all_basecamp_client_approvals` returns each approval with its status and approver. `list_all_basecamp_client_correspondences` returns client correspondence with its reply count. `list_all_basecamp_client_replies` reads the replies under one correspondence or approval.

Status boards live in card tables. `get_single_basecamp_card_table_by_id` returns a table's columns, and `list_all_basecamp_card_table_cards` reads the cards in one column. `list_all_basecamp_projects` returns each project the person can see, with its `clients_enabled` flag. That flag lets the model mark which projects have clients at all before it summarizes anything.

A useful Monday prompt reads like this: list every pending client approval across my projects, then the last client correspondence in each, then any card in the "Waiting on client" column. That is three read paths and no writes. Run it from an account staff login and it works the same as from an account lead's, because every step is a read.

## Whose Basecamp account each ChatGPT call runs on

Each person's own. Elaichi's basecamp connector signs in as a person, and every call through a connection uses the account it was connected with. A shared Basecamp connection reaches Basecamp as the person who connected it, for everyone it is shared with. At an agency, that would let a staff member read every client project the account lead is on.

Have each person connect Basecamp in Elaichi with their own Basecamp sign-in, and leave it unshared. Basecamp then decides which client projects each call can read, and Elaichi's role rules decide which tools each call can use. Basecamp's own guide says an app uses Basecamp on the person's behalf through their OAuth 2 token ([Basecamp's authentication guide](https://github.com/basecamp/bc-api/blob/master/sections/authentication.md), checked October 2026).

When a client company leaves a project, Basecamp switches every item previously visible to the client back to private ([Basecamp help, Working with clients](https://3.basecamp-help.com/article/689-clients-in-projects), checked October 2026). Nothing in Elaichi needs to change for that.

## Setting up Basecamp in ChatGPT for the agency

A workspace admin publishes Elaichi once as a custom app. OpenAI says full MCP support, including write actions, is rolling out in beta to ChatGPT Business, Enterprise and Edu ([OpenAI help center](https://help.openai.com/en/articles/12584461-developer-mode-and-mcp-apps-in-chatgpt), checked October 2026). On Business, only admins and owners enable developer mode and deploy an app. The path is Workspace settings, Apps, Create. Enter `https://api.elaichi.ai/mcp` exactly, click Scan Tools, then Create, and publish the draft.

ChatGPT's own action settings sit on that one app, not on Basecamp's tools behind it. In Elaichi, connected tools are never listed one by one, however few there are. The model finds Basecamp tools with `search_tools` and runs them through `execute_tool`. A ChatGPT setting can gate that one tool, but it cannot single out the visibility tool from a read. The per-tool decision lives in Elaichi's restriction. The full setup is in [connecting Elaichi to ChatGPT](/blog/connect-elaichi-to-chatgpt/).

On Elaichi's consent screen, "Run your connected tools" covers a connected app's reads and writes alike. Leaving a box unticked does not make Basecamp read-only, and it does not keep a comment away from a client. The allow rule does.

## Basecamp's hosted server versus a control plane for an agency

Basecamp hosts its own MCP server at `https://mcp.basecamp.com/mcp`, included with every Basecamp account ([basecamp.com/ai](https://basecamp.com/ai), checked October 2026). Basecamp's page says the assistant acts as the signed-in person. On approval, each person picks Read-only access or Full access. For an agency that needs only Basecamp, with staff on read-only and leads on full access, that is the simpler setup with no second vendor.

Elaichi's case is narrower and specific:

- **Per-tool rules on a role.** Account staff hold the Basecamp reads while every write stays restricted, and the leads' role keeps them.
- **One address across apps.** The same endpoint serves Basecamp and the agency's other apps, in ChatGPT, Claude and Cursor.
- **One audit trail.** Elaichi writes one entry for each connected-tool call that reaches execution (a call refused earlier writes none), whichever app the call reached.

Each entry names the person, the Basecamp connection reached, the tool and the outcome. It logs the one path argument that names the object, as the target id, and nothing else about the arguments, so a comment write shows which recording it went under. ChatGPT is named as the client. Read the Basecamp writes weekly, and check that each one landed in a project you expected. The same per-person pattern for an internal project team is in [Basecamp in Claude for overdue to-dos](/blog/project-team-claude-basecamp-todos/). Client-facing work in a CRM follows a similar shape in [Salesforce in ChatGPT for a sales team](/blog/sales-team-chatgpt-salesforce-accounts/), and every other app is in the [connector catalog](/connectors/).

## FAQ

### Can ChatGPT make internal Basecamp work visible to a client?

Yes, if it can reach update_a_basecamp_client_visibility_by_id. That tool sets visible_to_clients on a Basecamp recording, which shows it to the project's clients or hides it. Basecamp's help says a client who can see an item also sees all its existing comments. In Elaichi, leave that tool off the allow rule on the role your account staff hold.

### Does a comment ChatGPT posts in Basecamp reach the client?

It does when the item is client-visible. Basecamp's help, checked October 2026, says comments inherit client visibility from the item they are on, and that clients are notified of future comments on anything they can see. create_a_basecamp_comment posts under any recording, so a comment on a client-visible message or card reaches the client.

### Which Basecamp reads should an agency keep open in ChatGPT?

All of them. list_all_basecamp_client_approvals, list_all_basecamp_client_correspondences and list_all_basecamp_client_replies read the Clientside, and the card table tools read client status boards. Reading changes nothing a client sees, so an allow rule that names the read tools keeps every one of them in place.

### Should an agency use Basecamp's own MCP server instead?

Sometimes. Basecamp hosts a server at https://mcp.basecamp.com/mcp at no extra cost, and its AI page, checked October 2026, lets each person pick read-only access or full access on approval. If Basecamp is the only app in question, that is the simpler choice. Elaichi adds rules per tool and per role across apps, and one audit trail.

### Can Elaichi lock visible_to_clients to false on new messages?

Not reliably for a team on per-person connections. A frozen value in Elaichi binds only calls made through the toolbox entry that carries it, and each person reaches their own Basecamp connection directly. Comments also have no visibility argument to freeze, because they inherit it. Leave the writes off the staff role's allow rule instead.

## Read next

- [Basecamp in Claude for overdue to-dos and status](/blog/project-team-claude-basecamp-todos/) — Basecamp in Claude for a project team: each person on their own Basecamp sign-in, trash and project delete off the role, to-dos and comments kept.
- [ClickUp in ChatGPT for a customer success team](/blog/customer-success-chatgpt-clickup-tasks/) — Two decisions put ClickUp in ChatGPT for a customer success team: whose account each call runs on, and which ClickUp tools are restricted.
- [Each rep's own Salesforce access, in ChatGPT](/blog/sales-team-chatgpt-salesforce-accounts/) — Salesforce access in ChatGPT works per rep: each call runs on the rep's own connection, so Salesforce's sharing rules decide which accounts they see.