Runtime authentication

The daemon pool starts each installed runtime in a probe sandbox to read its models. That probe has no agent identity, so it cannot read organization or agent secrets. An install-wide Secret can supply API keys to both the probe and agent sessions. Use API-key authentication for unattended runtimes; an interactive OAuth login cannot complete in the pool probe.

Choose the runtime imageCopy Anchor Link

The chart's default runtime-sandbox image contains Claude Code, Codex, DeepSeek Harness, and OpenCode. The published runtime-sandbox-full image additionally contains Qwen Code and other ACP runtimes:

daemonPool:
  runtime:
    repository: ghcr.io/agentconnect-md/runtime-sandbox-full

The chart appends the selected AgentConnect release tag. Use daemonPool.runtime.image to pin a complete image reference. Changing the image restarts runtime discovery.

Configure any runtime with a SecretCopy Anchor Link

For OpenCode with Anthropic, OpenAI, or DeepSeek, use the built-in model pairs below. Existing pairs are reused automatically; no separate OpenCode environment mapping is needed. Use the following mapping for other providers or additional runtime settings.

1. Choose a model provider and obtain an API key. Check the runtime's official documentation for its API-key environment variable, supported model IDs, and endpoint format. For example, see Qwen Code authentication, OpenCode providers, and DeepSeek's API root.
2. Put the key, endpoint, and any runtime configuration in a Kubernetes Secret in the AgentConnect release namespace. Do not put the key in Helm values.
3. Map each runtime's environment variable to a Secret entry under daemonPool.runtimeEnvironment.runtimes. Use the runtime ID reported by the image. The chart projects only the named entries into the daemon; it sends each runtime only its own mapped variables at probe and session launch.
4. Upgrade the Helm release. A changed mapping rolls the daemon pool and runs the probe again. After changing a Secret value, restart the daemon pool so its environment and probe refresh.

For example, an install using DeepSeek's OpenAI-compatible API can put these entries in its Secret:

Then reference those entries without copying their values into Helm:

daemonPool:
  runtime:
    repository: ghcr.io/agentconnect-md/runtime-sandbox-full
  runtimeEnvironment:
    existingSecret: agentconnect-model-credentials
    runtimes:
      qwen-code:
        OPENAI_API_KEY: PROVIDER_API_KEY
        OPENAI_BASE_URL: PROVIDER_BASE_URL
        OPENAI_MODEL: QWEN_MODEL
      opencode:
        DEEPSEEK_API_KEY: PROVIDER_API_KEY
        OPENCODE_CONFIG_CONTENT: OPENCODE_CONFIG_CONTENT

Qwen Code selects its OpenAI-compatible API-key authentication from OPENAI_API_KEY. OpenCode selects the deepseek provider and model from OPENCODE_CONFIG_CONTENT and reads DEEPSEEK_API_KEY from its environment. The endpoint and model shown here follow DeepSeek's current API documentation; use your chosen provider's documentation for a different service. Neither runtime needs a browser login or a stored OAuth account.

OpenCode's model setting selects a default; it does not limit the provider list. For providers beyond the built-in pairs, put their API keys in the Secret and map their variables under opencode, such as OPENCODE_API_KEY for OpenCode Zen. When built-in pairs are configured, use OPENCODE_CONFIG_CONTENT to explicitly include any additional providers in enabled_providers. A model appearing in a catalog does not prove that an account can call it; verify it with a request using that provider's credential.

runtimeEnvironment.existingSecret can be omitted when daemonPool.modelCredentials.existingSecret already names the same Secret. Each mapping points to a Secret entry name, not an inline value. A missing or empty entry stops the daemon at startup instead of silently probing without the intended credential. A runtime mapping overrides an agent-level variable with the same name; built-in model translation and issued session keys retain their existing precedence for variables they write.

Built-in model pairs and other sourcesCopy Anchor Link

The chart also supports daemonPool.modelCredentials.existingSecret for its built-in credential translation:

MODEL_TOKEN and MODEL_BASE_URL are a shared fallback for these recognized runtimes. A runtime-specific pair replaces the shared pair as a whole. The daemon translates each pair into that runtime's configuration at probe and spawn; it does not translate a pair for Qwen Code or arbitrary runtimes. Use runtimeEnvironment for those runtimes and for settings beyond a key and URL, such as a model selection or provider configuration.

OpenCode defaults to the providers configured through these pairs. Explicit enabled_providers, model restrictions, and custom model definitions in OPENCODE_CONFIG_CONTENT are preserved. Reuse the Claude Code base URL for Anthropic: AgentConnect adds /v1 for OpenCode's SDK without duplicating an existing suffix. OpenAI and DeepSeek base URLs pass through unchanged.

With a key server, endpoint-only pairs are sufficient for model discovery. Discovery does not make model requests; each real session receives an issued key for its selected provider. A cross-provider switch takes effect at the next runtime start after the current work settles, using the new provider's key. Without a key server, OpenCode receives the separate static keys and can switch between the configured providers directly.

modelEgress.clients is another install-wide source for supported clients. The chart refuses combining it with modelCredentials.existingSecret, or setting a built-in pair again in daemonPool.extraEnv. Organization and agent variables and secrets reach their agent sessions but not the independent pool probe. Infra → Provider keys are organization connections for supported provider consumers; they are not ACP runtime credentials.

OpenCode also reuses the pairs supplied by modelEgress.clients.claude, .codex, and .deepseek. These existing client entries need no changes to enable OpenCode; there is no separate opencode client entry.

For a Codex gateway, use OPENAI_MODEL_TOKEN and OPENAI_MODEL_BASE_URL with the gateway's Codex-compatible API root. The daemon configures Codex's provider URL as well as its API key. When the endpoint is DeepSeek directly, use its documented API root, https://api.deepseek.com.

To confirm discovery after rollout, inspect the daemon pool's probe completion log and check the runtime's model picker in the console. A runtime installed in the image can still have an empty picker if its API key, model ID, or endpoint is wrong.

Keys stay with the daemon poolCopy Anchor Link

The install's own static keys never enter agent pods when their endpoint is HTTPS. The daemon pool reads them from its own environment, the pod's runtime gets a placeholder, and the pool member puts the real key on each request to the provider. This covers only the keys configured in this chart: the built-in pairs in modelCredentials, modelEgress.clients.<client>.apiKey, and ANTHROPIC_API_KEY, OPENAI_API_KEY, DEEPSEEK_API_KEY, and COPILOT_PROVIDER_API_KEY mapped under runtimeEnvironment.

• The daemon pool needs outbound HTTPS to every provider endpoint or gateway these keys use. If your cluster restricts egress from the release namespace, allow it.
• A key stays in the pod's environment when its endpoint is plain http://, when the daemon cannot tie it to one endpoint for that runtime, or when another variable also carries it, such as an OPENCODE_CONFIG_CONTENT that embeds the key. The daemon logs this once.
• Keys issued by a key server, and the model-discovery probe, are unchanged.

Credential protection describes the same behavior on other daemons.