feat(cli): Add root-level `composio connections` command for consumer namespace

[ja-818]

Problem

The CLI has no consumer-namespace commands for two fundamental operations:

1. List connected apps — composio dev connected-accounts list is developer-project-scoped and doesn't see consumer/"for you" connections
2. List all available apps — composio dev toolkits list requires composio dev init and developer project setup; there's no root-level catalog command

Real-world impact

We're building Houston, a desktop app that uses Composio for integrations. Our Integrations tab needs to show: (a) which apps the user is connected to, and (b) the full catalog of available apps. Without consumer-level commands, we resort to:

For connection status — probing each app individually via an SSRF side-channel:

// Abuse the SSRF guard in `composio proxy` to detect connections
composio proxy https://invalid.invalid/ --toolkit gmail
// "ToolRouterV2_NoActiveConnection" → not connected
// "ExternalProxy_SSRFBlocked" → connected

We run this 45 times in parallel (one subprocess per app). ~5 seconds latency.

For the app catalog — scraping composio.dev/toolkits HTML to extract initialToolkits JSON, plus a hardcoded static list of 45 popular apps with manually curated names and logo URLs.

Proposed Solution

Two new root-level commands that mirror existing developer-namespace functionality but operate in consumer mode (no project setup required):

1. composio connections

composio connections                          # List active connections
composio connections --toolkits gmail,slack    # Filter by toolkit
composio connections --status EXPIRED          # Show expired connections

2. composio apps

composio apps                    # Full catalog (~982 apps) with connection status
composio apps --query "email"    # Search by name/description
composio apps --connected        # Show only connected apps

Both commands reuse existing infrastructure:

• resolveCommandProject({ mode: 'consumer' }) for consumer user ID resolution
• client.connectedAccounts.list() for connection data
• repo.searchToolkits() + client.toolRouter.session.toolkits() for catalog + logos + status
• Existing format utilities (formatConnectedAccountsTable, formatToolkitsTable, etc.)

What this replaces for consumer-facing apps:

• SSRF probe trick (45 subprocess spawns → 1 command)
• Hardcoded static app catalogs
• HTML scraping of composio.dev
• ~5-second first-load latency → sub-1 second
• Polling-based connection status detection

Related

• Feature request: Add meta-tool to list connected toolkits in MCP server #3118 — Requests similar capability as an MCP meta-tool (complementary)
• consumer-short-term-cache.ts already calls getConsumerConnectedToolkits() internally but doesn't expose it as a command

PR submitted: #3188

[CryogenicPlanet]

hey would love more context into why you want to use us this way instead of directly building on top of our developer platform? we have APIs for doing all of this and should be fairly straight forward.

i understand the ask for those two commands, i am thinking about ways to minimize bash calls claude has to make while using the CLI.

for apps, we want it to search and not give it this escape hatch. you can get them programmatically here https://docs.composio.dev/reference/api-reference/toolkits/getToolkits

for connections, you cannot query the consumer connections but you can easily query the connections if you make a developer project via our APIs. i am more open to adding this into the cli but want to think about it more, my first idea is to bring back the connection rolling cache and expose that as json so it would be readable but i would not want to provide any SLAs on the CLI if you are building on top of it

[ja-818]

Hey! Quick context on our use case.

Houston is a free open source desktop app that lets non-technical people use AI agents. Someone says "check my calendar and send that email" and the agent uses composio execute under the hood. Users never see a terminal.

The only time they touch Composio is clicking "Connect Gmail" in our UI, doing OAuth, and coming back. That's it. They don't know what an API key or developer project is. They authenticated via composio login and composio link, everything is in the consumer namespace, and we just need to show them what they connected.

The cache file idea is interesting but it has a 15 min TTL and only populates when certain CLI commands run, so it's stale or empty on a fresh app launch.

I think this is a win for you too. We're putting Composio in front of people who would never find you otherwise. Non-technical users, 982 integrations, through a chat interface, zero docs. All we need is a reliable way to query consumer connections from the CLI that's already on their machine.

Happy to build whatever shape you prefer. CLI command, stable cache file, consumer-only endpoint. We just need it to work without developer project setup.

[CryogenicPlanet]

hey!

happy to jump on a call and explain further, but i think there is some confusion.

with our developer product you can build experiences like our CLI or Composio For You — they're built on our dev platform. your customers never need to interface with an API key or a developer project. only you guys have to, and then they can use us without ever seeing that side.

our consumer namespace is for people who want to use composio directly. the developer projects are for product builders like yourself to build complex, rich experiences on top of our platform, with a robust SLA and a good developer experience.

you could in theory build on top of our consumer apps like our connect mcp or our cli, but it's heavily discouraged — these are surfaces where we want to rapidly experiment.

all that said it makes sense to support showing connections in some way in the cli, but i want to think about minimizing calls for claude, and don't want to commit to any type of SLA as i might change it a few times.

[CryogenicPlanet]

this was shipped!