Model provider keys

Store Bedrock or Mantle credentials locally, or pin a Claude.ai subscription, and choose the Claude Code provider for each CLI profile.

Model provider keys let a CLI profile run Claude Code through AWS Bedrock or Mantle instead of inheriting the machine's default Claude configuration — or pin it to your Claude.ai subscription on a machine whose default configuration points at Bedrock. They are stored only on the machine running the Convoy CLI.

These credentials are different from Convoy API keys:

an Convoy API key authenticates the CLI and MCP clients with the Convoy backend
a model provider key authenticates Claude Code with Bedrock or Mantle

Add a provider key

Give each credential a local name and choose its provider:

convoy keys add work-bedrock \
  --provider bedrock \
  --region us-east-1

The CLI prompts for the token with masked input. Use --provider mantle for Mantle. The region is optional.

You can pass --token <token> for non-interactive setup, but doing so may save the credential in shell history.

Running add again with the same name updates the stored key.

Pin a Claude.ai subscription

--provider anthropic stores an entry with no credential at all:

convoy keys add claude-sub --provider anthropic

Assign it like any other entry, and profiles using it run Claude Code on the Claude sign-in of the machine the CLI runs on — your Claude.ai subscription.

This is stronger than leaving a profile unassigned. An unassigned profile follows the machine's Claude configuration, so a ~/.claude/settings.json (or a dev container) that enables Bedrock or Mantle wins. The anthropic entry is passed through Claude Code's command-line settings layer, which outranks that file, so the run stays on the subscription. A leftover AWS_BEARER_TOKEN_BEDROCK in the environment is ignored.

--token and --region are rejected for this provider — there is nothing to store.

List stored keys

convoy keys list

The output masks every token and shows which profiles use each key. Credential-free anthropic entries list their token as none. convoy keys ls is an alias.

Assign a key to a profile

From a directory that resolves to the intended profile:

convoy keys use work-bedrock

Or name the profile explicitly:

convoy keys use work-bedrock --profile work

The assignment is saved as the profile's provider_key. Restart convoy connect for the change to take effect.

At connection time, provider selection follows this order:

convoy connect --provider-key <name> — one-run override
the resolved profile's assigned provider_key
the machine's own Claude configuration, usually a Claude subscription

The one-run override does not change config.toml:

convoy connect --provider-key work-bedrock

If an assigned or overridden key does not exist, connect stops with an error instead of silently falling back to another provider.

Unassign or remove a key

Return a profile to the machine's Claude configuration:

convoy keys unassign --profile work

Delete a stored key:

convoy keys remove work-bedrock

convoy keys rm is an alias. Removal is refused while any profile still references the key; unassign it from those profiles first.

Storage and security

Provider keys are stored under [keys.<name>] in ~/.config/convoy/config.toml, while profile assignments use provider_key. See the config file reference for the complete schema and an example.

The tokens are not registered with Convoy or synchronized to its backend. Do not commit config.toml, paste tokens into shell history, or include them in support logs.