Cortex Code: CoCo in Snowsight no longer requires COPILOT_USER (Pending)

Starting the week of October 19, 2026, using Snowflake Cortex Code (CoCo) in Snowsight no longer requires the legacy SNOWFLAKE.COPILOT_USER database role. Access to CoCo is managed by the Cortex roles already in use (SNOWFLAKE.CORTEX_USER or SNOWFLAKE.CORTEX_AGENT_USER).

This change applies to CoCo in Snowsight only. SNOWFLAKE.COPILOT_USER isn’t being removed. After the change, that role no longer gates CoCo, so it can’t block any user from using CoCo. This is an unbundled behavior change, so there’s no testing period and no way to opt out after the change reaches your account.

Important

All information on this page, including the planned dates, is subject to change. Snowflake rolls this change out progressively, so the date on which a given account sees the change can vary.

Until this change reaches your account, CoCo in Snowsight still requires SNOWFLAKE.COPILOT_USER. See Access control requirements.

Behavior change

Before the change:

Access to CoCo in Snowsight requires SNOWFLAKE.COPILOT_USER plus either SNOWFLAKE.CORTEX_USER or SNOWFLAKE.CORTEX_AGENT_USER.

After the change:

Access to CoCo in Snowsight requires only SNOWFLAKE.CORTEX_USER or SNOWFLAKE.CORTEX_AGENT_USER.

SNOWFLAKE.COPILOT_USER is no longer part of the CoCo access path. Granting or revoking it has no effect on CoCo.

Why Snowflake is making this change

SNOWFLAKE.COPILOT_USER is a legacy database role that was tied to Snowflake Copilot, which has been fully sunset and removed from accounts. CoCo CLI and CoCo Desktop already don’t require SNOWFLAKE.COPILOT_USER. Removing it as a requirement for CoCo in Snowsight gives every CoCo surface the same access path, and stops the role from blocking CoCo in accounts that revoked it for legacy reasons.

This change doesn’t remove SNOWFLAKE.COPILOT_USER, alter other privileges, or grant data access. It only removes SNOWFLAKE.COPILOT_USER as a requirement for CoCo in Snowsight.

How this affects you

  • SNOWFLAKE.COPILOT_USER is still granted to PUBLIC: No change. This is the default. If you never revoked SNOWFLAKE.COPILOT_USER from PUBLIC, this behavior change doesn’t affect your account.
  • SNOWFLAKE.COPILOT_USER was revoked from PUBLIC: Roles that don’t have SNOWFLAKE.COPILOT_USER are affected. Those roles can use CoCo in Snowsight when they have SNOWFLAKE.CORTEX_USER or SNOWFLAKE.CORTEX_AGENT_USER. To keep CoCo restricted, use the controls in What you should do.

What you should do

1. Decide who should have access

Access to a CoCo surface (CLI, Snowsight, or Desktop) requires one of these database roles:

  • SNOWFLAKE.CORTEX_USER
  • SNOWFLAKE.CORTEX_AGENT_USER

Choose the outcome you want, then configure roles and limits to match:

  • Allow CoCo, Snowflake CoWork, and Cortex Agents: Grant SNOWFLAKE.CORTEX_USER or SNOWFLAKE.CORTEX_AGENT_USER to the user’s role.
  • Turn those agent surfaces off for a role: SNOWFLAKE.CORTEX_USER is granted to PUBLIC by default, so revoking it from one role doesn’t turn the surfaces off while PUBLIC still has it. Revoke SNOWFLAKE.CORTEX_USER and SNOWFLAKE.CORTEX_AGENT_USER from PUBLIC, then grant one of them only to the roles that should keep access.
  • Allow Snowflake CoWork and Cortex Agents, but block CoCo: Keep the Cortex database role, then set the daily credit-limit parameter for each CoCo surface you want to block to 0. Each surface is controlled independently. For the parameter names and how account-level and user-level limits interact, see Daily credit usage limits for CoCo.

To block CoCo in Snowsight for a single user, set that user’s daily credit limit to 0:

ALTER USER jsmith
  SET CORTEX_CODE_SNOWSIGHT_DAILY_EST_CREDIT_LIMIT_PER_USER = 0;

To block CoCo in Snowsight for everyone by default, and then allow specific users, set the account limit to 0 and set a non-zero limit on the users who should have access:

ALTER ACCOUNT SET CORTEX_CODE_SNOWSIGHT_DAILY_EST_CREDIT_LIMIT_PER_USER = 0;

ALTER USER power_user SET CORTEX_CODE_SNOWSIGHT_DAILY_EST_CREDIT_LIMIT_PER_USER = 20;

For CoCo CLI and CoCo Desktop, you can also use managed settings to restrict access.

If you can’t use daily credit limits to manage access, contact Snowflake Support.

2. Remove COPILOT_USER from CoCo setup

Remove SNOWFLAKE.COPILOT_USER from custom roles, grant scripts, and provisioning automation that used it for CoCo. It’s no longer needed for CoCo in Snowsight.

3. Confirm the result

Sign in as a sample user and check that CoCo access matches what you intended.

FAQ

What’s changing?

Starting the week of October 19, 2026, CoCo in Snowsight no longer requires the legacy SNOWFLAKE.COPILOT_USER database role. Access to CoCo is managed by the Cortex roles already in use (SNOWFLAKE.CORTEX_USER or SNOWFLAKE.CORTEX_AGENT_USER).

Did this change remove any privileges or data access?

No. This change only affects CoCo access in Snowsight. No other privileges or data access change.

Why now?

Snowflake is removing COPILOT_USER as a CoCo requirement because it’s a legacy role that was tied to Snowflake Copilot, which has been fully sunset and removed from accounts.

Will my users lose access?

No. Users who already had SNOWFLAKE.CORTEX_USER or SNOWFLAKE.CORTEX_AGENT_USER keep access. SNOWFLAKE.COPILOT_USER is simply no longer checked.

I revoked COPILOT_USER to keep CoCo off. What now?

That revoke no longer keeps CoCo off. Decide who should have access, then grant a Cortex database role or use the daily credit limit to restrict CoCo. See What you should do.

Is there a testing or opt-out period?

No. This is an unbundled behavior change. Changes start taking effect the week of October 19, 2026, and can’t be disabled after they reach your account.

Do I need to do anything?

Decide who should have access to CoCo, grant a Cortex database role or use the daily credit limit to match that decision, and remove SNOWFLAKE.COPILOT_USER from setup that used it for CoCo. See What you should do.

Ref: 2445