Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Importing configuration

Since 1.3.0, ccode can import a profile from a local YAML file or an HTTPS URL. This is in addition to the regular Configuration mechanism. The imported file can also declare which fields ccode should ask the user for at import time, like to fill out their own API key.

The idea here is that your team can have files that you distribute as presets for your projects, or host them on your LAN somewhere.

How this works

The three commands that came in with 1.3.0:

ccode add-profile                    # interactive
ccode add-profile --from-file <path> # import from local YAML
ccode add-profile --from-url <url>   # import from https URL
ccode remove-profile <name>          # remove a profile from a config
ccode set-default-profile <name>     # change default_profile in a config

Each one accepts an optional [target] (a directory, ., or an explicit file path) so you can edit project-level configs as well as the user config.

For example, you could execute the following in your project directory to have a config there:

ccode add-profile --from-url https://ccode.kronis.dev/configuration-examples/deepseek.yaml ccode.yaml

Or if you execute the following, then it just gets added to your own global config:

ccode add-profile --from-url https://ccode.kronis.dev/configuration-examples/deepseek.yaml

add-profile imports one profile per file/URL.

The single top-level key in your file is the profile name, and its value is the profile body.

If you’re hosting profile YAMLs for your team or org, here’s how you’d create your own:

  1. Put the profile body under a single top-level key (the profile name).
  2. Fill in everything except secrets (unless you want to share those and nobody else can see the files).
  3. Add a prompt: list with the field names users should fill in interactively (see below).

Field names are validated strictly against the Config Reference, so typos should get caught.

Prompting for values to fill out

Those profile files can include data like API keys for internal files, but sometimes you can instead give the user an example file without those, and prompt them to enter whatever needs to be filled out on a case-by-case basis.

This can be achieved with a prompt: field listing names of fields the user should be asked about at import time. ccode reads this list, prompts for each one, fills the answers into the profile body, and doesn’t include the actual prompt field in the saved profile.

Here’s the hosted DeepSeek (Pro) example:

# Example profile: DeepSeek (Pro tier)
# Sign up: https://platform.deepseek.com/
#
# Add to your config with:
#   ccode add-profile --from-url https://ccode.kronis.dev/configuration-examples/deepseek.yaml
#
# ccode will prompt you for the auth token during import.

deepseek:
  anthropic_base_url: "https://api.deepseek.com/anthropic"
  # the API key is part of the prompt field below, user will fill this out when pulling
  # anthropic_auth_token: "YOUR_DEEPSEEK_API_KEY_HERE"
  models:
    model:
      model: "deepseek-v4-pro[1m]"
    opus:
      model: "deepseek-v4-pro[1m]"
    sonnet:
      model: "deepseek-v4-pro[1m]"
    haiku:
      model: "deepseek-v4-flash"
    subagent:
      model: "deepseek-v4-flash"
  claude_code_effort_level: "max"
  env:
    CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS: "1"
  prompt:
    - anthropic_auth_token

Importing this file would show:

This profile asks for the following values - press ENTER to skip any:
  anthropic_auth_token: sk-...

A few rules:

  • Each name must be a valid profile YAML field (see the Config Reference).
  • ENTER skips a prompt; the field stays unset.
  • The prompt: field can target any single-string profile field. It cannot target the profile’s env: block, since that’s a map of arbitrary env vars rather than one fillable value.

If you want users to set their own env vars, ship the YAML with placeholder values and have them run ccode edit-config afterwards. You can also use --value to set fields without prompting, or --no-prompts to skip all prompts. See the ccode add-profile reference on the Usage page for examples.

Hosted example profiles

The example files below live on this site and you can use them directly. This would work nicely together with a minimal profile:

ccode init-config --minimal
ccode add-profile --from-url https://ccode.kronis.dev/configuration-examples/deepseek.yaml --set-default

Most use a prompt: list for any field ccode can’t fill in for you (auth tokens, project IDs, gateway URLs); a couple of providers don’t need any prompts at all and the file is a one-shot starter.

ProviderURLPrompts forOpen
Anthropic APIhttps://ccode.kronis.dev/configuration-examples/anthropic.yamlAPI keyview
Amazon Bedrockhttps://ccode.kronis.dev/configuration-examples/bedrock.yaml(none - uses AWS creds)view
Claude Platform on AWShttps://ccode.kronis.dev/configuration-examples/anthropic-aws.yamlworkspace ID + API key (ENTER on key for SigV4)view
Amazon Bedrock Mantlehttps://ccode.kronis.dev/configuration-examples/mantle.yaml(none - uses AWS creds)view
Google Vertex AIhttps://ccode.kronis.dev/configuration-examples/vertex.yamlGCP project IDview
Microsoft Foundry (Azure)https://ccode.kronis.dev/configuration-examples/foundry.yamlresource URL + API keyview
DeepSeek (Pro)https://ccode.kronis.dev/configuration-examples/deepseek.yamlauth tokenview
DeepSeek (Flash)https://ccode.kronis.dev/configuration-examples/deepseek-flash.yamlauth tokenview
OpenRouterhttps://ccode.kronis.dev/configuration-examples/openrouter.yamlauth tokenview
OpenRouter (custom model)https://ccode.kronis.dev/configuration-examples/openrouter-model.yamlauth token + every model slugview
OpenRouter (custom preset)https://ccode.kronis.dev/configuration-examples/openrouter-preset.yamlauth token (preset slug edited after import)view
Z.AI (Zhipu GLM)https://ccode.kronis.dev/configuration-examples/zai.yamlauth tokenview
Moonshot Kimihttps://ccode.kronis.dev/configuration-examples/kimi.yamlauth tokenview
Alibaba Qwenhttps://ccode.kronis.dev/configuration-examples/qwen.yamlauth tokenview
MiniMaxhttps://ccode.kronis.dev/configuration-examples/minimax.yamlauth tokenview
Local / self-hostedhttps://ccode.kronis.dev/configuration-examples/local.yamllocal server URL (model name edited after import)view
Organization gatewayhttps://ccode.kronis.dev/configuration-examples/gateway.yamlgateway URL + auth tokenview

Handling of secrets during import

If you import a profile into a project file that needs a secret, ccode will ask where the secret should go:

Where should the API key go?
If you intend to commit project files, the separate user config is safer.
  1) Your user config:  <user-config-path>
  2) This project file: <project-config-path>

Option 1 (default) puts the secret fields in your user config and the rest in the project file; option 2 keeps everything in the project file. Importing into your user config skips the prompt entirely.

The fields treated as secrets:

  • anthropic_api_key
  • anthropic_auth_token
  • claude_code_oauth_token
  • claude_code_oauth_refresh_token
  • anthropic_foundry_api_key
  • aws_bearer_token_bedrock
  • anthropic_aws_api_key

See also

For the day-to-day usage of:

  • ccode add-profile - adding a profile
  • ccode remove-profile - removing a profile
  • ccode set-default-profile - setting the default profile

you can also see the Commands section on the Usage page.