px0 tools connect <app> does the same thing on purpose, ahead of time, when you would rather authorize deliberately than wait for the first run to ask:
px0 tools list --status. Pass --reconnect to drop an existing authorization first - the fix for a token that has expired or been revoked, since without it an app already recorded as authorized just reports that and stops.
You never have to know which services exist, and you never connect a service you turn out not to need.
1. Set up the API key, once
px0 init asks for the same key, so on a fresh store this is already done.
Get the key from the Composio platform under Get Started → Settings → API Keys. px0 verifies it against the live API before storing it, so a typo’d or revoked key fails here rather than three screens into a workflow build.
The permission the key needs
The key needs write access toauth_configs. That is the permission that lets px0 prepare an app’s authorization on your behalf. A read-only key gets as far as the first tool call and then reports Composio’s own refusal:
Where the key is stored
Inconfig.toml under connectors.composio_api_key, and in .state/credentials.toml, which px0 keeps at mode 0600 and px0 doctor checks on every run.
Behind a TLS-intercepting proxy
If your network runs a TLS-inspecting proxy - Zscaler, Netskope, and friends - setting the key detects it, because the certificate chain will not validate against the public CA bundle Python ships with. px0 looks for a system CA bundle that does trust the interceptor, retries with it, and records it asconnectors.ca_bundle so later runs reuse it:
SSL_CERT_FILE at your corporate root and stops. It never silently disables verification - a tool that quietly turns off certificate checking on a corporate network is doing you harm, not a favour. An explicit SSL_CERT_FILE always wins over the stored bundle.
Once stored, that bundle is used for every outbound request px0 makes, not only Composio ones. A px0 brain add against an internal wiki behind the same proxy works without further configuration, and if you ever need to set it by hand:
2. Apps authorize themselves
Write a workflow that needs Slack, run it, and px0 does the rest:px0 workflows new asks first: once it knows which tools the workflow needs, it checks what is authorized and offers to prepare the rest, so a workflow is authorized before it ever runs. See Build a workflow.
Two properties are worth knowing:
- Preparing a link is idempotent. The underlying auth config is created once and cached, so a second attempt reuses it instead of piling up duplicate configurations in your Composio account.
- Minting a URL grants nothing. Access happens only when a human consents in the browser. px0 preparing a link gives it no access by itself.
- App credentials never touch your disk. px0 holds a Composio API key and connected-account ids, not your Slack or Gmail tokens. See What leaves your machine.
3. What is ready, and what is not
--status costs one API call per provider, which is why it is opt-in rather than the default. See Tools for the rest of what that listing shows.
To revoke an app entirely - deleted at Composio, and removed from the store’s credentials:
4. When an authorization lapses
px0 doctor fails (exit 4) on any stored authorization that is not active, so a health check catches a connection that quietly expired instead of letting a scheduled workflow discover it at 5pm on Friday:
INITIATED means a consent was started and never completed. px0 says so explicitly rather than minting a second link you would also leave open:
5. When something fails mid-run
A tool call whose app is not ready fails cleanly rather than crashing. The run is recorded asfailed, and the reason carries the URL you need:
connectors.retries (default 3) before the run gives up, so a momentary outage does not fail a scheduled workflow.
Next steps
Tools
Curated versus discovered tools, and read/write access.
Build a workflow
The builder authorizes what a plan needs, up front.