Coding Agent¶

A Coding Agent is a managed agent that brings Snowflake CoCo’s coding capabilities into your own applications through the Cortex Agents REST API. You add the code_toolset_all tool type to a Cortex Agent, and Snowflake provisions and manages a sandbox backed by the same runtime that powers CoCo — bash, file read/write/edit, grep, glob, web search, SQL execution, and skills — executes the tools, and streams results back to your application, so you don’t build or host an agent loop yourself. Any query that requires code generation, SQL execution, data transformation, or pipeline automation is handled inside the sandboxed runtime.

Use code_toolset_all when you want an autonomous coding agent with the full suite of development tools. It differs from two related surfaces:

• code_execution tool — a single Python sandbox tool you add alongside other agent tools (Cortex Analyst, Cortex Search). Use it when your agent’s primary function is not code generation. See Cortex Agent code execution tool.
• Cortex Code CLI — the cortex code command-line client that runs locally on your machine. A Coding Agent exposes the same toolset as a hosted agent you call over the API instead.

code_toolset_all and code_execution are mutually exclusive — a single request can declare at most one of them. Specifying both returns an error.

Included tools¶

When a request includes code_toolset_all, Snowflake automatically provisions the complete set of sandbox tools:

• bash: Execute shell commands
• read: Read file contents
• write: Create or overwrite files
• edit: Make targeted edits to existing files
• grep: Search file contents with regular expressions
• glob: Find files by pattern
• web_search: Search the web
• snowflake_sql_execute: Execute SQL against Snowflake
• skill: Execute agent skills

New tools added to the sandbox are automatically included without requiring changes to your request.

Enabling the toolset¶

Add the code_toolset_all tool type to the tools list of your agent specification or request:

{
  "tools": [
    {
      "tool_spec": {
        "type": "code_toolset_all",
        "name": "code_toolset_all"
      }
    }
  ]
}

No tool_resources entry is required for basic usage — the sandbox is provisioned automatically when this tool type is present. The remaining sections describe optional configuration.

Example request¶

The following agent:run request combines the most common configuration in a single call: the code_toolset_all tool, a mounted workspace, a skill attached from a Snowflake named stage, a disabled bundled skill, a permission policy, and orchestration model and instructions.

{
  "messages": [
    {"role": "user", "content": [{"type": "text", "text": "Forecast next quarter's revenue and write the results to a file."}]}
  ],
  "models": {
    "orchestration": "claude-sonnet-4-5"
  },
  "instructions": {
    "system": "You are a data analysis assistant. Prefer Python with pandas for data manipulation."
  },
  "tools": [
    {
      "tool_spec": {
        "type": "code_toolset_all",
        "name": "code_toolset_all"
      }
    }
  ],
  "skills": [
    {
      "name": "forecaster",
      "source": {
        "type": "STAGE",
        "path": "@db1.schema1.skill_stage/skills/forecaster"
      }
    }
  ],
  "tool_resources": {
    "code_toolset_all": {
      "permission_policy": { "type": "always_allow" },
      "workspace_mounts": [
        {
          "name": "USER$.PUBLIC.DEFAULT$",
          "type": "workspace",
          "mount_path": "/workspace"
        }
      ],
      "disabled_skills": ["streamlit"]
    }
  }
}

Skills are declared in the top-level skills array (not under tool_resources), matching how skills are attached to a persistent agent. Sandbox behavior — permission policy, workspace mounts, and disabled skills — is configured under tool_resources.code_toolset_all.

Sandbox permission policy¶

By default, tools that modify state (such as bash, write, edit, and snowflake_sql_execute) require user approval before execution. Control this behavior with permission_policy in tool_resources under the tool’s name.

{
  "tools": [
    { "tool_spec": { "type": "code_toolset_all", "name": "code_toolset_all" } }
  ],
  "tool_resources": {
    "code_toolset_all": {
      "permission_policy": { "type": "always_allow" }
    }
  }
}

The permission_policy field also applies to the code_execution tool type. See Cortex Agent code execution tool.

Attaching a workspace¶

To give the sandbox access to files in a Snowflake workspace, specify workspace_mounts in tool_resources under the tool’s name. Each entry describes a workspace to mount into the sandbox container:

