SoftTech AI Registry
Snowflake · Cortex Agents

Coding Agent

The Snowflake-managed coding sandbox provisioned for a Cortex Agent when the code_toolset_all tool type is configured. Snowflake documents that code_toolset_all automatically provisions the complete set of sandbox tools: bash (shell command execution), read, write (create or overwrite files), edit, grep, glob, web_search, snowflake_sql_execute (read-only SELECT and SHOW against Snowflake; documented as able to write to stages) and skill execution. Snowflake also documents that new tools added to the sandbox are automatically included without changes to the existing request or agent specification, so the toolset is a bundle whose membership can expand. The sandbox can mount Snowflake workspace objects read/write, and file changes written into a mounted workspace persist according to Snowflake workspace behaviour. This record covers only the code_toolset_all Coding Agent toolset, not generic Cortex Agents functionality.

Recorded characteristics

Function
When code_toolset_all is present in a Cortex Agent specification or request, Snowflake provisions a managed sandbox containing bash, read, write, edit, grep, glob, web_search, snowflake_sql_execute and skill execution. A run is initiated by a user or by an API or SQL caller; the agent then selects and invokes sandbox tools across multiple steps within the run, streaming tool_use and tool_result pairs before a final text answer. Snowflake documents that newly introduced sandbox tools become automatically included in code_toolset_all without the existing request or agent specification being changed, so the toolset composition is not fixed at the nine tools documented at the time of this record. Long-running work can use background execution, which requires a thread; background runs continue beyond the normal synchronous REST window (Snowflake documents a 15 minute synchronous timeout and a 6 hour background timeout) and can be reconnected to through the streaming endpoint or observed through thread messages. Background execution does not remove the permission policy: an approval-gated state-changing tool call still waits unless the configured permission policy allows execution. Coding Agent does not itself provide an event trigger or a scheduler; other Snowflake mechanisms may invoke an agent on a schedule, and that scheduling mechanism is outside this capability boundary.
Data access
Within the sandbox the agent can read and search files (read, grep, glob) and can query Snowflake through snowflake_sql_execute, which Snowflake documents as read-only: it supports SELECT and SHOW and, in Snowflake's explicit wording, cannot run DML or DDL. Snowflake also states the tool "can write to stages"; that behaviour is documented but its mechanism and precise scope are not publicly established. Files in the sandbox can be reached through a mounted Snowflake workspace declared by workspace_mounts: workspaces are mounted read/write at version live by default, the default mount path is /workspace, multiple workspaces can be mounted at distinct top-level absolute paths, and nested mount paths are not supported. Only Snowflake workspace objects created with CREATE WORKSPACE can be mounted; regular Snowflake stages are not equivalent to workspace mounts and are not documented as mountable. web_search retrieves web content into the run. Effective Snowflake data access is bounded by the calling user's privileges.
Actions
Can take actions
External actions
No
Human confirmation
Conditional
Permission basis
User permissions
Administrative control
Documented controls: including or removing code_toolset_all from the agent specification or request (code_toolset_all and the standalone code_execution tool are mutually exclusive and specifying both returns an error); the permission_policy setting in tool_resources (always_ask or always_allow); which Snowflake workspaces are mounted through workspace_mounts and at which paths; Snowflake RBAC, including the caller's default role, warehouse USAGE and object privileges; the Cortex database roles SNOWFLAKE.CORTEX_USER (granted to PUBLIC by default and covering all Covered AI Features) or the narrower SNOWFLAKE.CORTEX_AGENT_USER; agent object privileges (CREATE AGENT, USAGE, MODIFY, MONITOR, OWNERSHIP); workspace and object grants, including explicit CALLER USAGE/READ/WRITE grants in a Snowflake Native App context; attachment of skills, including skills defined under .snowflake/cortex/skills/ in a mounted workspace, and disabling skills where supported; and orchestration model configuration. An account-level administrative switch that disables Coding Agent across an account is not publicly established in the reviewed documentation, and Coding-Agent-specific audit and logging behaviour is likewise not established.
Default state
Disabled
Availability
Snowflake documents the Cortex Agents Coding Agent as generally available, announced in the release note dated 26 August 2026. The current Coding Agent documentation page carries no preview banner and Coding Agent does not appear on the Snowflake preview features index. No earlier preview history was established from primary documentation. Edition, region, cloud and deployment restrictions specific to Coding Agent are not publicly established in the reviewed documentation; Snowflake separately documents that background runs are generally available on AWS and Azure and require threads.
Licensing
Licensing and consumption terms specific to Coding Agent are not publicly established in the reviewed documentation. Access to Cortex Agents requires the SNOWFLAKE.CORTEX_USER or SNOWFLAKE.CORTEX_AGENT_USER database role and a default warehouse with USAGE granted to the caller's default role.
External model or provider
The orchestration model is configured through models.orchestration and defaults to auto, which Snowflake documents as letting Snowflake select the highest-quality model available to the account. Model pinning is supported; Snowflake's documentation examples show Anthropic Claude identifiers such as claude-sonnet-4-5 and claude-4-sonnet as current documented examples rather than an exhaustive or permanent list. Because auto selects dynamically, no single permanent model or provider is established for this capability. An exhaustive supported-model list, per-account or per-region model variation, and a permanent provider statement are not publicly established.
Limitations and uncertainty
Human confirmation: Snowflake documents two permission modes configured at build time through permission_policy. Under always_ask (the default) tools that modify state, such as bash, write, edit and snowflake_sql_execute, require user approval; the agent emits a permission request in a tool_use event and stops until the caller returns a permission_decision, so execution waits for a run-time approval. Under always_allow the run-time approval gate is removed and state-changing tools execute without contemporaneous human confirmation. Selecting a permission policy at configuration time is distinct from run-time approval of a specific tool call. The REST agent run interface can implement the interactive permission-decision loop across successive requests; a single SQL AGENT_RUN invocation returns one JSON value and cannot conduct that interactive exchange, so under always_ask the permission request is returned and the statement ends without the tool having run. Unattended or scheduled use involving state-changing tools therefore requires a permission configuration that does not wait for interactive approval. The existence of always_allow is not a Snowflake recommendation of unrestricted privileges. Permission basis and identity: execution uses caller's rights. Snowflake documents that Cortex Agents determines session permissions from the querying user's default role rather than the role active in the session, so effective access is bounded by that user's privileges plus the required Cortex database roles and object privileges. There is no dedicated agent service identity documented for the sandbox. Owner's rights boundary: Snowflake documents that calls to agents using owner's rights do not support code execution. When an agent is invoked from an owner's-rights stored procedure, Snowflake removes the code execution tools (including code_toolset_all) from the request, creates no sandbox even when the tool is enabled in the agent specification, and returns a warning; Snowflake directs callers to use caller's rights instead. Owner's rights is therefore not a route to broader Coding Agent access. Native Apps: agents created by a Snowflake Native App run under restricted caller's rights for the whole sandbox lifecycle, from the mounted workspace to data read through SQL; Snowflake states the sandbox never runs with the app's owner's-rights identity. Tool invocation requires both a consumer privilege and an explicit app caller grant, and declaring workspace_mounts does not bypass those grants. Persistence boundary: the sandbox is scoped to a single conversation thread, is not shared across threads, and in-memory state is not preserved between separate code executions. In-memory sandbox state does not itself constitute persistent workspace storage. Files written into a mounted Snowflake workspace do persist, because the workspace is backed by a stage. Not every file created inside the sandbox persists. SQL boundary: snowflake_sql_execute is documented as read-only, supporting SELECT and SHOW, and Snowflake states explicitly that it cannot run DML or DDL. No direct mutation of Snowflake database objects through INSERT, UPDATE, DELETE, CREATE, DROP or ALTER via this tool is established. Snowflake's parenthetical that the tool "can write to stages" is documented, but its operational semantics are not publicly established and must not be read as general DML or DDL capability. External action: web_search retrieves web content and is not by itself a state-changing action in an external business system. No default state-changing action in an external system is documented for Coding Agent. Actions available through separately configured custom tools, MCP connectors or other integrations are not attributed to this capability. Security and instruction sources (recorded factually as documented by Snowflake): Snowflake states that always_allow removes the execution gate, so the agent runs any command and modifies any resource its role can reach without confirmation, and advises verifying that every input to the run is trusted and running under a least-privilege role. Snowflake identifies the prompt, files in any mounted workspace, attached skills and content fetched with web_search as inputs that can steer what the agent does. Scope-expansion limitation: code_toolset_all is a bundled toolset whose membership Snowflake documents as expanding automatically when new sandbox tools are added, without the existing request or agent specification being changed. The operational capability represented by this record can therefore change without any customer configuration change, which is a monitoring-relevant fact. Adjacent capabilities excluded from this record: the standalone code_execution Python tool (mutually exclusive with code_toolset_all and documented as not querying data), Cortex Code CLI, Snowflake CoCo/CoWork, Cortex Analyst, Cortex Search, generic Cortex Agents orchestration, custom tools and MCP connectors. Unresolved fields: the exact semantics of the documented ability for SQL execution to write to stages; edition and region availability; the exhaustive supported-model list and a permanent provider; an account-level administrative disable control; and Coding-Agent-specific audit and logging behaviour.

Evidence