Multiple Companies

One Cofounder account can run many companies. Knowledge, connections, resources, events, and billing each belong to one company, so every command has to target the right one.

Pick the Active Company

The CLI saves your selection as its default:

company switch asks you to pick. company use <org-id-or-slug> sets the default without asking. company show is a readable summary with dashboard links. company get returns the full overview: what's ready, every resource, what the company knows, what's broken, and the next step.

Aim a Single Call

On the CLI, override the saved default for one command or one shell:

• --company-id <uuid>, a global flag on any CLI command.
• COFOUNDER_COMPANY_ID, which pins the company for the whole shell or agent environment.

On MCP, your agent first calls user_get and company_memberships_list to check the account and find the company named for the task. It passes that company's org_id as company_id on company tools. Account tools such as company_create don't take it. A working directory doesn't pick a company. If it's unclear which company you mean, your agent asks by name.

Whether company_id is required depends on how the connection signs in:

• With the standard MCP OAuth sign-in, company_id is required on every company tool when your account has more than one company. With exactly one, omitting it uses that company. The sign-in identifies your account, so switching companies needs no new login. Each call checks your current membership and permissions.
• A company API key always acts in its own company, so company_id can be omitted.
• On older connections whose token names a company (its cf claim), omitting company_id uses that company.

Company resources pick their company through a cofounder://companies/{company_id}/... URI. An earlier tool call doesn't pick the company for a resource read. See MCP Beyond Tools.

Features that differ by company

Some commands run only for companies that have their feature turned on. The CLI lists them only for those companies, and running one checks with Cofounder first, so a feature turned on recently works right away. Signing in or switching companies updates the list. cofounder company feature-flags list shows which features the active company has.

How Logins and Keys Stay on One Company

The CLI saves one user login. Switching companies changes the saved default without signing in again. Each command locks in its company when it starts and sends it as X-Organization-Id, so a switch or token refresh mid-run can't move it to another company. The server checks your live membership and permissions for that company.

Each MCP host has its own login and picks the company per call with company_id. Switching on the CLI doesn't change MCP. The older cofounder mcp stdio bridge only works with the company in its token and refuses others. Use native remote MCP to switch between companies.

The overrides above work for saved user logins only. A fixed COFOUNDER_API_TOKEN that names a company can't switch to another. An API key is bound to the company it was created under, and the API rejects a company_id for any other company. If you run two companies, create a key for each. See API Keys and Scripting.

Delete a Company

Both commands are destructive, so each needs a typed confirmation:

cofounder org delete <org-id> --confirm "DELETE COMPANY"
cofounder org start-fresh <org-id> --name "NewCo" --reason <category> --confirm "START FRESH"

org delete schedules permanent deletion seven days later. Billing is canceled immediately when the schedule is accepted. The command response includes a redirect_url, and the confirmation email and reminder email include the same link. Open it while signed in to cancel before deletion starts. Canceling does not restart subscriptions, so review billing separately.

start-fresh is a separate flow. It archives the selected company and creates a replacement company. It does not use the seven-day deletion schedule. Preview either command with --dry-run first.

Next Steps

For credentials that don't need anyone to sign in, see API Keys and Scripting.