{
  "tools": [
    { "tool_spec": { "type": "code_toolset_all", "name": "code_toolset_all" } }
  ],
  "tool_resources": {
    "code_toolset_all": {
      "workspace_mounts": [
        {
          "name": "USER$.PUBLIC.DEFAULT$",
          "type": "workspace",
          "mount_path": "/workspace"
        }
      ]
    }
  }
}

The workspace_mounts array fields:

You can mount multiple workspaces by including multiple entries in the workspace_mounts array:

"workspace_mounts": [
  {
    "name": "USER$.PUBLIC.DEFAULT$",
    "type": "workspace",
    "mount_path": "/workspace"
  },
  {
    "name": "DB.SCHEMA.SHARED_DATA",
    "type": "workspace",
    "mount_path": "/data"
  }
]

The workspace must exist and have a live version before it can be mounted. Workspaces are mounted read-write at version live by default. Skills defined in the mounted workspace (under .snowflake/cortex/skills/) are automatically attached to the agent session.

Attaching skills¶

The sandbox exposes skills to the agent from three sources:

• Bundled skills — Snowflake-provided skills (such as charting and dashboard skills) are included in every code_toolset_all sandbox by default. Use disabled_skills to remove ones you don’t want.
• Workspace skills — skills under .snowflake/cortex/skills/ in a mounted workspace are attached automatically (see Attaching a workspace).
• Stage-based skills — skills stored in a Snowflake named stage or Git repository, attached through the agent’s skills list.

Stage-based skills use the same mechanism documented in Agent skills: store each skill folder (with its SKILL.md and any scripts) in a named stage, then reference it in the top-level skills array. When the request also includes code_toolset_all, Snowflake mounts each referenced stage skill read-only into the sandbox and the agent can invoke it like any bundled skill — including running the skill’s Python scripts, since the sandbox provides the code execution environment those skills require.

{
  "messages": [
    {"role": "user", "content": [{"type": "text", "text": "Use the forecaster skill on this dataset."}]}
  ],
  "tools": [
    { "tool_spec": { "type": "code_toolset_all", "name": "code_toolset_all" } }
  ],
  "skills": [
    {
      "name": "forecaster",
      "source": {
        "type": "STAGE",
        "path": "@db1.schema1.skill_stage/skills/forecaster"
      }
    }
  ]
}

The USAGE privilege on the stage is required to read the skill files. For the full skill authoring, storage, and management workflow — including Git-backed skills and skills with code — see Agent skills.

Disabling skills¶

By default, the code_toolset_all sandbox includes all bundled skills. Selectively disable specific bundled skills using the disabled_skills field in tool_resources:

{
  "tools": [
    { "tool_spec": { "type": "code_toolset_all", "name": "code_toolset_all" } }
  ],
  "tool_resources": {
    "code_toolset_all": {
      "disabled_skills": ["dashboard", "streamlit"]
    }
  }
}

The disabled_skills array contains the names of bundled skills to remove from the sandbox session. Disabled skills are not visible to the agent and cannot be invoked. This is useful when you want to restrict the agent to a subset of capabilities.

Orchestration model and instructions¶

Customize the agent’s behavior with system-level instructions. When using instructions, use the models field (not model) to specify the orchestration model.

{
  "messages": [
    {"role": "user", "content": [{"type": "text", "text": "help me analyze this data"}]}
  ],
  "tools": [
    { "tool_spec": { "type": "code_toolset_all", "name": "code_toolset_all" } }
  ],
  "models": {
    "orchestration": "claude-sonnet-4-5"
  },
  "instructions": {
    "system": "You are a data analysis assistant. Always use Python with pandas for data manipulation."
  }
}

The instructions object fields:

The models object fields:

When to use each tool type¶

Use code_toolset_all when:

• You want an autonomous coding agent with file system access
• Your workflow requires reading, writing, and editing files
• You need shell command execution alongside SQL and web search

Use code_execution when:

• You need basic Python code execution alongside other tools (Cortex Analyst, Cortex Search)
• Your agent’s primary function is not code generation
• You want a lightweight sandbox for data processing and visualization

For the code_execution tool, default libraries, adding libraries through the Artifact Repository, and external network access, see Cortex Agent code execution tool.